On Thu, Apr 10, 2014 at 11:24:49PM +0300, Philippe De Swert wrote: > Hi all, > > On first sight it seems that the two things in the subject have > nothing to do with each other, so I will quickly explain why they do > (at least for me). So for some time already I have been working on > usb_moded, which is a small daemon which handles setting up gadget > drivers, so that a device can offer several different levels of > functionality (for this it is also capable of setting up network and > start/stop services over dbus/systemd/upstart when needed) > > Now I would like to add support for the new gadgetfs. And there I > run into two issues. > > 1. It seems that libusbg from Matt Porter seems the library to use. > Is that correct? I saw patches on the mailing list, but they did not > seem to have made it to: https://github.com/libusbg/libusbg I think it's the right choice. :) As of last week, all but the latest two series that have been posted have been merged to master as I work through some backlog in my copious spare time. > Is this the correct place, and should patches be sent to the mailing > list here? I also pushed it through a coverity scan already and have > a nice to do list. Yes, please post patches here. Bug fixes and new features are very welcome. On my TODO list is to update docs to explain submitting patches should occur on this list so we get wider code review. That's how we've been doing things so far. > 2. I am playing around on a ATSAM5D36-EK and I tried to use that as > a testing platform. Now the USB udc etc works fine. But there is no > real way to detect the insertion of a cable. Most udc drivers seem > to track vbus but this is not exposed. So I added a vbus attribute > to the base udc, but this only works when a gadget driver is > actually loaded. So as long as a gadget is active I can see the > attribute change. (A possible work-around would be a gadget driver > just to detect vbus, but that is a bit insane) > > What would be the best way to track cable insertion and expose it in > some way? As in this case I cannot short-cut it by using a > power_supply class type of device. And just to be sure I would like > to find a way that would be acceptable upstream. An extcon driver would be appropriate. It's specifically meant for this use case. You can then monitor the state of your USB cable with sysfs or uevents from userspace. -Matt -- 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
