1. 15 Jul, 2014 5 commits
    • Tom Gundersen's avatar
      net: rtnetlink - make create_link take name_assign_type · 5517750f
      Tom Gundersen authored
      This passes down NET_NAME_USER (or NET_NAME_ENUM) to alloc_netdev(),
      for any device created over rtnetlink.
      v9: restore reverse-christmas-tree order of local variables
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Tom Gundersen's avatar
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen authored
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      Coccinelle patch:
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      v9: move comments here from the wrong commit
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Tom Gundersen's avatar
      net: set name assign type for renamed devices · 238fa362
      Tom Gundersen authored
      Based on a patch from David Herrmann.
      This is the only place devices can be renamed.
      v9: restore revers-christmas-tree order of local variables
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • 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:
          The ifname is provided by the kernel with an enumerated
          suffix, typically based on order of discovery. Names may
          be reused and unpredictable.
          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.
          The ifname was provided by user-space during net-device setup.
          The net-device has been renamed from userspace. Once this type is set,
          it cannot change again.
          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
      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>
    • 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>
  2. 14 Jul, 2014 26 commits
  3. 13 Jul, 2014 1 commit
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next · 66568b39
      David S. Miller authored
      John W. Linville says:
      Please pull this batch of updates intended for the 3.17 stream...
      This is primarily a Bluetooth pull.  Gustavo says:
      "A lot of patches to 3.17. The bulk of changes here are for LE support.
      The 6loWPAN over Bluetooth now has it own module, we also have support for
      background auto-connection and passive scanning, Bluetooth device address
      provisioning, support for reading Bluetooth clock values and LE connection
      parameters plus many many fixes."
      The balance is just a pull of the wireless.git tree, to avoid some
      pending merge problems.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 11 Jul, 2014 8 commits