Hi Felipe, On Thursday 26 July 2012 10:45:56 Felipe Balbi wrote: > On Thu, Jul 26, 2012 at 01:23:01AM +0200, Laurent Pinchart wrote: > > On Thursday 26 July 2012 00:12:46 Bhupesh SHARMA wrote: > > > On Wednesday, July 25, 2012 6:41 PM Laurent Pinchart wrote: > > > > On Wednesday 25 July 2012 15:06:37 Bhupesh SHARMA wrote: > > > > > > > > [snip] > > > > > > > > > It's been almost a month since this RFC was circulated. > > > > > As no comments have been received so far, > > > > > > > > http://www.spinics.net/lists/linux-usb/msg66755.html > > > > > > > > Mails get lost sometime. > > > : > > > :) > > > > > > No no, I went through your reply in detail but got confused by the line: > > > "The overall approach looks good. I'll let Felipe comment on the > > > details, > > > he's much more knowledgeable than me about UDC.", so I thought I need to > > > wait for Felipe, others to comment to take this further. > > > > > > Since it's been a long time now, I sent another mail to the list to seek > > > Felipe/other's comment on the same, so that we can finalize a approach. > > > > I would like to hear Felipe's opinion as well. > > Yeah, sorry for the delay. Here's the short answer: > > we need a generic way of exposing more control to userland, not to the > function drivers themselves. Tying ->pullup() to e.g. an open() call to > a device node is quite lame since a simple "cat /dev/XYZ" will keep the > device node open and you will have a broken device again. > > What I want is for userland to tell me when it's ready to handle > requests and thus tell me when to call pullup(). We decided to do that > via a configfs layer which will also help getting rid of all gadget > files and keep only f_*.c in kernel. Combinations of those will also be > done in userland which will give a much more flexible solution for users > such as Android and will prevent us from applying a huge amount of > nokia.c-like files just because this and that manufacturer users a > different set of functions. This sounds good in the long term. > Until then, I don't think we have a solution for this problem which > would work always and, in fact, I don't want to have such a solution > otherwise we will have to maintain it for the forseeable future. I don't agree with you here. The existing usb_gadget_disconnect() function is documented as * Disables the D+ (or potentially D-) pullup, which the host may see * as a disconnect (when a VBUS session is active). Not all systems * support software pullup controls. * * This routine may be used during the gadget driver bind() call to prevent * the peripheral from ever being visible to the USB host, unless later * usb_gadget_connect() is called. For example, user mode components may * need to be activated before the system can talk to hosts. In practice this doesn't work, calling usb_gadget_disconnect() during bind doesn't prevent the device from being visible to the USB host. That's what I think should be fixed, until the configfs-based solution is ready. We should of course not add any API to expose ->pullup() to userspace as an interim solution, as that one would need to be maintained. -- Regards, Laurent Pinchart -- 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
