Re: [PATCH] usb: misc: usbtest: fix pattern tests for scatterlists.

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

 



Hi

Peter Chen <hzpeterchen@xxxxxxxxx> writes:
> On Tue, May 03, 2016 at 12:31:21PM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Peter Chen <hzpeterchen@xxxxxxxxx> writes:
>> > On Mon, May 02, 2016 at 11:39:03AM +0300, Mathias Nyman wrote:
>> >> The current implemenentation restart the sent pattern for each entry in
>> >
>> > %s/implemenentation/implementation
>> >
>> >> the sg list. The receiving end expects a continuous pattern, and test
>> >
>> > The f_sourcesink may not expect that, have you tried it?
>> 
>> Use the sources, Luke.
>> 
>
> Sorry, what do you mean ? is it a special device?
>
> At Documentation/usb/gadget-testing.txt, sourcesink uses usbtest to
> test.

Well, f_sourcesink implements the same protocol that an old NEC test
device implemented (IIRC), but anyway, both f_sourcesink and usbtest are
open source and shipped with the kernel. You can check all assumptions
made by both sides.

In any case, the gadget driver *has* to assume a continuous pattern
without any breaks otherwise it needs to agree with the host what the
pattern will be before doing any transactions.

To make the problem slightly clearer, when we pass pattern=1 to *both*
g_zero and usbtest, we're using a mod63 pattern. Buffers should be
initialized like so:

	for_each_byte_in_buffer(i)
		buf[i] = (i % wMaxPacketSize) % 63;
	
When using sg lists, the initialization is slightly different:

	for_each_sg(sglist)
        	for_each_byte_in_sg_buffer(i)
                	buf[i] = (i % wMaxPacketSize) % 63;

From this, it's clear to see that pattern would restart from 0 at every
sg entry. This means that gadget side's checks (which, at least as of
now, always uses linear buffer), would fail.

That's why we need to keep track of
total_size_of_all_previously_initialized_sg_entries, so that we can
continue the pattern where it stopped on previous entry, rather than
restarting from 0 every time.

All this to say that your previous argument:

>> > The f_sourcesink may not expect that, have you tried it?

Is wrong in two details:

a) we have certainly tested. How else would we find the problem ?
b) f_sourcesink *must* make the assumption of a continuous pattern with
   no breaks and/or cuts anywhere.

hope this answers your question.

cheers

-- 
balbi

Attachment: signature.asc
Description: PGP signature


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

  Powered by Linux