17 Jan, 2014

1 commit

  • 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
     

07 Dec, 2013

1 commit

  • 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
     

19 May, 2012

1 commit

  • 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
     

28 Mar, 2012

1 commit


23 Feb, 2012

1 commit

  • 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
     

22 Feb, 2012

1 commit

  • In 16adf5d07987d93675945f3cecf0e33706566005 I removed an over-broad
    alias that caused zaurus.ko to bind to unrelated devices.
    I had a report that at least one valid case no longer auto-loads because of this.
    This patch adds an ID for that case.

    Reported-by: Raphael Wimmer
    Signed-off-by: Dave Jones
    Signed-off-by: David S. Miller

    Dave Jones
     

19 Nov, 2011

1 commit

  • This converts the drivers in drivers/net/* to use the
    module_usb_driver() macro which makes the code smaller and a bit
    simpler.

    Added bonus is that it removes some unneeded kernel log messages about
    drivers loading and/or unloading.

    Cc: Wolfgang Grandegger
    Cc: Samuel Ortiz
    Cc: Oliver Neukum
    Cc: Peter Korsgaard
    Cc: Petko Manolov
    Cc: Steve Glendinning
    Cc: Christian Lamparter
    Cc: "John W. Linville"
    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: Lucas De Marchi
    Cc: "David S. Miller"
    Cc: Roel Kluin
    Cc: Paul Gortmaker
    Cc: Jiri Pirko
    Cc: Pavel Roskin
    Cc: Yoann DI-RUZZA
    Cc: George
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

29 Jun, 2011

1 commit

  • This module and a bunch of dependancies are getting loaded on several
    of laptops I have (probably picking up the mobile broadband device),
    that have nothing to do with zaurus. Matching by class without
    any vendor/device pair isn't the right thing to do here, as it
    will prevent any other driver from correctly binding to it.
    (Or in the absense of a driver, will just waste time & memory by
    unnecessarily loading modules)

    Signed-off-by: Dave Jones
    Signed-off-by: David S. Miller

    Dave Jones
     

02 Apr, 2011

1 commit

  • The documentation for the USB ethernet devices suggests that
    only some devices are supposed to use usb0 as the network interface
    name instead of eth0. The logic used there, and documented in
    Kconfig for CDC is that eth0 will be used when the mac address
    is a globally assigned one, but usb0 is used for the locally
    managed range that is typically used on point-to-point links.

    Unfortunately, this has caused a lot of pain on the smsc95xx
    device that is used on the popular pandaboard without an
    EEPROM to store the MAC address, which causes the driver to
    call random_ether_address().

    Obviously, there should be a proper MAC addressed assigned to
    the device, and discussions are ongoing about how to solve
    this, but this patch at least makes sure that the default
    interface naming gets a little saner and matches what the
    user can expect based on the documentation, including for
    new devices.

    The approach taken here is to flag whether a device might be a
    point-to-point link with the new FLAG_POINTTOPOINT setting in
    the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
    and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
    of the two. The usbnet framework only looks at the MAC address
    for device naming if both flags are set, otherwise it trusts the
    flag.

    Signed-off-by: Arnd Bergmann
    Tested-by: Andy Green
    Signed-off-by: David S. Miller

    Arnd Bergmann
     

04 Dec, 2009

1 commit

  • Only files where David Miller is the primary git-signer.
    wireless, wimax, ixgbe, etc are not modified.

    Compile tested x86 allyesconfig only
    Not all files compiled (not x86 compatible)

    Added a few > 80 column lines, which I ignored.
    Existing checkpatch complaints ignored.

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

02 Mar, 2009

1 commit

  • The Motorola MOTOMAGX phones (Z6, E8, Zn5 so far) are providing
    combined ACM/BLAN USB configuration. Since it has Vendor Specific
    class, the corresponding drivers (cdc-acm, zaurus) can't find it just
    by interface info. This patch adds usb id so the zaurus driver can
    properly handle this combined device.

    Signed-off-by: Dmitriy Taychenachev
    Signed-off-by: David S. Miller

    Dmitriy Taychenachev
     

01 Feb, 2008

1 commit

  • Move headers usbnet.h and rndis_host.h to include/linux/usb and fix includes
    for drivers/net/usb modules. Headers are moved because rndis_wlan will be
    outside drivers/net/usb in drivers/net/wireless and yet need these headers.

    Signed-off-by: Jussi Kivilinna
    Acked-by: David Brownell
    Signed-off-by: John W. Linville
    Signed-off-by: David S. Miller

    Jussi Kivilinna
     

10 May, 2007

1 commit

  • It is preferable to group drivers by usage (net, scsi, ATA, ...) than
    by bus. When reviewing drivers, the [PCI|USB|PCMCIA|...] maintainer
    is probably less qualified on networking issues than a networking
    maintainer. Also, from a practical standpoint, chips often
    appear on multiple buses, which is why we do not put drivers into
    drivers/pci/net.

    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Jeff Garzik

    Jeff Garzik