Message-ID: <87fvts28y0.fsf@nemi.mork.no>
Date:	Thu, 29 Aug 2013 10:32:55 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	David Miller <davem@...emloft.net>
Cc:	robmatic@...il.com, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, oliver@...kum.org
Subject: Re: [PATCH net,stable] net: usb: Add HP hs2434 device to ZLP exception table

David Miller <davem@...emloft.net> writes:

> From: Rob Gardner <robmatic@...il.com>
> Date: Wed, 28 Aug 2013 18:40:22 -0600
>
>> The exception list means "usb_device_id entries for specific devices
>> that are known to need the workaround." There are just two such entries.
>> There isn't even a separate list. So maybe we just have a nomenclature
>> problem, and we could simply be calling this a "white list" instead of
>> "exception list". The other possible meaning of whitelist (all devices
>> that *don't* need the workaround) is unthinkable, as that would be a huge
>> list and much more prone to be unmanageable than what we've got now.
>
> Ok I misunderstood.  I thought we were discoving that all chips which
> have been thoroughly investigated end up needing the workaround.
>
> I guess it's only a specific family of these chips which seem to all
> have the problem?

This driver is a class driver, which means that it deals with a number
of completely independent chip designs from different vendors.  We have
so far seen and tested chips from ST-Ericsson, Qualcomm and Mediatek
with this driver.  Given that Microsoft requires MBIM, we are likely to
see implementations on all available 3G/LTE chips (if there are any
others?)

Only devices with Qualcomm chips have the bug in question, and so far we
have only observed it in modules made by Sierra Wireless. The firmware
in these modules has a base part made by Qualcomm and an application
part made by Sierra Wireless.  We do not know which part of the firmware
is responsible for the bug, but we do know that the Qualcomm base
firmware used by these modules support MBIM framing.  Based on this, I
am guessing that the chip vendor Qualcomm is responsible for the bug. If
correct, then the bug is likely to appear in products from many
different module vendors.  It would not be the first time we saw that...

I do have a Huawei MBIM device with a Qualcomm chip, but this module
does not have the Qualcomm firmware with MBIM support. The MBIM
implementation is therefore assumed to be made by Huawei and running as
a firmware application on the device.  This device does not have the bug.

Now, if we could just identify devices running a Qualcomm base firmware
with MBIM support then we could enable the workaround for all those. But
the driver does not have any way to identify them.  It must base its
decision on the USB descriptors, in practice only device ID and product
ID. A module vendor can use chips from different sources (Huawei does
this), and as Rob says: Laptop vendors will often have modules made with
their own vendor ID. Most laptop vendors will also use modules from
different vendors.  HP, as a current example, is known to use modules
both from Sierra Wireless (need the workaround) and Ericsson (does not
want the workaround).

This makes any sort of vendor matching difficult, and we end up with
device specific blacklisting or whitelisting as the only option.  If it
had been only the two devices we have now, or even only a few tens of
devices, this would not have been a big deal.  But I do expect that the
length of this exception list will be comparable to the list of devices
supported by the qmi_wwan driver, i.e. hundreds.  And, like that driver,
the list will probably never be complete. Given the difficulties
detecting the need for the workaround, the list is probably going to be
extremely incomplete. Only a small percentage of end users with affected
devices will be able to provide the necessary information.

For the question of the workaround impact on devices without bug: They
will work fine, and the effect will not be user noticable AFAICS.  But
it will have a negative impact on the device, most likely causing higher
power consumption. Alexey has explained this much better than I can, as
I do not fully understand the device firmware design and requirements:
http://www.spinics.net/lists/linux-usb/msg78078.html

Quoting part of his explanation (talking about the *device* CPU and
INT - we do not care about the host):

  If host decides to send ZLP after full NTB, CPU must handle
  additional INT per every full NTB instead of doing useful work.
  For FTP transfer with constantly full NTBs you get twice amount of
  Interrupts.

I do agree that this is unfortunate. And hurting standard compliant
devices to work around a standard violating bug in other devices does
not feel right.  But I do not see any other option.



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

Powered by blists - more mailing lists