All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn-yOkvZcmFvRU@public.gmane.org>
To: Yauheni Kaliuta <y.kaliuta-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Greg Suarez <gsuarez-AKjrjAf1O7qe8kRwQpwjMg@public.gmane.org>,
	Alexey Orishko
	<alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
	Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Subject: Re: [PATCH net 2/3] net: cdc_mbim: send ZLP after max sized NTBs
Date: Mon, 21 Jan 2013 23:01:59 +0100	[thread overview]
Message-ID: <87hamab3fs.fsf@nemi.mork.no> (raw)
In-Reply-To: <87wqv64gr9.fsf-jZyLUQyd5ymekGDzARDqUg@public.gmane.org> (Yauheni Kaliuta's message of "Mon, 21 Jan 2013 18:56:10 +0200")

Yauheni Kaliuta <y.kaliuta-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>> "BM" == Bjørn Mork writes:
>
>  > We normally avoid sending ZLPs by padding NTBs with a zero byte
>  > if the NTB is shorter than dwNtbOutMaxSize, resulting in a short
>  > USB packet instead of a ZLP.  But in the case where the NTB length
>  > is exactly dwNtbOutMaxSize and this is an exact multiplum of
>  > wMaxPacketSize, then we must send a ZLP.
>
> The idea of NCM was to avoid extra ZLPs. If your transfer is exactly
> dwNtbOutMaxSize, it's known, you can submit such request on the receiver
> side and you do not need any EOT indicatation, so the frametime can be
> used for useful data.

Yes, that makes sense.  And I understand that both you and Alexey are of
this opinion.

But this idea is by no means made clear (to me) in the spec.  I do not
think the current wording is precise enough to expect every implementor
to understand any such intent.  The only place I find either "short
packet" or ZLP mentioned in the NCM spec is in tables 3-1 and 3-2,
describing the 16bit and 32bit NTH formats, in the description of the
(d)wBlockLength fields.  And even there it is only mentioned in the
context of the special (d)wBlockLength = 0x0000 handling.

If the intent was to prevent ZLPs, then it would have been wise to write
that in the NCM standard. As it stands you have to use a lot of
imagination to read that intent into the current spec.

> I didn't check MBIM specs, but I guess, it wasn't changed. But better get
> Alexey's answer for sure.

No, there are no changes to this area in the MBIM spec AFAIK, so
whatever is correct for NCM is also correct for MBIM.  The question is
what is correct for NCM.

>  > This fixes an issue seen on a Sierra Wireless MC7710 device
>  > where the transmission would fail whenever we ended up padding
>  > the NTBs to max size.
>
> Is it buggy?

That is not unlikely. However, if so then it is buggy in a way we just
have to deal with because Windows does...

But before claiming this to be a bug I would like to understand how we
have come to this conclusion that NCM and MBIM devices should not need
ZLPs.  I agree that it would have made sense to have such a requirement,
but I cannot find it in the spec.

I would also like to know how Windows works around this issue, because I
am pretty confident that this device works with Windows 8.  If it didn't
then the firmware wouldn't have been flagged for release, and it is.  It
is even distributed by 3rd party integrators (aka laptop vendors).



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2013-01-21 22:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21 15:50 [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8 Bjørn Mork
2013-01-21 15:50 ` [PATCH net 1/3] net: cdc_ncm: workaround for missing CDC Union Bjørn Mork
2013-01-21 15:50 ` [PATCH net 2/3] net: cdc_mbim: send ZLP after max sized NTBs Bjørn Mork
     [not found]   ` <1358783440-11459-3-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2013-01-21 16:31     ` Alexey ORISHKO
2013-01-21 22:36       ` Bjørn Mork
     [not found]       ` <2AC7D4AD8BA1C640B4C60C61C8E520154A8EE17D57-8ZTw5gFVCTjVH5byLeRTJxkTb7+GphCuwzqs5ZKRSiY@public.gmane.org>
2013-01-22  9:54         ` Bjørn Mork
2013-01-22 15:51           ` Alexey ORISHKO
2013-01-21 16:56     ` Yauheni Kaliuta
     [not found]       ` <87wqv64gr9.fsf-jZyLUQyd5ymekGDzARDqUg@public.gmane.org>
2013-01-21 22:01         ` Bjørn Mork [this message]
2013-01-22 17:16           ` Yauheni Kaliuta
     [not found] ` <1358783440-11459-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2013-01-21 15:50   ` [PATCH net 3/3] net: cdc_ncm: fix error path for single interface probing Bjørn Mork
2013-01-22  8:58     ` Oliver Neukum
2013-01-22 10:32       ` Bjørn Mork
2013-01-21 19:22 ` [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8 David Miller
2013-01-21 19:42   ` Alexey ORISHKO
2013-01-21 20:16     ` Bjørn Mork
2013-01-21 20:34       ` Alexey Orishko
2013-01-21 22:12         ` Bjørn Mork

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=87hamab3fs.fsf@nemi.mork.no \
    --to=bjorn-yokvzcmfvru@public.gmane.org \
    --cc=alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
    --cc=gsuarez-AKjrjAf1O7qe8kRwQpwjMg@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=oneukum-l3A5Bk7waGM@public.gmane.org \
    --cc=y.kaliuta-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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.