On Thu, 23 Feb 2012 01:52:55 -0800, Felipe Balbi <balbi@xxxxxx> wrote:
What I mean is that host could be sending a request with the correct RECIP_INTERFACE but wrong ctrl->bRequest.
And so functions check value of ctrl->bRequest. f_rndis has a switch in rndis_setup() with two cases and a default handling invalid requests. Sorry, I might have misspoken. I meant that function does not need to check if request was directed to it. It of course still needs to check whether the request is valid. On Thu, 23 Feb 2012 01:52:55 -0800, Felipe Balbi <balbi@xxxxxx> wrote:
Besides, some of req->context changes could be done in a different way. In f_ncm.c for instance, it receives the Setup phase by using composite.c's request, but then it changes the setup phase request and requeues it to receive the data phase, and does nothing with the Status phase.
I'm lost here. f_ncm sets context just like Łukasz' patch tries to do in f_rndis and just like some other functions pointed earlier do: req->complete = ncm_ep0out_complete; req->length = w_length; req->context = f;
This is one of the places which causes the most confusion and the most problems when writing UDC drivers for linux. There's very little "standardization" on who/how should Setup/Data/Status phases be handled on the framework. It's pretty much a trial and error approach. I say again that the best solution would be to allow functions to queue their own requests to ep0, rather than re-using composite.c's request.
Maybe yes, maybe no. I might know too little to argue that but what I can say is that at the moment it's not how it's done however, f_rndis is broken, and needs a fix. As a matter of fact, maybe “cc: stable” for that patch is in order. Still, I'm not convinced that it is really required for each function to allocate its own request object. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +----<email/xmpp: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo-- -- 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
