1. 01 Mar, 2016 9 commits
  2. 29 Feb, 2016 12 commits
  3. 27 Feb, 2016 1 commit
  4. 26 Feb, 2016 18 commits
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · e1bae75d
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      1GbE Intel Wired LAN Driver Updates 2016-02-24
      
      This series contains updates to e1000e, igb and igbvf.
      
      Raanan provides updates for e1000e, first increases the ULP timer since it
      now takes longer for the ULP exit to complete on Skylake.  Fixes the
      configuration of the internal hardware PHY clock gating mechanism, which was
      causing packet loss due to mis configuring.  Fixed additional ULP
      configuration settings which were not being properly cleared after cable
      connect in V-Pro capable systems.  Added support for more i219 devices.
      
      Takuma Ueba provides a fix for I210 where IPv6 autoconf test sometimes
      fails due to DAD NS for link-local is not transmitted.  To avoid this
      issue, we need to wait until 1000BASE-T status register "Remote receiver
      status OK".
      
      Todd provides a patch to override EEPROM WoL settings for specific OEM
      devices. Then renamed igb defines to be more generic, since the define
      E1000_MRQC_ENABLE_RSS_4Q enables 4 and 8 queues depending on the part.
      
      Roland Hii fixes an issue where only the half cycle time of less than or
      equal to 70 millisecond uses the I210 clock output function.  His patch
      adds additional conditions when half cycle time is equal to 125 or 250 or
      500 millisecond to use the clock output function.
      
      Alex Duyck adds support for generic transmit checksums for igb and igbvf.
      
      Jon Maxwell fixes an issues where customer applications are registering
      and un-registering multicast addresses every few seconds which is leading
      to many "Link is up" messages in the logs as a result of the
      netif_carrier_off(netdev) in igbvf_msix_other().  So remove the
      link is up message when registering multicast addresses.
      
      Corinna Vinschen provides a fix for when switching off VLAN offloading on
      i350, the VLAN interface becomes unusable.
      
      Stefan Assmann updates the driver to use ndo_stop() instead of
      dev_close() when running ethtool offline self test.  Since dev_close()
      causes IFF_UP to be cleared which will remove the interfaces routes
      and some addresses.
      
      v2: Dropped patches 6-10 in the original series.  Patch 6-7 added support
          for character device for AVB and based on community feedback, we do not
          want to do this.  Patches 8-10 provided fixes to the problematic code
          added in patches 6 & 7.  So all of them must go!
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1bae75d
    • Alexander Duyck's avatar
      GSO: Provide software checksum of tunneled UDP fragmentation offload · 22463876
      Alexander Duyck authored
      On reviewing the code I realized that GRE and UDP tunnels could cause a
      kernel panic if we used GSO to segment a large UDP frame that was sent
      through the tunnel with an outer checksum and hardware offloads were not
      available.
      
      In order to correct this we need to update the feature flags that are
      passed to the skb_segment function so that in the event of UDP
      fragmentation being requested for the inner header the segmentation
      function will correctly generate the checksum for the payload if we cannot
      segment the outer header.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22463876
    • David S. Miller's avatar
      Merge branch 'vrf-saddr-selection' · c3f463ba
      David S. Miller authored
      David Ahern says:
      
      ====================
      net: l3mdev: Fix source address for unnumbered deployments
      
      David Lamparter noted a use case where the source address selection fails
      to pick an address from a VRF interface - unnumbered interfaces. The use
      case has the VRF device as the VRF local loopback with addresses and
      interfaces enslaved without an address themselves. e.g,
      
          ip addr add 9.9.9.9/32 dev lo
          ip link set lo up
      
          ip link add name vrf0 type vrf table 101
          ip rule add oif vrf0 table 101
          ip rule add iif vrf0 table 101
          ip link set vrf0 up
          ip addr add 10.0.0.3/32 dev vrf0
      
          ip link add name dummy2 type dummy
          ip link set dummy2 master vrf0 up
      
          --> note dummy2 has no address - unnumbered device
      
          ip route add 10.2.2.2/32 dev dummy2 table 101
          ip neigh add 10.2.2.2 dev dummy2 lladdr 02:00:00:00:00:02
      
      ping to the 10.2.2.2 through the L3 domain:
      
          $ ping -I vrf0 -c1 10.2.2.2
          ping: Warning: source address might be selected on device other than vrf0.
          PING 10.2.2.2 (10.2.2.2) from 9.9.9.9 vrf0: 56(84) bytes of data.
      
      picks up the wrong address -- the one from 'lo' not vrf0. And from tcpdump:
          12:57:29.449128 IP 9.9.9.9 > 10.2.2.2: ICMP echo request, id 2491, seq 1, length 64
      
      This patch series changes address selection to only consider devices in
      the same L3 domain and to use the VRF device as the L3 domains loopback.
      
          $ ping -I vrf0 -c1 10.2.2.2
          PING 10.2.2.2 (10.2.2.2) from 10.0.0.3 vrf0: 56(84) bytes of data.
      
      From tcpdump:
          12:59:25.096426 IP 10.0.0.3 > 10.2.2.2: ICMP echo request, id 2113, seq 1, length 64
      
      Now the source address comes from vrf0.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3f463ba
    • David Lamparter's avatar
      net: l3mdev: prefer VRF master for source address selection · 17b693cd
      David Lamparter authored
      When selecting an address in context of a VRF, the vrf master should be
      preferred for address selection.  If it isn't, the user has a hard time
      getting the system to select to their preference - the code will pick
      the address off the first in-VRF interface it can find, which on a
      router could well be a non-routable address.
      Signed-off-by: default avatarDavid Lamparter <equinox@diac24.net>
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      [dsa: Fixed comment style and removed extra blank link ]
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17b693cd
    • David Ahern's avatar
      net: l3mdev: address selection should only consider devices in L3 domain · 3f2fb9a8
      David Ahern authored
      David Lamparter noted a use case where the source address selection fails
      to pick an address from a VRF interface - unnumbered interfaces.
      
      Relevant commands from his script:
          ip addr add 9.9.9.9/32 dev lo
          ip link set lo up
      
          ip link add name vrf0 type vrf table 101
          ip rule add oif vrf0 table 101
          ip rule add iif vrf0 table 101
          ip link set vrf0 up
          ip addr add 10.0.0.3/32 dev vrf0
      
          ip link add name dummy2 type dummy
          ip link set dummy2 master vrf0 up
      
          --> note dummy2 has no address - unnumbered device
      
          ip route add 10.2.2.2/32 dev dummy2 table 101
          ip neigh add 10.2.2.2 dev dummy2 lladdr 02:00:00:00:00:02
      
          tcpdump -ni dummy2 &
      
      And using ping instead of his socat example:
          $ ping -I vrf0 -c1 10.2.2.2
          ping: Warning: source address might be selected on device other than vrf0.
          PING 10.2.2.2 (10.2.2.2) from 9.9.9.9 vrf0: 56(84) bytes of data.
      
      >From tcpdump:
          12:57:29.449128 IP 9.9.9.9 > 10.2.2.2: ICMP echo request, id 2491, seq 1, length 64
      
      Note the source address is from lo and is not a VRF local address. With
      this patch:
      
          $ ping -I vrf0 -c1 10.2.2.2
          PING 10.2.2.2 (10.2.2.2) from 10.0.0.3 vrf0: 56(84) bytes of data.
      
      >From tcpdump:
          12:59:25.096426 IP 10.0.0.3 > 10.2.2.2: ICMP echo request, id 2113, seq 1, length 64
      
      Now the source address comes from vrf0.
      
      The ipv4 function for selecting source address takes a const argument.
      Removing the const requires touching a lot of places, so instead
      l3mdev_master_ifindex_rcu is changed to take a const argument and then
      do the typecast to non-const as required by netdev_master_upper_dev_get_rcu.
      This is similar to what l3mdev_fib_table_rcu does.
      
      IPv6 for unnumbered interfaces appears to be selecting the addresses
      properly.
      
      Cc: David Lamparter <david@opensourcerouting.org>
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f2fb9a8
    • Simon Horman's avatar
      can: rcar: add device tree support for r8a779[234] · f71096df
      Simon Horman authored
      Simply document new compatibility string.
      As a previous patch adds a generic R-Car Gen2 compatibility string
      there appears to be no need for a driver updates.
      
      By documenting these compat stings they may be used in DTSs shipped, for
      example as part of ROMs. They must be used in conjunction with the Gen2
      fallback compat string. At this time there are no known differences between
      the r8a779[234] IP blocks and that implemented by the driver for the Gen2
      fallback compat string. Thus there is no need to update the driver as the
      use of the Gen2 fallback compat string will activate the correct code in
      the current driver while leaving the option for r8a779[234]-specific driver
      code to be activated in an updated driver should the need arise.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      f71096df
    • Simon Horman's avatar
      can: rcar: add gen[12] fallback compatibility strings · 0dfa61bb
      Simon Horman authored
      Add fallback compatibility string for R-Car Gen 1 and Gen2.
      
      In the case of Renesas R-Car hardware we know that there are generations of
      SoCs, e.g. Gen 1 and Gen 2. But beyond that its not clear what the
      relationship between IP blocks might be. For example, I believe that
      r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
      descendant of the former or vice versa.
      
      We can, however, by examining the documentation and behaviour of the
      hardware at run-time observe that the current driver implementation appears
      to be compatible with the IP blocks on SoCs within a given generation.
      
      For the above reasons and convenience when enabling new SoCs a
      per-generation fallback compatibility string scheme being adopted for
      drivers for Renesas SoCs.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      0dfa61bb
    • Marc Kleine-Budde's avatar
      can: ems_usb: fix coding style · 59097ac9
      Marc Kleine-Budde authored
      This patch fixes the coding style issues introduced in commit:
      
          90cfde46 can: ems_usb: Fix possible tx overflow
      Reported-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      59097ac9
    • David S. Miller's avatar
      Merge branch 'ethtool-ksettings' · 8d3f2806
      David S. Miller authored
      David Decotigny says:
      
      ====================
      new ETHTOOL_GLINKSETTINGS/SLINKSETTINGS API
      
      History:
       v9
       - add 'link' in macro, struct and function names
       - rename ethtool_link_ksettings::parent -> ::base
       - remove un-needed mlx4 en_dbg_enabled() companion patch
       - note: bitmap u32[] API patches were merged separately by Kan Liang
       v8
       - bitmap u32 API returns number of bits copied, unit tests updated
       v7
       - module_exit in test_bitmap
       v6
       - fix copy_from_user in user/kernel handshake
       v5
       note: please see v4 bullets for a question regarding bitmap.c
       - minor fix to make allyesconfig/allmodconfig
       v4
       - removed typedef for link mode bitmaps
       - moved bitmap<->u32[] conversion routines to bitmap.c . This is the
         naive implementation. I have an endian-aware version that uses
         memcpy/memset as much as possible, but I find it harder to follow
         (see http://paste.ubuntu.com/13863722/). Please let me know if I
         should use it instead.
       - fixes suggested by Ben Hutchings
       v3
       - rebased v2 on top of latest net-next, minor checkpatch/printf %*pb
         updates
       v2
       - keep return 0 in get_settings when successful, instead of
         propagating positive result from driver's get_settings callback.
       v1
       - original submission
      
      The main goal of this series is to support ethtool link mode masks
      larger than 32 bits. It implements a new ioctl pair
      (ETHTOOL_GLINKSETTINGS/SLINKSETTINGS), its associated callbacks
      (get/set_link_ksettings) and a new struct ethtool_link_settings, which
      should eventually replace legacy ethtool_cmd. Internally, the kernel
      uses fixed length link mode masks defined at compilation time in
      ethtool.h (for now: 31 bits), that can be increased by changing
      __ETHTOOL_LINK_MODE_LAST in ethtool.h (absolute max is 4064 bits,
      checked at compile time), and the user/kernel interface allows this
      length to be arbitrary within 1..4064. This should allow some
      flexibility without using too much heap/stack space, at the cost of a
      small kernel/user handshake for the user to determine the sizes of
      those bitmaps.
      
      Along the way, I chose to drop in the new structure the 3 ethtool_cmd
      fields marked "deprecated" (transceiver/maxrxpkt/maxtxpkt). They are
      still available for old drivers via the (old) ETHTOOL_GSET/SSET API,
      but are not available to drivers that switch to new API. Of those 3
      fields, ethtool_cmd::transceiver seems to be still actively used by
      several drivers, maybe we should not consider this field deprecated?
      The 2 other fields are basically not used. This transition requires
      some care in the way old and new ethtool talk to the kernel.
      
      More technical details provided in the description for main patch. In
      particular details about backward compatibility properties.
      
      Some open questions:
       - the kernel/interface multiplexes the "tell me the bitmap length"
         handshake and the "give me the settings" inside the new
         ETHTOOL_GLINKSETTINGS cmd. I was thinking of making this into 2
         separate cmds: 1 cmd ETHTOOL_GKERNELPROPERTIES which would be
         kernel-wide rather than device-specific, would return properties
         like "length of the link mode bitmaps", and possibly others. And
         ETHTOOL_GLINKSETTINGS would expect the proper bitmaps
       - the link mode bitmaps are piggybacked at tail of the new struct
         ethtool_link_settings. Since its user-visible definition does not
         assume specific bitmap width, I am using a 0-length array as the
         publicly visible placeholder. But then, the kernel needs to
         specialize it (struct ethtool_link_ksettings) to specify its
         current link mode masks. This means that kernel code is "littered"
         with "ksettings->base.field" to access "field" inside
         ethtool_settings:
         + I could use ethtool_link_settings everywhere (instead of a new
           ethtool_ksettings) and an container_of accessor (or a plain cast)
           to retrieve the link mode masks?
         + or: we could decide to make the link mode masks statically
           bounded again, ie. make their width public, but larger than
           current 32, and unchangeable forever. This would make everything
           straightforward, but we might hit limits later, or have an
           unneeded memory/stack usage for unused bits.
         any preference?
       - I foresee bugs where people use the legacy/deprecated SUPPORTED_x
         macros instead of the new ETHTOOL_LINK_MODE_x_BIT enums in the new
         get/set_link_ksettings callbacks. Not sure how to prevent problems
         with this.
      
      The only driver which was converted for now is mlx4. I am not
      considering fcoe as fully converted, but I updated it a minima to be
      able to remove __ethtool_get_settings, now known as
      __ethtool_get_link_ksettings.
      
      Tested with legacy and "future" ethtool on 64b x86 kernel and 32+64b
      ethtool, and on a 32b x86 kernel + 32b ethtool.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d3f2806
    • David Decotigny's avatar
      3d8f7cc7
    • David Decotigny's avatar
      net: ethtool: remove unused __ethtool_get_settings · 3237fc63
      David Decotigny authored
      replaced by __ethtool_get_link_ksettings.
      Signed-off-by: default avatarDavid Decotigny <decot@googlers.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3237fc63
    • David Decotigny's avatar
      7cad1bac
    • David Decotigny's avatar
      702b26a2
    • David Decotigny's avatar
      57709798
    • David Decotigny's avatar
      17605b96
    • David Decotigny's avatar
      008eb736
    • David Decotigny's avatar
      0ab6b544
    • David Decotigny's avatar
      85f95819