On Fri, Mar 16, 2007 at 03:37:54PM -0700, David Brownell wrote:
> On Wednesday 14 March 2007 5:18 am, Li Yang wrote:
> > Apparently this gadget doesn't support setting usb_cdc_line_coding.
>
> It does support it ... but that support is buggy. It should be issuing
> a read request before doing the memcpy(); instead, it wrongly assumes
> that something else already issued the read.
>
> Plus, it doesn't correctly test for some error cases: port is null,
> there's not enough incoming data.
>
>
> > But the code pretends that it supports, and queues a zero length
> > request for the DATA phase. That will cause overflow for udc in
> > processing the DATA transaction. The patch make it return -EOPNOTSUPP
> > and stall cleanly.
>
> So, a workaround for the bug. Did you notice how the other SET
> request has the same bug?
>
> If you're not going to really fix this, please update the patch
> to address the same bug in the other path; and its description
> to say that you're replacing buggy code with an explicit failure.
>
> Best of course would be to fix the underlying bugs, since you
> clearly have a test setup and the fixes should be trivial, more or
> less
>
> if (wLength == right length) {
> update req->complete
> ret = right length
> }
>
> and providing new completion handlers which copy the data.
Ok, I've dropped this from my tree now, thanks.
Li, care to redo the patch?
thanks,
greg k-h
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
