On Wed, 27 Jul 2011 14:29:05 +0200 Michal Nazarewicz <mina86@xxxxxxxxxx> wrote: > On Wed, 27 Jul 2011 14:17:28 +0200, jacob pan > <jacob.jun.pan@xxxxxxxxx> wrote: > > my goal is to inform userspace the connection status of otg port > > such that user can make a decision on which gadget role he wants to > > use for the device. It seems these ffs_data_xxx functions cannot > > definitively tell the connection state. I guess i may have to add > > uevents to the UDC driver or OTG transcriver driver. But it would > > not be a generic solution as functionfs. > > ffs_data_*() only inform you about the state of FunctionFS being > changed. Namely that some userspace process started configuration or > closed all files thus stopping using FunctionFS. This is not related > to being or not being connected to host/(otg-)device. > > Recently posted (and merged I believe) UDC class provides uevents when > a gadget driver is loaded (such as g_ffs or g_ether) but that again > does not inform about the state of connection. > > I guess your best bet would be to look at composite.c and adding > uevents somewhere there as it proxies communication on ep0 thus also > connections and such. This, obviously, will only work for composite > gadgets though (both g_ffs and g_ether are composite gadgets). > the problem is that if for some reason, once connected, windows host does not start the setup process, composite driver still may not get informed. it happened on my win7 host when it sees ffs composite device, it does not recognize the device does not initiate setup (e.g. set_alt) > If you are interested in just being connected, there may be some other > place to look at, which I'm unaware of. One way I can think of is > always having a “fake” g_mass_storage which would report a single > ejected LUN and monitoring when hosts sets configuration on it. > Again, someone may know a better solution for this though. > this a good idea for the idle case to load fake mass storage gadget. but i do need to know state of being disconnected. perhaps once we have a generic otg state machine, it can emit uevent and allow a more generic solution. -- Thanks Jacob -- 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
