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
     

08 Nov, 2012

1 commit


12 Oct, 2012

1 commit


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
     

02 Apr, 2012

1 commit

  • Make CDC EEM recalculate the hard_mtu after adjusting the
    hard_header_len.

    Without this, usbnet adjusts the MTU down to 1494 bytes, and the host is
    unable to receive standard 1500-byte frames from the device.

    Tested with the Linux USB Ethernet gadget.

    Cc: Oliver Neukum
    Signed-off-by: Rabin Vincent
    Signed-off-by: David S. Miller

    Rabin Vincent
     

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
     

08 Apr, 2011

1 commit


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
     

31 Mar, 2011

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

18 Feb, 2010

1 commit

  • These macros are too similar to the dev_ equivalents
    but take a usbnet * argument. Convert them to the recently
    introduced netdev_ macros and remove the old macros.

    The old macros had "\n" appended to the format string.
    Add the "\n" to the converted uses.

    Some existing uses of the dev macros in cdc_eem.c
    probably mistakenly had trailing "\n". No "\n" added there.

    Fix net1080 this/other log message inversion.

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

    Joe Perches
     

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
     

23 Sep, 2009

1 commit

  • This is an alternate solution to the EEM 'sentinel' CRC valiation issue.

    CDC EEM allows using a 'sentinel' ethernet frame CRC of 0xdeadbeef in
    place of a real CRC. The 'sentinel' value is transmitted in big-endian
    order whereas the normal CRC is little-endian. This patch handles both
    cases appropriately.

    Signed-off-by: Brian Niebuhr
    Signed-off-by: Greg Kroah-Hartman

    Brian Niebuhr
     

17 Jul, 2009

1 commit

  • When the driver received an EEM packet with CRC option enabled, driver must
    compute and check the CRC of the Ethernet data. Previous version computes CRC
    on Ethernet data plus the original CRC value. Skbuff is correctly trimed but
    the old length is used when CRC is computed.

    Signed-off-by: Vincent CUISSARD
    Signed-off-by: David S. Miller

    Vincent CUISSARD
     

01 Jul, 2009

1 commit


05 May, 2009

1 commit

  • This introduces a CDC Ethernet Emulation Model (EEM) host side
    driver to support USB EEM devices.

    EEM is different from the Ethernet Control Model (ECM) currently
    supported by the "CDC Ethernet" driver. One key difference is
    that it doesn't require of USB interface alternate settings to
    manage interface state; some maldesigned hardware can't handle
    that part of USB. It also avoids a separate USB interface for
    control and status updates.

    [ dbrownell@users.sourceforge.net: fix skb leaks, add rx packet
    checks, improve fault handling, EEM conformance updates, cleanup ]

    Signed-off-by: Omar Laazimani
    Signed-off-by: David Brownell
    Signed-off-by: David S. Miller

    Omar Laazimani