Tejun Heo wrote:
Jeff Garzik wrote:
Tejun Heo wrote:
Jeff Garzik wrote:
We probably need to do this...
it's not a controller requirement but a BIOS one, so in theory even an
existing, deployed AHCI 1.2 platform could suddenly require BIOS/OS
handoff, if a BIOS update suddenly starts doing new and weird stuff
in SMI.
Note that we need to do BIOS/OS handoff upon resume as well as at boot
time.
Yeah, probably. Do you know of any system which makes use of this
feature? I'm a bit uneasy about committing it without any testing.
I don't.
But the purpose of the feature is to tell BIOS to cleanup and stop using
the hardware. It's a dumb feature, because of compatibility realities,
but hey, other network and SCSI drivers have been doing this sort of
synchronization with their on-board firmwares for years.
IMO the more dangerous route is to continue loading ahci, without first
telling the BIOS to clean up and get out of our way.
Hmmm.... yeah, I'm just worried a bit about adding a chunk of
completely untested code. How about adding a big fat warning message
which gets triggered if the handoff thing seems to be active?
Yeah, printing out something makes a lot of sense, but I would just add
it to the flags output in ahci_print_info() or similar. If we don't
see any further action from ahci (or the system as a whole), we know
something exploded very early in the AHCI driver load.
Or maybe AMD (I see they're CC'd) could test this for us? AMD, what say
you?
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
