1. 15 Jul, 2014 12 commits
    • Tom Gundersen's avatar
      net: add name_assign_type netdev attribute · 685343fc
      Tom Gundersen authored
      Based on a patch by David Herrmann.
      
      The name_assign_type attribute gives hints where the interface name of a
      given net-device comes from. These values are currently defined:
        NET_NAME_ENUM:
          The ifname is provided by the kernel with an enumerated
          suffix, typically based on order of discovery. Names may
          be reused and unpredictable.
        NET_NAME_PREDICTABLE:
          The ifname has been assigned by the kernel in a predictable way
          that is guaranteed to avoid reuse and always be the same for a
          given device. Examples include statically created devices like
          the loopback device and names deduced from hardware properties
          (including being given explicitly by the firmware). Names
          depending on the order of discovery, or in any other way on the
          existence of other devices, must not be marked as PREDICTABLE.
        NET_NAME_USER:
          The ifname was provided by user-space during net-device setup.
        NET_NAME_RENAMED:
          The net-device has been renamed from userspace. Once this type is set,
          it cannot change again.
        NET_NAME_UNKNOWN:
          This is an internal placeholder to indicate that we yet haven't yet
          categorized the name. It will not be exposed to userspace, rather
          -EINVAL is returned.
      
      The aim of these patches is to improve user-space renaming of interfaces. As
      a general rule, userspace must rename interfaces to guarantee that names stay
      the same every time a given piece of hardware appears (at boot, or when
      attaching it). However, there are several situations where userspace should
      not perform the renaming, and that depends on both the policy of the local
      admin, but crucially also on the nature of the current interface name.
      
      If an interface was created in repsonse to a userspace request, and userspace
      already provided a name, we most probably want to leave that name alone. The
      main instance of this is wifi-P2P devices created over nl80211, which currently
      have a long-standing bug where they are getting renamed by udev. We label such
      names NET_NAME_USER.
      
      If an interface, unbeknown to us, has already been renamed from userspace, we
      most probably want to leave also that alone. This will typically happen when
      third-party plugins (for instance to udev, but the interface is generic so could
      be from anywhere) renames the interface without informing udev about it. A
      typical situation is when you switch root from an installer or an initrd to the
      real system and the new instance of udev does not know what happened before
      the switch. These types of problems have caused repeated issues in the past. To
      solve this, once an interface has been renamed, its name is labelled
      NET_NAME_RENAMED.
      
      In many cases, the kernel is actually able to name interfaces in such a
      way that there is no need for userspace to rename them. This is the case when
      the enumeration order of devices, or in fact any other (non-parent) device on
      the system, can not influence the name of the interface. Examples include
      statically created devices, or any naming schemes based on hardware properties
      of the interface. In this case the admin may prefer to use the kernel-provided
      names, and to make that possible we label such names NET_NAME_PREDICTABLE.
      We want the kernel to have tho possibilty of performing predictable interface
      naming itself (and exposing to userspace that it has), as the information
      necessary for a proper naming scheme for a certain class of devices may not
      be exposed to userspace.
      
      The case where renaming is almost certainly desired, is when the kernel has
      given the interface a name using global device enumeration based on order of
      discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM.
      
      Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has
      not yet been ported. This is mostly useful as a transitionary measure, allowing
      us to label the various naming schemes bit by bit.
      
      v8: minor documentation fixes
      v9: move comment to the right commit
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: default avatarKay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      685343fc
    • Ezequiel Garcia's avatar
      net: mvpp2: Fix a typo in the license · c634099d
      Ezequiel Garcia authored
      The proper string for this license is "GPL v2", instead of "GPLv2".
      This commit fixes that.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c634099d
    • David S. Miller's avatar
      Merge branch 'amd811e-cleanups' · 0854a7f1
      David S. Miller authored
      Varka Bhadram says:
      
      ====================
      This series cleanup for AMD8111E ethernet driver
      
      v1: fix checkpatch warnings.
      v2: added new line in debug messages
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0854a7f1
    • Varka Bhadram's avatar
      ethernet: amd: fix 'foo* bar' · 46c73ecc
      Varka Bhadram authored
      This patch fix the 'foo*' bar with 'foo *bar' and (foo*) with (foo *).
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46c73ecc
    • Varka Bhadram's avatar
      ethernet: amd: fix pci device ids · ba69a3d7
      Varka Bhadram authored
      Normally any device ids will be above the corresponding device driver
      structure. This patch moves the pci device ids and MODULE_DEVICE_TABLE()
      above the pci driver structure.
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba69a3d7
    • Varka Bhadram's avatar
      ethernet: amd: fix comment styles · 13a4fa43
      Varka Bhadram authored
      This patch fixes the comment style issues
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13a4fa43
    • Varka Bhadram's avatar
      ethernet: amd: dynamic debug fixes · f7afbaa5
      Varka Bhadram authored
      This patch convert printk() to netdev_dbg/info/err or dev_info/err/dbg
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7afbaa5
    • Varka Bhadram's avatar
      ethernet: amd: use devm_ioremap() · 711fec5d
      Varka Bhadram authored
      This patch replace ioremap() with the devm_ioremap() so that
      the resource will be freed automatically with the probe failed.
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      711fec5d
    • Varka Bhadram's avatar
      ethernet: amd: move amd111e_remove_one after probe · 43519e60
      Varka Bhadram authored
      This patch moves the remove functionalities after the probe
      so that we can see the registered and released resources properly.
      Every driver follows the same concept.
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43519e60
    • David S. Miller's avatar
      Merge branch 'sfc-next' · 30c9e022
      David S. Miller authored
      Shradha Shah says:
      
      ====================
      sfc: Add 40G support
      
      This patch series adds support for Solarflare 7000 series
      40G Solarflare network adapters starting with the SFN7X42Q.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30c9e022
    • Edward Cree's avatar
      sfc: Add 40G link capability decoding · ac331e94
      Edward Cree authored
      Needed to select 40G mode on a 10G/40G capable card.
      Signed-off-by: default avatarShradha Shah <sshah@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac331e94
    • Mateusz Wrzesinski's avatar
  2. 14 Jul, 2014 17 commits
  3. 11 Jul, 2014 11 commits