On Wed, 07 May 2008, Shaohua Li wrote: > On Tue, 2008-05-06 at 22:13 -0300, Henrique de Moraes Holschuh wrote: > > On Wed, 07 May 2008, Shaohua Li wrote: > > > On Tue, 2008-05-06 at 12:18 -0300, Henrique de Moraes Holschuh wrote: > > > > On Tue, 06 May 2008, Shaohua Li wrote: > > > > > The bay driver is duplicated with libata, I thought we should delete it. > > > > > See bug http://bugzilla.kernel.org/show_bug.cgi?id=9526 > > > > > > > > The bay driver is currently useless, BUT it should handle a lot of stuff > > > > libata won't, such as bay batteries, bay floppies, and anything else in > > > > a bay that is not a hard disk. > > > > > > > > The fact that the driver currently looks only after disks is just a bug. > > > > It should, in fact, bind to any ejectable device not already handled by > > > > a different driver. > > > Isn't this the job of acpi dock driver? > > > > No, but I actually fail to see why do we even care about the difference > > from a dock to a bay. Dock *could* be made to handle both. > It appears some systems haven't a dock but a bay. In a thinkpad, you > could hotplug cdrom/battery/harddisk in the slot of cdrom, but it's not > a dock. libata should handle it well (but it doesn't handle _EJ0 > currently, I have a patch in above bugzilla). > > But you are right, acpi dock driver should be extended to support bay. > I'll give it a try. Thanks. Here's what I know about bays (and docks). I expect you know most, if not all of what I'll write, but what the heck, it is good to have these things in the clear :-) 1. Bay and dock notifications are NOT standard. You need to feed them to a notification chain AND generate uevents, and expect a reply before you can actually do something. There are two big classes of machines here: 1a) those which notify you that the bay/dock is BEING ejected 1b) those which notify you the user wants to eject, and wait for a command to power down the bay/dock and let the user know she can remove the device. Thinkpads are on the 1b class. See (4) below. 2. Even if a bay can take different types of devices, the same bay may appear as a number of different EJ0 handlers. In that case, the firmware is to know which handler to use based on which type of device is inside the bay. Thinkpads do this. 3. IMO, "eject" really should be a device property, and not something tied to a bay. For docks, this is a lot more difficult to do right, since a dock has multiple devices (and usually at least one BUS, and often more than one. Thinkpads have PCI, PCIe and USB buses through the dock) behind it, so it is probably best to have dock ejects as a property of a "dock" platform device, and bay ejects as a property of whatever device is inside the bay. This should be an userspace AND kernel API. 4. bay ejection notifications can take two forms (see (1) above): 4a) device removal (we already have this) 4b) device removal REQUEST Thinkpads should do 4b, then IF AND ONLY IF the user or a kernel platform driver uses (3) to command the ejection, they do 4a. Some laptops will just do 4a, doing (3) before the user yanks the device requires the user to not be an yahoo (i.e. just like USB pen-drives). And for laptops that do 4b for docks, one should probably replicate the "request undock" notification for every device inside the dock, and not just for the dock device. What value you get from an ACPI NOTIFY for 4a or 4b is NOT standard, you will need a platform device OR userspace to interpret it for you. 5. bay and dock notifications (at least on thinkpads) are issued to the ACPI node of the real device, not to the APCI EJ0 node. This is what is causing issues between bay and libata (both want to register a notify hook to the same node, and ACPICA allows only one driver per node). I am not really sure the "ACPI driver model" is the right way to tie bay functionality to the system. A hook and notifier system inside ACPICA to implement it as a service of the ACPI sybsystem might work better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
