Kristen Carlson Accardi wrote: > On Thu, 28 Sep 2006 10:38:29 +0200 > Hannes Reinecke wrote: > >> Hi Jeff, >> >> argl. Appearently I'm in Yeltsin mode. >> >> Anyway: I'm also have finished an updated version of the ACPI patches. >> They are also based upon the patches by Randy Dunlap but with some >> improvements: > > Hey, > I don't care who gets this stuff in, I just want it done with :). > I'm going to go ahead and make the changes to my patches that Jeff > suggested yesterday, but I'm also glad to help review your patches. > But having looked at your attachment I feel like I'm missing something. > Was there more than this? I don't see the patch that has libata-acpi.c in it. > Oh, not again. Feeling like a git newbie :-( Right. Fixed now. >> - Omit the namespace walk for SATA devices. We can really trust the ACPI >> layer to find out the correct device. If not the ACPI is buggered anyway >> and we shouldn't even try to continue. > > Not sure about this one - how does this work for devices that may not > be present at boot time? Normally this is something we have to walk > namespace for in order to discover -- at least with removable bay > devices. > Tricky that. Don't think so. Reasoning as follows: ACPI is _really_ not designed for hotplugging. The entire ACPI code has to be present at boot time; it's not possible to modify it during run-time. Hence it already _knows_ about all possible controllers and the objects are already present in memory. And all removable bay controllers I've seen so far are either USB devices (which aren't controlled by ACPI anyway) or already present on the mainboard. There might not be a drive attached to them (ie if the bay is not present), but the controller is. And the controller is the only one which actually has a representation in sysfs, hence the correct ACPI object is already attached to it. The SATA-device or PATA channel / PATA-drive don't have a direct representation in sysfs, hence we have to take care of identifying the correct ACPI object ourselves. Which is what we're already do. But the controller itself will already be present. And even if not we can be reasonably sure that the driver core already has assigned the correct handle for us. But to be on the safe side I've put in a sanity check anyway. So, attached is an updated version of my patch, based on the 'acpi' branch from libata-dev. We now even do _GTM & _STM and have the possiblity to call _GTF for PATA devices, too. Not that I recommend that. Comments etc are welcome. Cheers, Hannes -- Dr. Hannes Reinecke hare@suse.de SuSE Linux Products GmbH S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de