Re: hub port power control vs. physical disconnect/connect

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
On Wed, 12 Dec 2007, Vlado Handziski wrote:

> Hi all,
> 
> To properly clean the internal state in the kernel modules, we are
> currently manually unbinding the usb module attached to a hub port
> device using sysfs before issuing a port power control command to a
> hub using libusb. This is workig quite well, but it looks like the
> removal of the actual port device is deferred until the port power on
> command. When doing physical connect/disconnect this is not the case.
> So what are we missing?  Is there a way to make the port power control
> behave the same (create same sequence of UEVENTs) like in physical
> connect/disconnect. Maybe some way to call usb_disconnect() in hub.c
> from userspace?

The USB stack doesn't remove a device until it gets a disconnect
message from the device's hub.  When you turn off the port power the 
hub doesn't send any disconnect messages, so the kernel doesn't realize 
the device is gone.

Currently there is no way for you to force this behavior (and there is 
no way to call usb_disconnect from userspace).  You can come close by 
unbinding the device's driver.  For example, if the device's sysfs ID
was 1-2.3 you would do:

	echo -n 1-2.3 >/sys/bus/usb/drivers/usb/unbind

That won't remove the device structure but it will make the structure 
almost unusable.

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.