On Friday, July 26, 2013 09:37:09 AM Aaron Lu wrote: > On 07/25/2013 10:52 PM, Tejun Heo wrote: > > On Thu, Jul 25, 2013 at 01:47:03PM +0800, Aaron Lu wrote: > >> Binding ACPI handle to SCSI device has several drawbacks, namely: > >> 1 During ATA device initialization time, ACPI handle will be needed > >> while SCSI devices are not created yet. So each time ACPI handle is > >> needed, instead of retrieving the handle by ACPI_HANDLE macro, > >> a namespace scan is performed to find the handle for the corresponding > >> ATA device. This is inefficient, and also expose a restriction on > >> calling path not holding any lock. > >> 2 The binding to SCSI device tree makes code complex, while at the same > >> time doesn't bring us any benefit. All ACPI handlings are still done > >> in ATA module, not in SCSI. > >> > >> Rework the ATA ACPI binding code to bind ACPI handle to ATA transport > >> devices(ATA port and ATA device). The binding needs to be done only once, > >> since the ATA transport devices do not go away with hotplug. And due to > >> this, the flush_work call in hotplug handler for ATA bay is no longer > >> needed. > > > > I like it but am wondering why we weren't doing this before. Was the > > acpi support added before we made ata objects proper devices? > > I think so. But since I didn't do the original binding, I can only guess > :-) > > At the time of the original binding, ACPI binding logic requires the > binding device has a bus type, which these ATA transport devices don't > have. > > Later, the ACPI binding code evolves and no such limitation exists > anymore. As you can see, we can simply set the ACPI handle before this > device is added in driver core, and the binding will be done. Yeah, we made that change in the ACPI core around 3.8 IIRC. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
