Comments about commit 'PCI: docking station: remove dock uevents'?

Comments about commit 'PCI: docking station: remove dock uevents'?

[Holger Macht]

Hi,

> commit 5669021e40964303994a20633548732c6bb26636
> Author: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
> Date:   Tue Aug 1 14:59:19 2006 -0700
>
>     PCI: docking station: remove dock uevents
>
>     Remove uevent dock notifications.  There are no consumers
>     of these events at present, and uevents are likely not the
>     correct way to send this type of event anyway.
>
>     Until I get some kind of idea if anyone in userspace cares
>     about dock events, I will just not send any.
>
>     Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

I'm currently looking at docking station support for various
laptops/vendors and what can be done to get them working. At the moment,
userspace has to do some quirks to get support for them. For instance,
when docking an X60 into a docking station where a SATA DVD drive is
located, userland has to rescan the scsi host for the drive to show up. So
I need a notification from the kernel on dock/undock events. Currently I'm
using the ibm_acpi driver to either get the ibm/hotkey or the ibm/dock
event. Due to the fact that I also want to support other laptops and
because of the existance of a common dock station driver, I'm considering
to use it. A notification is of course only needed if triggering something
in userspace is the right way to go at all. So if ideally everything
should happen inside the kernel anyway, please tell me. In this case maybe
I will have a look at the kernel and will use ibm_acpi meanwhile. However,
if it's possible to readd the notification, I could just skip the ibm_acpi
way for docking and could use the common driver. Maybe it even shouldn't
be done via uevent, maybe an acpi event is enough?

Additionally, currently the dock driver automatically executes the _DCK
method when it detects a dock/undock event. Wouldn't it be good to have
common sysfs interface for docking so that userland can trigger the
dock/undock? This way userland would also be able to do 'something before'
docking/undocking, such as unregistering a device, showing a poput that it
is now save to physically undock, etc.

Regards,
	Holger

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Matthew Garrett]

On Sun, Nov 12, 2006 at 03:07:37PM +0100, Holger Macht wrote:

> I'm currently looking at docking station support for various
> laptops/vendors and what can be done to get them working. At the moment,
> userspace has to do some quirks to get support for them. For instance,
> when docking an X60 into a docking station where a SATA DVD drive is
> located, userland has to rescan the scsi host for the drive to show up.

Does the docking not generate a bus rescan event on the SATA bus? If it 
does, it's just a special case of ACPI drive hotplugging. You can't do 
it reliably from userspace, but I think Kirsten has been looking at 
doing it properly in the kernel.

> Additionally, currently the dock driver automatically executes the _DCK
> method when it detects a dock/undock event. Wouldn't it be good to have
> common sysfs interface for docking so that userland can trigger the
> dock/undock? This way userland would also be able to do 'something before'
> docking/undocking, such as unregistering a device, showing a poput that it
> is now save to physically undock, etc.

When the dock contains a drive, I think there's possibly an argument in 
favour of this. Otherwise, the hardware should be able to deal with it - 
every ACPI-based dock I've played with has had some indication to inform 
the user that the device has disconnected.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Holger Macht]

On Mon 13. Nov - 12:14:37, Matthew Garrett wrote:
> On Sun, Nov 12, 2006 at 03:07:37PM +0100, Holger Macht wrote:
> 
> > I'm currently looking at docking station support for various
> > laptops/vendors and what can be done to get them working. At the moment,
> > userspace has to do some quirks to get support for them. For instance,
> > when docking an X60 into a docking station where a SATA DVD drive is
> > located, userland has to rescan the scsi host for the drive to show up.
> 
> Does the docking not generate a bus rescan event on the SATA bus? If it 

Maybe it does, I'll have to recheck.

> does, it's just a special case of ACPI drive hotplugging. You can't do 
> it reliably from userspace, but I think Kirsten has been looking at 
> doing it properly in the kernel.

What I'm doing at the moment (for about a week ;-) is to echo "- - -" to
/sys/class/scsi_host/host*/scan for all unoccupied hosts on a dock
event. And this works pretty good. But it's of course only a workaround if
the scsi bus generates an event.

> 
> > Additionally, currently the dock driver automatically executes the _DCK
> > method when it detects a dock/undock event. Wouldn't it be good to have
> > common sysfs interface for docking so that userland can trigger the
> > dock/undock? This way userland would also be able to do 'something before'
> > docking/undocking, such as unregistering a device, showing a poput that it
> > is now save to physically undock, etc.

With recent kernel I have to unregister from the drive from userspace to
prevent confusion about if the drive is still there or not.

> When the dock contains a drive, I think there's possibly an argument in 
> favour of this. Otherwise, the hardware should be able to deal with it - 
> every ACPI-based dock I've played with has had some indication to inform 
> the user that the device has disconnected.

Yes, this one has such an indicator, too. I just thought notifying
userspace could be helpful for other cases, that's why I'm asking for
comments.

Thanks,
	Holger

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Matthew Garrett]

On Mon, Nov 13, 2006 at 08:43:27PM +0100, Holger Macht wrote:

> What I'm doing at the moment (for about a week ;-) is to echo "- - -" to
> /sys/class/scsi_host/host*/scan for all unoccupied hosts on a dock
> event. And this works pretty good. But it's of course only a workaround if
> the scsi bus generates an event.

That's just about workable for adding a device, but it loses badly for 
removing one.

> With recent kernel I have to unregister from the drive from userspace to
> prevent confusion about if the drive is still there or not.

Right. And that doesn't help in the case where the user undocks without 
waiting for everything to stop flashing first. Of course, in that case 
it's probably reasonable to tell the user that they lose, but we can do 
better than leaving a random drive lying around and a partially wedged 
sata bus...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Kristen Carlson Accardi]

On Mon, 13 Nov 2006 12:14:37 +0000
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Sun, Nov 12, 2006 at 03:07:37PM +0100, Holger Macht wrote:
> 
> > I'm currently looking at docking station support for various
> > laptops/vendors and what can be done to get them working. At the moment,
> > userspace has to do some quirks to get support for them. For instance,
> > when docking an X60 into a docking station where a SATA DVD drive is
> > located, userland has to rescan the scsi host for the drive to show up.
> 
> Does the docking not generate a bus rescan event on the SATA bus? If it 
> does, it's just a special case of ACPI drive hotplugging. You can't do 
> it reliably from userspace, but I think Kirsten has been looking at 
> doing it properly in the kernel.

When you use the "bay" driver in addition to the "dock" driver (bay is 
in -mm right now) you would get a notification on dock/undock in the driver
which would then cause the bay driver to notify user space about the 
drive event.  I've not found any other devices that require user space
notification.

> 
> > Additionally, currently the dock driver automatically executes the _DCK
> > method when it detects a dock/undock event. Wouldn't it be good to have
> > common sysfs interface for docking so that userland can trigger the
> > dock/undock? This way userland would also be able to do 'something before'
> > docking/undocking, such as unregistering a device, showing a poput that it
> > is now save to physically undock, etc.
> 
> When the dock contains a drive, I think there's possibly an argument in 
> favour of this. Otherwise, the hardware should be able to deal with it - 
> every ACPI-based dock I've played with has had some indication to inform 
> the user that the device has disconnected.

I think there is an arguement in favor of this, but there are more arguments
in favor of not waiting for user space before executing the acpi _DCK to
undock - mainly because not all dock stations actually lock the laptop
in the dock, and so the user is going to just do it anyway.  by undocking
as soon as we get the hardware notification, we can at least clean up
after this activity.  Also, most people who have commented on my bay driver
(which does assume user space handles the actual eject) have complained
about the fact that I wait for user space.  they general feedback I've gotten
is that these activities should "just happen" and not require user intervention.


> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Holger Macht]

On Mon 13. Nov - 19:50:25, Matthew Garrett wrote:
> On Mon, Nov 13, 2006 at 08:43:27PM +0100, Holger Macht wrote:
> 
> > What I'm doing at the moment (for about a week ;-) is to echo "- - -" to
> > /sys/class/scsi_host/host*/scan for all unoccupied hosts on a dock
> > event. And this works pretty good. But it's of course only a workaround if
> > the scsi bus generates an event.
> 
> That's just about workable for adding a device, but it loses badly for 
> removing one.

On before physically removing the laptop I did an echo 1 >
/sys/.../device/delete . That's actually the reason why I need a undock
event in userspace for now.


> > With recent kernel I have to unregister from the drive from userspace to
> > prevent confusion about if the drive is still there or not.
> 
> Right. And that doesn't help in the case where the user undocks without 
> waiting for everything to stop flashing first. Of course, in that case 
> it's probably reasonable to tell the user that they lose, but we can do 
> better than leaving a random drive lying around and a partially wedged 
> sata bus...

User presses lever on dock station or presses Fn+F9 on a thinkpad
generates a undock acpi event, then I'm unregistering the device, then I
trigger the undock from userspace and at this point the indicator on the
dock station turns green so the user knows that he can remove the laptop.

Regards,
	Holger

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Kristen Carlson Accardi]

On Mon, 13 Nov 2006 20:57:40 +0100
Holger Macht <hmacht@suse.de> wrote:

> On Mon 13. Nov - 19:50:25, Matthew Garrett wrote:
> > On Mon, Nov 13, 2006 at 08:43:27PM +0100, Holger Macht wrote:
> > 
> > > What I'm doing at the moment (for about a week ;-) is to echo "- - -" to
> > > /sys/class/scsi_host/host*/scan for all unoccupied hosts on a dock
> > > event. And this works pretty good. But it's of course only a workaround if
> > > the scsi bus generates an event.
> > 
> > That's just about workable for adding a device, but it loses badly for 
> > removing one.
> 
> On before physically removing the laptop I did an echo 1 >
> /sys/.../device/delete . That's actually the reason why I need a undock
> event in userspace for now.
> 
> 
> > > With recent kernel I have to unregister from the drive from userspace to
> > > prevent confusion about if the drive is still there or not.
> > 
> > Right. And that doesn't help in the case where the user undocks without 
> > waiting for everything to stop flashing first. Of course, in that case 
> > it's probably reasonable to tell the user that they lose, but we can do 
> > better than leaving a random drive lying around and a partially wedged 
> > sata bus...
> 
> User presses lever on dock station or presses Fn+F9 on a thinkpad
> generates a undock acpi event, then I'm unregistering the device, then I
> trigger the undock from userspace and at this point the indicator on the
> dock station turns green so the user knows that he can remove the laptop.
> 
> Regards,
> 	Holger

Brandon is working on adding a sysfs interface to the dock driver right
now.  We have so far only added a read only parameter that will display
the dock status, however, it is possible to add a sysfs entry that would
allow the user to undock by writing to it.  

Brandon, can you add this to your sysfs patch?

Thanks,
Kristen

Re: Comments about commit 'PCI: docking station: remove dock uevents'?

[Holger Macht]

On Mon 13. Nov - 11:54:23, Kristen Carlson Accardi wrote:
> On Mon, 13 Nov 2006 12:14:37 +0000
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > On Sun, Nov 12, 2006 at 03:07:37PM +0100, Holger Macht wrote:
> > 
> > > I'm currently looking at docking station support for various
> > > laptops/vendors and what can be done to get them working. At the moment,
> > > userspace has to do some quirks to get support for them. For instance,
> > > when docking an X60 into a docking station where a SATA DVD drive is
> > > located, userland has to rescan the scsi host for the drive to show up.
> > 
> > Does the docking not generate a bus rescan event on the SATA bus? If it 
> > does, it's just a special case of ACPI drive hotplugging. You can't do 
> > it reliably from userspace, but I think Kirsten has been looking at 
> > doing it properly in the kernel.
> 
> When you use the "bay" driver in addition to the "dock" driver (bay is 
> in -mm right now) you would get a notification on dock/undock in the driver
> which would then cause the bay driver to notify user space about the 
> drive event.  I've not found any other devices that require user space
> notification.

Ok, thanks for the pointer, I'll have a look at it.

Regards,
	Holger

> 
> > 
> > > Additionally, currently the dock driver automatically executes the _DCK
> > > method when it detects a dock/undock event. Wouldn't it be good to have
> > > common sysfs interface for docking so that userland can trigger the
> > > dock/undock? This way userland would also be able to do 'something before'
> > > docking/undocking, such as unregistering a device, showing a poput that it
> > > is now save to physically undock, etc.
> > 
> > When the dock contains a drive, I think there's possibly an argument in 
> > favour of this. Otherwise, the hardware should be able to deal with it - 
> > every ACPI-based dock I've played with has had some indication to inform 
> > the user that the device has disconnected.
> 
> I think there is an arguement in favor of this, but there are more arguments
> in favor of not waiting for user space before executing the acpi _DCK to
> undock - mainly because not all dock stations actually lock the laptop
> in the dock, and so the user is going to just do it anyway.  by undocking
> as soon as we get the hardware notification, we can at least clean up
> after this activity.  Also, most people who have commented on my bay driver
> (which does assume user space handles the actual eject) have complained
> about the fact that I wait for user space.  they general feedback I've gotten
> is that these activities should "just happen" and not require user intervention.
> 
> 
> > 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html