On Thu, 15 Mar 2007 16:31:24 -0300 Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > > I think we should focus our efforts on a generic (non platform specific) > > solution that can work across many laptops (i.e. ACPI_BAY). Let's make > > Agreed, as long as that doesn't mean we have to pollute ACPI_BAY with a > truckload of crap required to deal with vendor/model-specific idioticities. > I hope ThinkPads are not like that, but I am not sure, and I'd feel bad > about adding a lot of quirks to ACPI_BAY because of ThinkPad weirdness :p So for the dock driver I supplied an interface to allow interested subsystems to register handlers to be called by the dock driver during dock events. This allowed me to let individual subsystems do whatever unique things they needed to do when the dock was either inserted or removed. For the bay driver, we could actually provide a mechanism to allow platform specific drivers to take advantage of the generic stuff, but then have the bay driver call a registered handler to do some weird specific thing - this way at least we are sharing the bulk of our code and weird stuff can be contained somewhere else. > > Otherwise, it would be best to allow model-specific modules to provide extra > functionality for ACPI_BAY, that way we have generic code, and we can > contain the braindamage to where it belongs (e.g. in ibm-acpi). > > > so if you do have time to work on this, that would be great. I am happy > > to test on the set of laptops I've got. > > I will see what I can do. My "first approach" at a requirements list for a > proper bay module are as follows: > > 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > > 2. It will do the right thing on plug and unplug. This means telling the > rest of the kernel to disable the device in the bay, for example. Right now > we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > leave libata to scream blood murder until it disables its end due to too > many retries, for example; Personally - I think tighter integration to libata here would be beneficial. Once libata acpi support is straightened out, if we can store acpi handles associated with libata devices, we can perhaps have a mechanism of obtaining ata_device structs so that we can have a nice way of telling libata to delete devices etc. I am hoping libata-acpi will be straightened out for 2.6.22. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
