All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org
Subject: usb: usbtest: Add TEST 29, toggle sync, Clear toggle between bulk writes
Date: Fri, 15 Dec 2017 10:59:33 +0200	[thread overview]
Message-ID: <87r2rwl62y.fsf@linux.intel.com> (raw)

Hi,

Mathias Nyman <mathias.nyman@linux.intel.com> writes:
> On 14.12.2017 20:12, Alan Stern wrote:
>> On Thu, 14 Dec 2017, Mathias Nyman wrote:
>> 
>>> Clear Feature Endpoint Halt should reset the data toggle even if the
>>> endpoint isn't halted. Host should manage to clear the host side data
>>> toggle to keep in sync with the device.
>>>
>>> Test by sending a "3 data packet URB" before and after clearing the halt.
>>> this should create a toggle sequence with two consecutive DATA0 packets.
>>>
>>> A successful test sequence looks like this
>>>      ClearFeature(ENDPOINT_HALT) - initial toggle clear
>>>    DATA0 (max packet sized)
>>>    DATA1 (max packet sized)
>>>    DATA0 (zero length packet)
>>>      ClearFeature(ENDPOINT_HALT) - resets toggle
>>>    DATA0 (max packet sized), if clear halt fails then toggle is DATA1
>>>    DATA1 (max packet sized)
>>>    DATA0 (zero length packet)
>>>
>>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>> 
>> This test is a little unusual in that it doesn't contain a way to
>> detect failures.  That is, you can't tell from the test results whether
>> the device and the host behaved the way they are supposed to (in the
>> case of the host, you could use a USB analyzer to find out).
>> 
>> Also, some devices don't handle Clear-Halt requests properly if the
>> endpoint isn't already halted.  Presumably people wouldn't use one of
>> those devices for this test!  :-)
>
> I was hoping that the device (dwc3 with zero gadget in my case) would
> somehow react if the host sends a DATA1 packet right after
> ClearFeature(ENDPOINT_HALT), but turns out this device accepts it and
> continues to work just fine. So I ended up looking at the traffic with

that's because we prevent clear halt when endpoint is not halted. That
was changed when a problem was found when enumerating against macOS. It
may be that we're actually hiding an IP bug by doing that, however I
never got an argument strong enough to revert the commit.

This, may just be the strong argument I need :-)

             reply	other threads:[~2017-12-15  8:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-15  8:59 Felipe Balbi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-12-15 17:02 usb: usbtest: Add TEST 29, toggle sync, Clear toggle between bulk writes Alan Stern
2017-12-15  8:49 Mathias Nyman
2017-12-15  8:20 Felipe Balbi
2017-12-14 18:12 Alan Stern
2017-12-14 16:39 Mathias Nyman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r2rwl62y.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.