That will happen. Recent Apple's OF will reset all ATA devices before
booting the kernel, thus triggering the problem with some of them,
and ide-pmac will hard-reset (via the reset line) devices on boot
as well to avoid problems caused by bogus firmwares or machines booted
from MacOS who let the devices in whatever bogus/unknown state (possibly
I saw that happening on some embedded platforms as well.
I realy think the kernel should be able to do it all, and waiting
around the busy bit is neither complicated nor hamrful, so...
>Seriously, if you are a handed an ATA device that is actually in
>operation when the kernel boots, you are already out of spec. I would
>prefer to barf if the BSY or DRDY bits are set, because taking over the
>ATA bus while a device is in the middle of a command shouldn't be
>happening at Linux kernel boot, ever.
It will happen when the device just got reset or powered up. It's really
a couple of lines to do that properly (see my other mail about the full
procedure I copied from Apple firmware that seem to work fine on all
HW I've tested so far).
Also, another issue we didn't deal with properly yet is PM. With non-APM
power management (like pmac, but probably also ACPI and some embedded
devices), the devices will be basically powered off during suspend, and
no firmware is here to put them back into life on wakeup. So you have to
redo the bringup, which, in some cases (like hotswap IDE bays on some
PowerBooks) probably involves re-running the probe procedure at least,
then re-setting up the device (SET_FEATURE dance)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/