On Tue, Dec 13, 2005 at 10:14:17AM -0800, Randy Dunlap wrote:

1.  I had problems applying it.  What tree is it against?
    Say so in the description.

It was against 2.6.15-git at the time, but I accidently left a hunk of 
stuff from the hotplug patch in there which probably confused things. 
I'll try to rediff it by the end of the week (and do other tidying)

7.  Most important:  What good does the ACPI interface do/add?
    What I mean is that acpi_get_child() in scsi_acpi_find_channel()
    always returns a handle value of 0, so it doesn't get us
    any closer to determining the ACPI address (_ADR) of the SATA
    devices.  The acpi_get_devices() technique in my patch (basically
    walking the ACPI namespace, looking at all "devices") is the
    only way that I know of doing this, but I would certainly
    like to find a better way.

When the PCI bus is registered, acpi walks it and finds the appropriate 
acpi handle for each PCI device. This is shoved in the 
firmware_data field of the device structure. Later on, we register the 
scsi bus. As each item on the bus is added, the acpi callback gets 
called. If it's not an endpoint, scsi_acpi_find_channel gets called. 
We're worried about the host case. The host number will correspond to 
the appropriate _ADR underneath the PCI device that the host is on, so 
we simply get the handle of the PCI device and then ask for the child 
with the appropriate _ADR. That gives us the handle for the device, and 
returning that sticks it back in the child's firmware_data field.

At least, that's how it works here. If acpi_get_child always returns 0 
for you, then it sounds like something's going horribly wrong. Do you 
have a copy of the DSDT?
-- 
Matthew Garrett | mjg59@srcf.ucam.org