Bug 831361

Actually I'm wrong: it's replaced by pata_macio. Problem is that pata_macio isn't loaded in installer. If I modprobe pata_macio missing devices appear again.

The problem is that pata_macio contains two drivers, one for the "PCI" variant of the device and one for the "macios" variant (ie, part of the mac-io ASIC and probed via the device-tree). However for some reason I only ever added a module table entry for the PCI bit.

Now it's not totally trivial to fix. First I need to check (somebody around knows off hand ?) whether we can have several module device tables in a single module. If the answer is yes, then I probably need to refine the matching system first.

As it is, the driver will try to match with anything named "ide" or "ata" or anything with a device_type "IDE" or "ATA" which is pretty gross.

So we probably want to rewrite the match table to use the "compatible" property instead, which is fine for all variants that have a well known "compatible" property ... except a few ancient based on the "ohare" version of mac-io which doesn't... (some do, not all, for example the Performa6400 doesn't).

At this point the right approach is thus to:

 - Change the match table to use "compatible" with a list of all the supported
values including "ohare-ata" for the ohare case.

 - Add the module device table for it (again assuming it's ok to have multiple tables in the module. If not we'll have to split the driver in 3: PCI, macio, common)

 - Add a "fixup" in prom_init.c that looks for all IDE/ATA controllers under a node name "ohare" or "pci106b,7", and add the appropriate compatible property if it's missing.

I can try to do a patch later this week, however I don't have any of those old machines to test it on (but do we really care ?)

Why not just load it if macio is detected at all?

Well, that's not how the module loader works :-)

It uses the same mechanism used to bind the driver to the device. The problem is that for the macio part, it uses a specific device type (macio_device/macio_driver) so the rather generic matching doesn't matter, but to keep things easier we never exposed a macio bus type to udev for module matching purposes, and use the standard OF method instead.

Also what's "a macio" ... there's a good half a dozen different versions of it with different PCI IDs etc... so that isn't going to be easier anyway. Also not all variants have IDE cells in them.

I think my proposal is the right thing to do, I just need to squeeze in some time to actually write a patch.

Did this ever get fixed upstream?  Does anyone actually still care?

Well, there are still some users so it would be nice to fix one days and no, I didn't get to do it... in the meantime, it's probably best to keep it built-in.

The kernel config for powerpc still says

CONFIG_PATA_MACIO=m

Josh, would it be possible to make it built-in as Benjamin suggested in comment #6? Or are there any implications with doing so?

Thanks & regards, Phil

Yes.  I'll try to get to it today.  Need to see if it should go in for all powerpc or just 32-bit.

Fixed in master branch.  Should be in the next rawhide build.