Hi, On Thu, Jul 26, 2012 at 01:23:01AM +0200, Laurent Pinchart wrote: > Hi Bhupesh, > > 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. 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
