Re: [ibm-acpi-devel] CONFIG_IBM_BAY

Henrique de Moraes Holschuh
2007-03-19T23:11:27Z

On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote:
> On Mon, 19 Mar 2007 15:37:46 +0100
> Holger Macht <hmacht@suse.de> wrote:
> > Sure. What actually bothers me is that in its current state, the dock
> > station driver signals 'green' on the dock station as soon as the user
> > presses the hardware undock button, but regardlessly of anything else. I
> > think it would be ok to let the ACPI undock event up to userspace because
> > in many situations it knows best when it is save to undock.
>
> I disagree - as I mentioned, not all laptops actually let you (userspace)
> control the undock process because they don't lock. The dock driver
> does notify user space of an undock, before it actually undocks:
>
> /*
> * here we need to generate the undock
> * event prior to actually doing the undock
> * so that the device struct still exists.
> */
> dock_event(ds, event, UNDOCK_EVENT);
> hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST);
> undock(ds);
> eject_dock(ds);
>
>
> We even notify other subsystems of our intent to undock prior to actually
> doing it.

The above does not support two-stage-capable (i.e. non-braindamaged)
hardware docks properly. While a two-stage (notify always, but undock only
if userspace (or another kernel module) tells you to) can support both
two-stage and broken-as-designed single-stage docks.

You can either let a machine-specific module (e.g. ibm-acpi) generate the
"undock immediately" functionality if the machine has a single-stage dock,
or let userspace do it, or even use black/whitelists on the dock module if
you want... but please give us the two-stage undock support.

--
"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