1. 20 Oct, 2017 8 commits
    • David S. Miller's avatar
      Merge tag 'rxrpc-next-20171018' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 9854d758
      David S. Miller authored
      David Howells says:
      
      ====================
      rxrpc: Add bits for kernel services
      
      Here are some patches that add a few things for kernel services to use:
      
       (1) Allow service upgrade to be requested and allow the resultant actual
           service ID to be obtained.
      
       (2) Allow the RTT time of a call to be obtained.
      
       (3) Allow a kernel service to find out if a call is still alive on a
           server between transmitting a request and getting the reply.
      
       (4) Allow data transmission to ignore signals if transmission progress is
           being made in reasonable time.  This is also usable by userspace by
           passing MSG_WAITALL to sendmsg()[*].
      
      [*] I'm not sure this is the right interface for this or whether a sockopt
          should be used instead.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9854d758
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-for-davem-2017-10-18' of... · 37320537
      David S. Miller authored
      Merge tag 'wireless-drivers-next-for-davem-2017-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for 4.15
      
      The first pull request for 4.15, unusually late this time but still
      relatively small. Also includes merge from wireless-drivers to fix
      conflicts in iwlwifi.
      
      Major changes:
      
      rsi
      
      * add P2P mode support
      
      * sdio suspend and resume support
      
      iwlwifi
      
      * A fix and an addition for PCI devices for the A000 family
      
      * Dump PCI registers when an error occurs, to make it easier to debug
      
      rtlwifi
      
      * add support for 64 bit DMA, enabled with a module parameter
      
      * add module parameter to enable ASPM
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37320537
    • Arnd Bergmann's avatar
      net: sched: cls_u32: use hash_ptr() for tc_u_hash · d18b4b35
      Arnd Bergmann authored
      After the change to the tp hash, we now get a build warning
      on 32-bit architectures:
      
      net/sched/cls_u32.c: In function 'tc_u_hash':
      net/sched/cls_u32.c:338:17: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
        return hash_64((u64) tp->chain->block, U32_HASH_SHIFT);
      
      Using hash_ptr() instead of hash_64() lets us drop the cast
      and fixes the warning while still resulting in the same hash
      value.
      
      Fixes: 7fa9d974 ("net: sched: cls_u32: use block instead of q in tc_u_common")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d18b4b35
    • Dan Carpenter's avatar
      tipc: checking for NULL instead of IS_ERR() · c75e427d
      Dan Carpenter authored
      The tipc_alloc_conn() function never returns NULL, it returns error
      pointers, so I have fixed the check.
      
      Fixes: 14c04493 ("tipc: add ability to order and receive topology events in driver")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c75e427d
    • David S. Miller's avatar
      Merge branch 'sh_eth-fallback-compat-strings' · 6575f354
      David S. Miller authored
      Simon Horman says:
      
      ====================
      net: sh_eth: add R-Car Gen[12] fallback compatibility strings
      
      Add fallback compatibility strings for R-Car Gen 1 and 2.
      
      In the case of Renesas R-Car hardware we know that there are generations of
      SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
      between IP blocks might be. For example, I believe that r8a7790 is older
      than r8a7791 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 is being adopted for
      drivers for Renesas SoCs.
      
      Changes since v1:
      * Correct typos in changelogs
      * Consistently use tabs for indentation in bindings document
      * Enhance readability of description of bindings usage
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6575f354
    • Simon Horman's avatar
      net: sh_eth: implement R-Car Gen[12] fallback compatibility strings · b4804e0c
      Simon Horman authored
      Implement fallback compatibility strings for R-Car Gen 1 and 2.
      
      In the case of Renesas R-Car hardware we know that there are generations of
      SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
      between IP blocks might be. For example, I believe that r8a7790 is older
      than r8a7791 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 is being adopted for
      drivers for Renesas SoCs.
      
      Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks.  The
      approach that has been consistently taken for other IP blocks is to name
      common code, compatibility strings and so on after R-Car Gen2.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4804e0c
    • Simon Horman's avatar
      net: sh_eth: rename name structures as rcar_gen[12]_* · 6c4b2f7e
      Simon Horman authored
      Rename structures describing R-Car SoCs as rcar_gen[12]_*
      rather than r8a77[79]x_*. This seems a little easier on the
      eyes. And will make things slightly cleaner in a follow-up
      patch that adds fallback-compatibility strings for these SoCs.
      
      Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks.  The
      approach that has been consistently taken for other IP blocks is to name
      common code, compatibility strings and so on after R-Car Gen2.
      
      Also rename sh_eth_set_rate_r8a777x as sh_eth_set_rate_rcar as
      it it is used by the R-Car generations supported by the driver.
      
      This patch should have no run-time effect and
      is compile-tested only.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c4b2f7e
    • Simon Horman's avatar
      dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings · 87d9fa64
      Simon Horman authored
      Add fallback compatibility strings for R-Car Gen 1 and 2.
      
      In the case of Renesas R-Car hardware we know that there are generations of
      SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
      between IP blocks might be. For example, I believe that r8a7790 is older
      than r8a7791 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 is being adopted for
      drivers for Renesas SoCs.
      
      Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks.  The
      approach that has been consistently taken for other IP blocks is to name
      common code, compatibility strings and so on after R-Car Gen2.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87d9fa64
  2. 19 Oct, 2017 24 commits
  3. 18 Oct, 2017 8 commits