Re: f_loopback's new problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/02/2015 06:49 AM, Peter Chen wrote:
On Fri, Oct 30, 2015 at 10:28:09AM +0100, Krzysztof Opasiak wrote:


On 10/30/2015 08:31 AM, Peter Chen wrote:
Hi Krzysztof and Felipe,

With commit (91c42b0d usb: gadget: loopback: Fix looping back logic
implementation), the gadget loopback supports real loopback function
that is read data from the host, and them send the same data back.

But it breaks the testing function between f_loopback and usbtest,
usbtest does not expect the data will be back from opposite endpoint,
and our documentation (Documentation/usb/gadget-testing.txt) also
says we can use usbtest to test f_loopback.

How about supports old function as well as loopback function at the
same time?

Personally I don't agree with this approach. Loopback function had
been working until commit:

e0857ce usb: gadget: loopback: don't queue requests to bogus endpoints
dated: Mon Oct 13 15:30:52 2014 -0500

After that it began to behave like /dev/null and /dev/zero so it was
more like SourceSink. Then commit:

ec91aff7 Documentation: usb: LOOPBACK function testing
dated: Tue Dec 16 14:56:31 2014 +0100

added entry in documentation about testing the Loopback function but
in that time this function was not working correctly. Then with my
commit:

91c42b0 usb: gadget: loopback: Fix looping back logic implementation
dated: Wed Oct 14 22:49:40 2015 +0200

I have fixed loopback function so now it working now as it was
working before e0857ce. This time line shows that the documentation
has been added when function was not really working. So in my humble
opinion the broken part is the documentation and that's the place
for fix (and update testusb.c if you would like to use it for
testing loopback function).

I don't want to break the some usb tests I added which
can test the maximum USB throughput for bulk.


Is there any reason why didn;t you use SourceSink function which can
work exactly like loopback did before the fix (/dev/zero /dev/null)?


The SourceSink has only one request in queue, the performance is poor


Hmm so maybe it would be a good idea to add qlen param to SourceSink function?;) This should fix the performance problem
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux