On 12/05/2011 05:19 PM, Alan Stern wrote:
I am using the /g_file_storage/gadget driver. I was wondering if it is
possible to detect if a cable (and USB host) is connected to the USB
device port.
Looks like the driver prints the following message to dmesg when the
host is connected:
g_file_storage gadget: full speed config #1
This is really just a side effect. The gadget driver itself isn't very
aware of when the gadget is connected to a host. The UDC driver is
responsible for all that stuff.
For instance if plug the device into the host computer you see this
output once the driver is loaded. If the driver is not available (and
nobody can handle this function) you don't see any message.
But there is no message when it is disconnected. So how can I check the
current status of the connection. Is there some status file in sysfs I
can look at?
Any other possibility?
Felipe, Sebastian, this sounds like a good candidate for something to
be added to the UDC core framework. Perhaps a pollable sysfs file
containing the current connection/PHY status? The UDC driver would
merely have to invoke a new core routine whenever the status changed.
So what do we want?
We do have a disconnect callback (gadget_driver->disconnect) where the
udc driver should tell the gadget when we lost the link. So in theory
we know when we lost the link partner by force.
After the USB-Reset the udc-driver knows that it is connected again.
But a good cell phone or bad cables can lead a USB-Reset as well.
If you are connected to self-powered HUB and you re-plug it from one
computer to another the udc does only notice that something changed due
to the USB-Reset, right?
So I think looking at the speed attribute is the best thing we can do.
If we route a few callbacks through udc-core we could make speed
attribute poll able. Every speed change, results in re-enumeration and
this could be a cable plug.
Alan Stern
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
