1. 26 Feb, 2016 22 commits
    • 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
    • David Decotigny's avatar
      314d10d7
    • David Decotigny's avatar
      9856909c
    • David Decotigny's avatar
      96a0c396
    • David Decotigny's avatar
      091a9277
    • David Decotigny's avatar
      net: ethtool: add new ETHTOOL_xLINKSETTINGS API · 3f1ac7a7
      David Decotigny authored
      This patch defines a new ETHTOOL_GLINKSETTINGS/SLINKSETTINGS API,
      handled by the new get_link_ksettings/set_link_ksettings callbacks.
      This API provides support for most legacy ethtool_cmd fields, adds
      support for larger link mode masks (up to 4064 bits, variable length),
      and removes ethtool_cmd deprecated
      fields (transceiver/maxrxpkt/maxtxpkt).
      
      This API is deprecating the legacy ETHTOOL_GSET/SSET API and provides
      the following backward compatibility properties:
       - legacy ethtool with legacy drivers: no change, still using the
         get_settings/set_settings callbacks.
       - legacy ethtool with new get/set_link_ksettings drivers: the new
         driver callbacks are used, data internally converted to legacy
         ethtool_cmd. ETHTOOL_GSET will return only the 1st 32b of each link
         mode mask. ETHTOOL_SSET will fail if user tries to set the
         ethtool_cmd deprecated fields to
         non-0 (transceiver/maxrxpkt/maxtxpkt). A kernel warning is logged if
         driver sets higher bits.
       - future ethtool with legacy drivers: no change, still using the
         get_settings/set_settings callbacks, internally converted to new data
         structure. Deprecated fields (transceiver/maxrxpkt/maxtxpkt) will be
         ignored and seen as 0 from user space. Note that that "future"
         ethtool tool will not allow changes to these deprecated fields.
       - future ethtool with new drivers: direct call to the new callbacks.
      
      By "future" ethtool, what is meant is:
       - query: first try ETHTOOL_GLINKSETTINGS, and revert to ETHTOOL_GSET if
         fails
       - set: query first and remember which of ETHTOOL_GLINKSETTINGS or
         ETHTOOL_GSET was successful
         + if ETHTOOL_GLINKSETTINGS was successful, then change config with
           ETHTOOL_SLINKSETTINGS. A failure there is final (do not try
           ETHTOOL_SSET).
         + otherwise ETHTOOL_GSET was successful, change config with
           ETHTOOL_SSET. A failure there is final (do not try
           ETHTOOL_SLINKSETTINGS).
      
      The interaction user/kernel via the new API requires a small
      ETHTOOL_GLINKSETTINGS handshake first to agree on the length of the link
      mode bitmaps. If kernel doesn't agree with user, it returns the bitmap
      length it is expecting from user as a negative length (and cmd field is
      0). When kernel and user agree, kernel returns valid info in all
      fields (ie. link mode length > 0 and cmd is ETHTOOL_GLINKSETTINGS).
      
      Data structure crossing user/kernel boundary is 32/64-bit
      agnostic. Converted internally to a legal kernel bitmap.
      
      The internal __ethtool_get_settings kernel helper will gradually be
      replaced by __ethtool_get_link_ksettings by the time the first
      "link_settings" drivers start to appear. So this patch doesn't change
      it, it will be removed before it needs to be changed.
      Signed-off-by: default avatarDavid Decotigny <decot@googlers.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f1ac7a7
    • David Decotigny's avatar
      48133335
    • David Decotigny's avatar
    • Tom Herbert's avatar
      net: Facility to report route quality of connected sockets · a87cb3e4
      Tom Herbert authored
      This patch add the SO_CNX_ADVICE socket option (setsockopt only). The
      purpose is to allow an application to give feedback to the kernel about
      the quality of the network path for a connected socket. The value
      argument indicates the type of quality report. For this initial patch
      the only supported advice is a value of 1 which indicates "bad path,
      please reroute"-- the action taken by the kernel is to call
      dst_negative_advice which will attempt to choose a different ECMP route,
      reset the TX hash for flow label and UDP source port in encapsulation,
      etc.
      
      This facility should be useful for connected UDP sockets where only the
      application can provide any feedback about path quality. It could also
      be useful for TCP applications that have additional knowledge about the
      path outside of the normal TCP control loop.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a87cb3e4
    • David Ahern's avatar
      net: ipv6: Make address flushing on ifdown optional · f1705ec1
      David Ahern authored
      Currently, all ipv6 addresses are flushed when the interface is configured
      down, including global, static addresses:
      
          $ ip -6 addr show dev eth1
          3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
              inet6 2100:1::2/120 scope global
                 valid_lft forever preferred_lft forever
              inet6 fe80::e0:f9ff:fe79:34bd/64 scope link
                 valid_lft forever preferred_lft forever
          $ ip link set dev eth1 down
          $ ip -6 addr show dev eth1
          << nothing; all addresses have been flushed>>
      
      Add a new sysctl to make this behavior optional. The new setting defaults to
      flush all addresses to maintain backwards compatibility. When the set global
      addresses with no expire times are not flushed on an admin down. The sysctl
      is per-interface or system-wide for all interfaces
      
          $ sysctl -w net.ipv6.conf.eth1.keep_addr_on_down=1
      or
          $ sysctl -w net.ipv6.conf.all.keep_addr_on_down=1
      
      Will keep addresses on eth1 on an admin down.
      
          $ ip -6 addr show dev eth1
          3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
              inet6 2100:1::2/120 scope global
                 valid_lft forever preferred_lft forever
              inet6 fe80::e0:f9ff:fe79:34bd/64 scope link
                 valid_lft forever preferred_lft forever
          $ ip link set dev eth1 down
          $ ip -6 addr show dev eth1
          3: eth1: <BROADCAST,MULTICAST> mtu 1500 state DOWN qlen 1000
              inet6 2100:1::2/120 scope global tentative
                 valid_lft forever preferred_lft forever
              inet6 fe80::e0:f9ff:fe79:34bd/64 scope link tentative
                 valid_lft forever preferred_lft forever
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1705ec1
  2. 25 Feb, 2016 18 commits