The installer still doesn't seem to grok 'modalias' files in sysfs, so we need to add special detection code for the PlayStation 3 "system bus". Attached. Note, we also need anaconda to probe for USB hosts using BUS_UNSPEC instead of BUS_PCI.
Created attachment 152622 [details] PS3 system bus support for kudzu
Created attachment 152628 [details] amended patch Ew, anaconda can't handle module aliases. Amended patch uses the exact name of the driver modules...
Created attachment 152629 [details] PS3 system bus support for kudzu Oops, last patch had one extra line of whitespace added. Removed in this one...
Created attachment 152635 [details] PS3 system bus support for kudzu Gr, and the 4-space indenting inherited from elsewhere confused me too. This time it'll probe for video and scsi devices even when not also probing for network and/or usb.
The video part seems wrong - it will only ever find the device if the driver is already loaded, which somewhat defeats the point. Is there a better way to find this? As for the SCSI bit, the blind match on the model name in OF implies that this will not work very well if we do switch to just using modalias, although that may be something that can change later.
(In reply to comment #5) > The video part seems wrong - it will only ever find the device if the driver is > already loaded, which somewhat defeats the point. Is there a better way to find > this? The driver _is_ already loaded, in our kernel. It's built-in. But that doesn't seem to be sufficient to make the installer use (and set up) X. We need this match too. > As for the SCSI bit, the blind match on the model name in OF implies that this > will not work very well if we do switch to just using modalias, although that > may be something that can change later. Yeah, in time I think the storage thing will end up a ps3_system_bus device like the others -- but for now there's nothing to indicate its presence except the fact that this is a PS3.
(In reply to comment #6) > The driver _is_ already loaded, in our kernel. It's built-in. But that doesn't > seem to be sufficient to make the installer use (and set up) X. We need this > match too. Is that something that's always going to be the case? It would be nice if there was another way to determine this. Added in 1.2.69-1, with the one change to #ifdef __powerpc__ most of ps3Probe. I can't test it on PS3, though.
yeah, we'll always have the video driver built-in. It's the only console and we need it as early as possible. It's likely that it'll also end up with a ps3_system_bus device too though, and we can drop both of the special cases at the end. I can give you an account on a PS3 when I get to a sensible network and am no longer on GPRS... which will be some hours after I get on the plane I was supposed to have boarded three quarters of an hour ago. Or Paul can test -- or indeed Paul can give you an account with sudo privs on ps3.infradead.org, since he'll know its root password.
Yeah, I tried to argue to Geoff that we should create device tree nodes for probing for the ps3 dt, but that didn't seem to get much traction. Bill if you want to mail me a preferred username and ssh public key I'll set you up.
Might be useful in the future - in this case if you could test, that would be great.
Looks good on a running system -- testit.py hacked to list all devices on BUS_PS3 finds storage, gelic, fb, all 4 usb hosts. Asked for only CLASS_VIDEO it shows the framebuffer. An install is the real test, of course. Paul, you said you tried a rawhide install today? Was that with the new kudzu?
This shoudl all be working now AFAIK -- dwmw2 said in his blog that an install worked