On Di 06. Mai - 12:24:11, Henrique de Moraes Holschuh wrote: > On Tue, 06 May 2008, Holger Macht wrote: > > On Di 06. Mai - 11:33:16, Holger Macht wrote: > > > On Di 06. Mai - 17:23:31, Shaohua Li wrote: > > > > On Tue, 2008-05-06 at 17:15 +0800, Holger Macht wrote: > > > > > On Mo 05. Mai - 22:25:08, Holger Macht wrote: > > > > > > If acpi_install_notify_handler() for a bay device fails, the bay > > > > > driver is > > > > > > superfluous. Most likely, another driver (like libata) is already > > > > > caring > > > > > > about this device anyway. Furthermore, > > > > > > register_hotplug_dock_device(acpi_handle) from the dock driver must > > > > > not be > > > > > > called twice with the same handler. So clean up and exit. > > > > > > > > > > The patch needs some more work. I'll send an updated one as soon as > > > > > ready. > > > > The bay driver is duplicated with libata, I thought we should delete it. > > > > See bug http://bugzilla.kernel.org/show_bug.cgi?id=9526 > > > > > > Yes, I know, but couldn't it be helpful on systems not using libata? > > > > Also, libata has to be patched to execute ACPI _EJ0 (not a huge issue, I > > know) or calling bay's eject_removable drive method. > > It *is* a huge issue. I think that currently, bay handling on thinkpads > is broken because of it, and users that expect it to just work could > well fry their hardware if they're the sort of people who don't LOOK at > the bay light before they yank stuff from it :-) > > This is not a bug report, but a head's up. I am at 2.6.23, so I didn't > test for the bug yet. > > Anyway, when you bind to an ACPI node, you forbid anything else from > doing it. This means it is now your problem to handle **ALL** > capabilities of that node. This means libata MUST handle ejection, or > it MUST NOT bind to an ACPI node. I fully agree. With "not a huge issue", I rather meant that coding this two lines of code is pretty easy ;-) Regards, Holger -- 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
