Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 4月, 2017 1 次提交
  3. 25 1月, 2017 1 次提交
  5. 13 1月, 2017 1 次提交
  7. 03 12月, 2016 1 次提交
    • K
      cdc_ether: Fix handling connection notification · d5c83d0d
      由 Kristian Evensen 提交于 
      Commit bfe9b9d2 ("cdc_ether: Improve ZTE MF823/831/910 handling")
introduced a work-around in usbnet_cdc_status() for devices that exported
cdc carrier on twice on connect. Before the commit, this behavior caused
the link state to be incorrect. It was assumed that all CDC Ethernet
devices would either export this behavior, or send one off and then one on
notification (which seems to be the default behavior).

Unfortunately, it turns out multiple devices sends a connection
notification multiple times per second (via an interrupt), even when
connection state does not change. This has been observed with several
different USB LAN dongles (at least), for example 13b1:0041 (Linksys).
After bfe9b9d2, the link state has been set as down and then up for
each notification. This has caused a flood of Netlink NEWLINK messages and
syslog to be flooded with messages similar to:

cdc_ether 2-1:2.0 eth1: kevent 12 may have been dropped

This commit fixes the behavior by reverting usbnet_cdc_status() to how it
was before bfe9b9d2. The work-around has been moved to a separate
status-function which is only called when a known, affect device is
detected.

v1->v2:

* Do not open-code netif_carrier_ok() (thanks Henning Schild).
* Call netif_carrier_off() instead of usb_link_change(). This prevents
calling schedule_work() twice without giving the work queue a chance to be
processed (thanks Bjørn Mork).

Fixes: bfe9b9d2 ("cdc_ether: Improve ZTE MF823/831/910 handling")
Reported-by: NHenning Schild <henning.schild@siemens.com>
Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5c83d0d
  9. 19 10月, 2016 1 次提交
  11. 25 7月, 2016 1 次提交
    • K
      cdc_ether: Improve ZTE MF823/831/910 handling · bfe9b9d2
      由 Kristian Evensen 提交于 
      The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.

This patch tries to improve the handling of ZTE devices by doing the
following:

* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.

* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.

* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.

This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.

v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).

v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.

v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
Acked-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bfe9b9d2
  13. 10 1月, 2016 1 次提交
  15. 17 11月, 2015 1 次提交
  17. 16 9月, 2015 1 次提交
  19. 09 7月, 2015 1 次提交
  21. 01 4月, 2015 1 次提交
  23. 08 11月, 2014 1 次提交
  25. 29 10月, 2014 2 次提交
  27. 30 7月, 2014 1 次提交
  29. 01 4月, 2014 1 次提交
  31. 06 3月, 2014 1 次提交
    • H
      r8152: disable the ECM mode · 10c32717
      由 hayeswang 提交于 
      There are known issues for switching the drivers between ECM mode and
vendor mode. The interrup transfer may become abnormal. The hardware
may have the opportunity to die if you change the configuration without
unloading the current driver first, because all the control transfers
of the current driver would fail after the command of switching the
configuration.

Although to use the ecm driver and vendor driver independently is fine,
it may have problems to change the driver from one to the other by
switching the configuration. Additionally, now the vendor mode driver
is more powerful than the ECM driver. Thus, disable the ECM mode driver,
and let r8152 to set the configuration to vendor mode and reset the
device automatically.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10c32717
  33. 17 1月, 2014 1 次提交
  35. 15 1月, 2014 1 次提交
  37. 02 1月, 2014 1 次提交
  39. 07 12月, 2013 1 次提交
  41. 17 9月, 2013 3 次提交
  43. 12 7月, 2013 1 次提交
  45. 02 7月, 2013 1 次提交
  47. 11 6月, 2013 1 次提交
    • B
      qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820 · c2020be3
      由 Bjørn Mork 提交于 
      Another QMI speaking Qualcomm based device, which should be
driven by qmi_wwan, while cdc_ether should ignore it.

Like on other Huawei devices, the wwan function can appear
either as a single vendor specific interface or as a CDC ECM
class function using separate control and data interfaces.
The ECM control interface protocol is 0xff, likely in an
attempt to indicate that vendor specific management is
required.

In addition to the near standard CDC class, Huawei also add
vendor specific AT management commands to their firmwares.
This is probably an attempt to support non-Windows systems
using standard class drivers.  Unfortunately, this part of
the firmware is often buggy.  Linux is much better off using
whatever native vendor specific management protocol the
device offers, and Windows uses, whenever possible. This
means QMI in the case of Qualcomm based devices.

The E1820 has been verified to work fine with QMI.

Matching on interface number is necessary to distiguish the
wwan function from serial functions in the single interface
mode, as both function types will have class/subclass/function
set to ff/ff/ff.

The control interface number does not change in CDC ECM mode,
so the interface number matching rule is sufficient to handle
both modes.  The cdc_ether blacklist entry is only relevant in
CDC ECM mode, but using a similar interface number based rule
helps document this as a transfer from one driver to another.

Other Huawei 02/06/ff devices are left with the cdc_ether driver
because we do not know whether they are based on Qualcomm chips.
The Huawei specific AT command management is known to be somewhat
hardware independent, and their usage of these class codes may
also be independent of the modem hardware.
Reported-by: NGraham Inggs <graham.inggs@uct.ac.za>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2020be3
  49. 09 5月, 2013 1 次提交
  51. 07 5月, 2013 1 次提交
  53. 18 4月, 2013 1 次提交
  55. 12 4月, 2013 1 次提交
  57. 19 2月, 2013 1 次提交
  59. 20 12月, 2012 1 次提交
  61. 18 12月, 2012 2 次提交
  63. 26 10月, 2012 1 次提交
  65. 20 5月, 2012 1 次提交
  67. 19 5月, 2012 1 次提交
    • S
      USB: Disable hub-initiated LPM for comms devices. · e1f12eb6
      由 Sarah Sharp 提交于 
      Hub-initiated LPM is not good for USB communications devices.  Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.

If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data.  Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.

The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host.  In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.

Set the disable_hub_initiated_lpm flag for for all USB communications
drivers.  I know there aren't currently any USB 3.0 devices that
implement these class specifications, but we should be ready if they do.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1f12eb6
  69. 16 5月, 2012 1 次提交
  71. 07 5月, 2012 1 次提交
    • B
      cdc_ether: Ignore bogus union descriptor for RNDIS devices · 6eddcb4c
      由 Bjørn Mork 提交于 
      Some RNDIS devices include a bogus CDC Union descriptor pointing
to non-existing interfaces.  The RNDIS code is already prepared
to handle devices without a CDC Union descriptor by hardwiring
the driver to use interfaces 0 and 1, which is correct for the
devices with the bogus descriptor as well. So we can reuse the
existing workaround.

Cc: Markus Kolb <linux-201011@tower-net.de>
Cc: Iker Salmón San Millán <shaola@esdebian.org>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: 655387@bugs.debian.org
Cc: stable@vger.kernel.org
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6eddcb4c