Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 10月, 2017 8 次提交
    • D
      Merge tag 'rxrpc-next-20171018' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 9854d758
      由 David S. Miller 提交于 
      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: NDavid S. Miller <davem@davemloft.net>
      9854d758
    • D
      Merge tag 'wireless-drivers-next-for-davem-2017-10-18' of... · 37320537
      由 David S. Miller 提交于 
      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: NDavid S. Miller <davem@davemloft.net>
      37320537
    • A
      net: sched: cls_u32: use hash_ptr() for tc_u_hash · d18b4b35
      由 Arnd Bergmann 提交于 
      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: NArnd Bergmann <arnd@arndb.de>
Acked-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d18b4b35
    • D
      tipc: checking for NULL instead of IS_ERR() · c75e427d
      由 Dan Carpenter 提交于 
      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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c75e427d
    • D
      Merge branch 'sh_eth-fallback-compat-strings' · 6575f354
      由 David S. Miller 提交于 
      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: NDavid S. Miller <davem@davemloft.net>
      6575f354
    • S
      net: sh_eth: implement R-Car Gen[12] fallback compatibility strings · b4804e0c
      由 Simon Horman 提交于 
      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: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4804e0c
    • S
      net: sh_eth: rename name structures as rcar_gen[12]_* · 6c4b2f7e
      由 Simon Horman 提交于 
      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: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c4b2f7e
    • S
      dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings · 87d9fa64
      由 Simon Horman 提交于 
      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: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87d9fa64
  3. 19 10月, 2017 24 次提交
  5. 18 10月, 2017 8 次提交