Eric Lee / smarc-fsl-linux-kernel

04 Feb, 2017

1 commit

  • 087c2ecb2   qmi_wwan/cdc_ether: add device ID for HP lt2523 (Novatel E371) WWAN card ... Browse Code »

    [ Upstream commit 5b9f57516337b523f7466a53939aaaea7b78141b ]

    Another rebranded Novatel E371. qmi_wwan should drive this device, while
    cdc_ether should ignore it. Even though the USB descriptors are plain
    CDC-ETHER that USB interface is a QMI interface. Ref commit 7fdb7846c9ca
    ("qmi_wwan/cdc_ether: add device IDs for Dell 5804 (Novatel E371) WWAN
    card")

    Cc: Dan Williams
    Signed-off-by: Bjørn Mork
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Bjørn Mork
     

03 Dec, 2016

1 commit

  • d5c83d0d1   cdc_ether: Fix handling connection notification ... Browse Code »

    Commit bfe9b9d2df66 ("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 bfe9b9d2df66, 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 bfe9b9d2df66. 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: bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
    Reported-by: Henning Schild
    Signed-off-by: Kristian Evensen
    Signed-off-by: David S. Miller

    Kristian Evensen
     

25 Jul, 2016

1 commit

  • bfe9b9d2d   cdc_ether: Improve ZTE MF823/831/910 handling ... Browse Code »

    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: Kristian Evensen
    Acked-by: Oliver Neukum
    Signed-off-by: David S. Miller

    Kristian Evensen
     

10 Jan, 2016

1 commit

  • 29c6dd591   cdc-acm: fix NULL pointer reference ... Browse Code »

    The union descriptor must be checked. Its usage was conditional
    before the parser was introduced. This is important, because
    many RNDIS device, which also use the common parser, have
    bogus extra descriptors.

    Signed-off-by: Oliver Neukum
    Tested-by: Vasily Galkin
    Signed-off-by: David S. Miller

    Oliver Neukum
     

17 Nov, 2015

1 commit

16 Sep, 2015

1 commit

09 Jul, 2015

1 commit

01 Apr, 2015

1 commit

08 Nov, 2014

1 commit

29 Oct, 2014

2 commits

30 Jul, 2014

1 commit

  • c472ab68a   cdc-ether: clean packet filter upon probe ... Browse Code »

    There are devices that don't do reset all the way. So the packet filter should
    be set to a sane initial value. Failure to do so leads to intermittent failures
    of DHCP on some systems under some conditions.

    Signed-off-by: Oliver Neukum
    Signed-off-by: David S. Miller

    Oliver Neukum
     

01 Apr, 2014

1 commit

  • 7b5939ba5   qmi_wwan/cdc_ether: move Novatel E371 (1410:9011) to qmi_wwan ... Browse Code »

    This device provides QMI and ethernet functionality via a standard CDC
    ethernet descriptor. But when driven by cdc_ether, the QMI
    functionality is unavailable because only cdc_ether can claim the USB
    interface. Thus blacklist the device in cdc_ether and add its IDs to
    qmi_wwan, which enables both QMI and ethernet simultaneously.

    Signed-off-by: Yegor Yefremov
    Signed-off-by: David S. Miller

    Yegor Yefremov
     

06 Mar, 2014

1 commit

  • 10c327171   r8152: disable the ECM mode ... Browse Code »

    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: Hayes Wang
    Signed-off-by: David S. Miller

    hayeswang
     

17 Jan, 2014

1 commit

  • a81ab36bf   drivers/net: delete non-required instances of include <linux/init.h> ... Browse Code »

    None of these files are actually using any __init type directives
    and hence don't need to include . Most are just a
    left over from __devinit and __cpuinit removal, or simply due to
    code getting copied from one driver to the next.

    This covers everything under drivers/net except for wireless, which
    has been submitted separately.

    Signed-off-by: Paul Gortmaker
    Signed-off-by: David S. Miller

    Paul Gortmaker
     

15 Jan, 2014

1 commit

  • c7de7dec2   r8152: ecm and vendor modes coexist ... Browse Code »

    Remove the limitation that the ecm and r8152 drivers couldn't coexist.
    - Remove the devices from the blacklist of relative drivers.
    - Remove usb_driver_set_configuration() from r8152 driver.
    - Modify the id_table of the r8152 driver for the vendor mode only.

    Signed-off-by: Hayes Wang
    Signed-off-by: David S. Miller

    hayeswang
     

02 Jan, 2014

1 commit

07 Dec, 2013

1 commit

  • 9cb00073d   usb: Fix FSF address in file headers ... Browse Code »

    Several files refer to an old address for the Free Software Foundation
    in the file header comment. Resolve by replacing the address with
    the URL so that we do not have to keep
    updating the header comments anytime the address changes.

    CC: Oliver Neukum
    CC: Steve Glendinning
    CC: Oliver Neukum
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller

    Jeff Kirsher
     

17 Sep, 2013

3 commits

12 Jul, 2013

1 commit

  • c073f666f   net/usb: add relative mii functions for r815x ... Browse Code »

    Base on cdc_ether, add the mii functions for RTL8152 and RTL8153.
    The RTL8152 and RTL8153 support ECM mode which use the driver of
    cdc_ether. Add the mii functions. Then, the basic PHY access is
    possible.

    Signed-off-by: Hayes Wang
    Signed-off-by: David S. Miller

    hayeswang
     

02 Jul, 2013

1 commit

  • 1fc4c84d4   net: cdc_ether: allow combined control and data interface ... Browse Code »

    Some Icera based Huawei modems handled by this driver are not
    completely CDC ECM compliant, using the same USB interface for both
    control and data. The CDC functional descriptors include a Union
    naming this interface as both master and slave, so it is supportable
    by relaxing the descriptor parsing in case these interfaces are
    identical.

    This has been tested on a Huawei K3806 and verified to add support
    for that device.

    Reported-and-tested-by: Enrico Mioso
    Signed-off-by: Bjørn Mork
    Acked-by: Oliver Neukum
    Signed-off-by: David S. Miller

    Bjørn Mork
     

11 Jun, 2013

1 commit

  • c2020be3c   qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820 ... Browse Code »

    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: Graham Inggs
    Signed-off-by: Bjørn Mork
    Signed-off-by: David S. Miller

    Bjørn Mork
     

09 May, 2013

1 commit

07 May, 2013

1 commit

18 Apr, 2013

1 commit

  • a6bda459f   net: cdc_ether: silence sparse __CHECK_ENDIAN__ warning ... Browse Code »

    Remove warning introduced by commit 418fc57 ("usbnet: cdc-ether: apply
    usbnet_link_change"):

    CHECK .../drivers/net/usb/cdc_ether.c
    .../drivers/net/usb/cdc_ether.c:409:46: warning: incorrect type in argument 2 (different base types)
    .../drivers/net/usb/cdc_ether.c:409:46: expected bool [unsigned] [usertype]
    .../drivers/net/usb/cdc_ether.c:409:46: got restricted __le16 [usertype] wValue

    Cc: Ming Lei
    Signed-off-by: Bjørn Mork
    Acked-by: Ming Lei
    Signed-off-by: David S. Miller

    Bjørn Mork
     

12 Apr, 2013

1 commit

19 Feb, 2013

1 commit

20 Dec, 2012

1 commit

18 Dec, 2012

2 commits

26 Oct, 2012

1 commit

  • f8295ec22   qmi_wwan/cdc_ether: move Novatel 551 and E362 to qmi_wwan ... Browse Code »

    These devices provide QMI and ethernet functionality via a standard CDC
    ethernet descriptor. But when driven by cdc_ether, the QMI
    functionality is unavailable because only cdc_ether can claim the USB
    interface. Thus blacklist the devices in cdc_ether and add their IDs to
    qmi_wwan, which enables both QMI and ethernet simultaneously.

    Signed-off-by: Dan Williams
    Cc: stable@vger.kernel.org
    Acked-by: Greg Kroah-Hartman
    Acked-by: Bjørn Mork
    Signed-off-by: David S. Miller

    Dan Williams
     

23 May, 2012

1 commit

  • a48199146   Merge tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb ... Browse Code »

    Pull USB 3.5-rc1 changes from Greg Kroah-Hartman:
    "Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.

    It's touches a lot of different parts of the kernel, all USB drivers,
    due to some API cleanups (getting rid of the ancient err() macro) and
    some changes that are needed for USB 3.0 power management updates.

    There are also lots of new drivers, pimarily gadget, but others as
    well. We deleted a staging driver, which was nice, and finally
    dropped the obsolete usbfs code, which will make Al happy to never
    have to touch that again.

    There were some build errors in the tree that linux-next found a few
    days ago, but those were fixed by the most recent changes (all were
    due to us not building with CONFIG_PM disabled.)

    Signed-off-by: Greg Kroah-Hartman "

    * tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (477 commits)
    xhci: Fix DIV_ROUND_UP compile error.
    xhci: Fix compile with CONFIG_USB_SUSPEND=n
    USB: Fix core compile with CONFIG_USB_SUSPEND=n
    brcm80211: Fix compile error for .disable_hub_initiated_lpm.
    Revert "USB: EHCI: work around bug in the Philips ISP1562 controller"
    MAINTAINERS: Add myself as maintainer to the USB PHY Layer
    USB: EHCI: fix command register configuration lost problem
    USB: Remove races in devio.c
    USB: ehci-platform: remove update_device
    USB: Disable hub-initiated LPM for comms devices.
    xhci: Add Intel U1/U2 timeout policy.
    xhci: Add infrastructure for host-specific LPM policies.
    USB: Add macros for interrupt endpoint types.
    xhci: Reserve one command for USB3 LPM disable.
    xhci: Some Evaluate Context commands must succeed.
    USB: Disable USB 3.0 LPM in critical sections.
    USB: Add support to enable/disable USB3 link states.
    USB: Allow drivers to disable hub-initiated LPM.
    USB: Calculate USB 3.0 exit latencies for LPM.
    USB: Refactor code to set LPM support flag.
    ...

    Conflicts:
    arch/arm/mach-exynos/mach-nuri.c
    arch/arm/mach-exynos/mach-universal_c210.c
    drivers/net/wireless/ath/ath6kl/usb.c

    Linus Torvalds
     

20 May, 2012

1 commit

19 May, 2012

1 commit

  • e1f12eb6b   USB: Disable hub-initiated LPM for comms devices. ... Browse Code »

    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: Sarah Sharp
    Cc: Marcel Holtmann
    Cc: Gustavo Padovan
    Cc: Johan Hedberg
    Cc: Hansjoerg Lipp
    Cc: Tilman Schmidt
    Cc: Karsten Keil
    Cc: Peter Korsgaard
    Cc: Jan Dumon
    Cc: Petko Manolov
    Cc: Steve Glendinning
    Cc: "John W. Linville"
    Cc: Kalle Valo
    Cc: "Luis R. Rodriguez"
    Cc: Jouni Malinen
    Cc: Vasanthakumar Thiagarajan
    Cc: Senthil Balasubramanian
    Cc: Christian Lamparter
    Cc: Brett Rudley
    Cc: Roland Vossen
    Cc: Arend van Spriel
    Cc: "Franky (Zhenhui) Lin"
    Cc: Kan Yan
    Cc: Dan Williams
    Cc: Jussi Kivilinna
    Cc: Ivo van Doorn
    Cc: Gertjan van Wingerde
    Cc: Helmut Schaa
    Cc: Herton Ronaldo Krzesinski
    Cc: Hin-Tak Leung
    Cc: Larry Finger
    Cc: Chaoming Li
    Cc: Daniel Drake
    Cc: Ulrich Kunitz
    Signed-off-by: Sarah Sharp

    Sarah Sharp
     

16 May, 2012

1 commit

07 May, 2012

1 commit

  • 6eddcb4c8   cdc_ether: Ignore bogus union descriptor for RNDIS devices ... Browse Code »
    1

    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
    Cc: Iker Salmón San Millán
    Cc: Jonathan Nieder
    Cc: Oliver Neukum
    Cc: 655387@bugs.debian.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Bjørn Mork
    Signed-off-by: David S. Miller

    Bjørn Mork
     

23 Feb, 2012

1 commit

  • ee932bf9a   Move Logitech Harmony 900 from cdc_ether to zaurus ... Browse Code »
    1

    In the current kernel implementation, the Logitech Harmony 900 remote
    control is matched to the cdc_ether driver through the generic
    USB_CDC_SUBCLASS_MDLM entry. However, this device appears to be of the
    pseudo-MDLM (Belcarra) type, rather than the standard one. This patch
    blacklists the Harmony 900 from the cdc_ether driver and whitelists it for
    the pseudo-MDLM driver in zaurus.

    Signed-off-by: Scott Talbert
    Signed-off-by: David S. Miller

    Scott Talbert
     

07 Jan, 2012

1 commit

  • ff4b8a57f   Merge branch 'driver-core-next' into Linux 3.2 ... Browse Code »

    This resolves the conflict in the arch/arm/mach-s3c64xx/s3c6400.c file,
    and it fixes the build error in the arch/x86/kernel/microcode_core.c
    file, that the merge did not catch.

    The microcode_core.c patch was provided by Stephen Rothwell
    who was invaluable in the merge issues involved
    with the large sysdev removal process in the driver-core tree.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman