RE: [Intel-wired-lan] [PATCH net-next v1 5/7] i40e: convert to new udp_tunnel infrastructure

> From: Intel-wired-lan On Behalf Of Jakub > Kicinski > Sent: Tuesday, July 21, 2020 6:27 PM > To: da...@davemloft.net > Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Jakub Kicinski > > Subject: [Intel-wired-lan] [PATCH net-next v1 5/7] i40e: convert to new > udp_tunnel infrastruc

RE: [Intel-wired-lan] [PATCH net-next v1 4/7] selftests: net: add a test for shared UDP tunnel info tables

> From: Intel-wired-lan On Behalf Of Jakub > Kicinski > Sent: Tuesday, July 21, 2020 6:27 PM > To: da...@davemloft.net > Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Jakub Kicinski > > Subject: [Intel-wired-lan] [PATCH net-next v1 4/7] selftests: net: add a test > for > shared U

[PATCH net-next] net: neterion: Remove set but not used variable

Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/neterion/vxge/vxge-traffic.c: In function vxge_hw_vpath_intr_disable: drivers/net/ethernet/neterion/vxge/vxge-traffic.c:160:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable] drivers/net/ethernet/neterion

[PATCH] rtlwifi: rtl8192ee: use true,false for bool variable large_cfo_hit

This addresses the following coccinelle warning: drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:721:27-47: WARNING: Comparison of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:722:3-23: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi

[PATCH] rtlwifi: rtl8821ae: use true,false for bool variable large_cfo_hit

This addresses the following coccinelle warning: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2680:27-47: WARNING: Comparison of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2683:3-23: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwi

[PATCH] rtlwifi: rtl8723be: use true,false for bool variable large_cfo_hit

This addresses the following coccinelle warning: drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c:1155:27-47: WARNING: Comparison of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c:1156:3-23: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwi

[PATCH net-next] net: qed: use true,false for bool variables

This addresses the following coccinelle warning: drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:2-13: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/qlogic/qed/qed_rdma.c:1468:2-14: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/qlogic/qed/qed_rdma.c:1471:2-13:

[PATCH net-next] net: b44: use true,false for bool variables

This addresses the following coccinelle warning: drivers/net/ethernet/broadcom/b44.c:2213:6-20: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/broadcom/b44.c:2218:2-16: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/broadcom/b44.c:2226:3-17: WARNING: Assignment

[PATCH net-next] bnx2x: use true,false for bool variables

This addresses the following coccinelle warning: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:15415:1-26: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:12393:2-17: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/broadcom/bnx2x/bnx

[PATCH net-next] net: ethernet: ti: cpsw: use true,false for bool variables

This addresses the following coccinelle warning: drivers/net/ethernet/ti/cpsw.c:1599:2-17: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/ti/cpsw.c:1300:2-17: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: Jason Yan --- drivers/net/ethernet

[PATCH net-next] 8139too: use true,false for bool variables

This addresses the following coccinelle warning: drivers/net/ethernet/realtek/8139too.c:981:2-8: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: Jason Yan --- drivers/net/ethernet/realtek/8139too.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote: > On Fri, Sep 18, 2020 at 03:19:05PM +0300, Leon Romanovsky wrote: > > > So we do have an open-source library called hl-thunk, which uses our > > > driver and indeed that was part of the requirement. > > > It is similar to libdrm.

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote: > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote: > > On Fri, Sep 18, 2020 at 03:19:05PM +0300, Leon Romanovsky wrote: > > > > So we do have an open-source library called hl-thunk, which uses our > > > > driver and

RE: [PATCH v3,net-next,0/4] Add Support for Marvell OcteonTX2 Cryptographic

> Subject: Re: [PATCH v3,net-next,0/4] Add Support for Marvell OcteonTX2 > Cryptographic > > On Thu, 2020-09-17 at 18:58 +0530, Srujana Challa wrote: > > The following series adds support for Marvell Cryptographic > > Acceleration > > Unit(CPT) on OcteonTX2 CN96XX SoC. > > This series is tested wi

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 10:30:12AM +0200, Greg Kroah-Hartman wrote: > On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote: > > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Sep 18, 2020 at 03:19:05PM +0300, Leon Romanovsky wrote: > > > > > So we do ha

Re: [PATCH bpf-next v6 05/10] bpf: support attaching freplace programs to multiple attach points

Andrii Nakryiko writes: > On Thu, Sep 17, 2020 at 1:21 PM Toke Høiland-Jørgensen > wrote: >> >> From: Toke Høiland-Jørgensen >> >> This enables support for attaching freplace programs to multiple attach >> points. It does this by amending the UAPI for bpf_link_Create with a target >> btf ID th

Re: [PATCH v2 0/2] dt-bindings: can: document R8A774E1

Hi Wolfgang, Marc, David, On Thu, Aug 27, 2020 at 4:30 PM Lad Prabhakar wrote: > > Hi All, > > Both the patches are part of series [1] (patch 18/20, 19/20), > rest of the patches have been acked/merged so just sending > two patches from the series. > > [1] https://lkml.org/lkml/2020/7/15/515 > >

[PATCH iproute2-next RFC] ip xfrm: support setting XFRMA_SET_MARK_MASK attribute in states

The XFRMA_SET_MARK_MASK attribute can be set in states (4.19+) It is optional and the kernel default is 0x It is the mask of XFRMA_SET_MARK(a.k.a. XFRMA_OUTPUT_MARK in 4.18) e.g. ./ip/ip xfrm state add output-mark 0x6 mask 0xab proto esp \ auth digest_null 0 enc cipher_null '' ip xfrm sta

[PATCH iproute2-next RFC] ip xfrm: support setting XFRMA_SET_MARK_MASK attribute in states

The XFRMA_SET_MARK_MASK attribute can be set in states (4.19+) It is the mask of XFRMA_SET_MARK(a.k.a. XFRMA_OUTPUT_MARK in 4.18) It is optional and the kernel default is 0x e.g. ./ip/ip xfrm state add output-mark 0x6 mask 0xab proto esp \ auth digest_null 0 enc cipher_null '' ip xfrm sta

[PATCH net-netx] net: renesas: sh_eth: suppress initialized field overwritten warning

Suppress a bunch of warnings of the form: drivers/net/ethernet/renesas/sh_eth.c:100:13: warning: initialized field overwritten [-Woverride-init] This is because after the sh_eth_offset_xxx array is initialized to SH_ETH_OFFSET_INVALID, some specific register_offsets are re-initialized. It wasn'

Re: [PATCH 05/20] dt-bindings: timer: renesas,cmt: Document r8a774e1 CMT support

Hi Daniel and Thomas, On Thu, Aug 27, 2020 at 6:00 PM Lad, Prabhakar wrote: > > Hi Daniel and Thomas, > > On Wed, Jul 15, 2020 at 12:09 PM Lad Prabhakar > wrote: > > > > Document SoC specific bindings for RZ/G2H (r8a774e1) SoC. > > > > Signed-off-by: Lad Prabhakar > > --- > > Documentation/dev

Re: [PATCH 02/20] dt-bindings: thermal: rcar-gen3-thermal: Add r8a774e1 support

Hi Niklas/Zhang/Daniel, On Thu, Aug 27, 2020 at 5:52 PM Lad, Prabhakar wrote: > > Hi Zhang,Daniel,Amit, > > On Wed, Jul 15, 2020 at 12:09 PM Lad Prabhakar > wrote: > > > > Document RZ/G2H (R8A774E1) SoC bindings. > > > > Signed-off-by: Lad Prabhakar > > --- > > Documentation/devicetree/binding

Re: [PATCH 8/9] dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC

Hi David, On Thu, Aug 27, 2020 at 11:28 AM Lad, Prabhakar wrote: > > Hi David, > > On Mon, Jul 13, 2020 at 10:36 PM Lad Prabhakar > wrote: > > > > From: Marian-Cristian Rotariu > > > > Document RZ/G2H (R8A774E1) SoC bindings. > > > > Signed-off-by: Marian-Cristian Rotariu > > > > Signed-off-b

Re: [PATCH 05/20] dt-bindings: timer: renesas,cmt: Document r8a774e1 CMT support

On 19/09/2020 13:00, Lad, Prabhakar wrote: > Hi Daniel and Thomas, > > On Thu, Aug 27, 2020 at 6:00 PM Lad, Prabhakar > wrote: >> >> Hi Daniel and Thomas, >> >> On Wed, Jul 15, 2020 at 12:09 PM Lad Prabhakar >> wrote: >>> >>> Document SoC specific bindings for RZ/G2H (r8a774e1) SoC. >>> >>> Sign

Re: [PATCH 02/20] dt-bindings: thermal: rcar-gen3-thermal: Add r8a774e1 support

On 19/09/2020 13:05, Lad, Prabhakar wrote: > Hi Niklas/Zhang/Daniel, > > On Thu, Aug 27, 2020 at 5:52 PM Lad, Prabhakar > wrote: >> >> Hi Zhang,Daniel,Amit, >> >> On Wed, Jul 15, 2020 at 12:09 PM Lad Prabhakar >> wrote: >>> >>> Document RZ/G2H (R8A774E1) SoC bindings. >>> >>> Signed-off-by: Lad

Re: [PATCH] net/sched: cbs: fix calculation error of idleslope credits

Hi Xiaoyong, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.9-rc5 next-20200918] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as docume

[PATCH bpf-next v7 01/10] bpf: disallow attaching modify_return tracing functions to other BPF programs

From: Toke Høiland-Jørgensen >From the checks and commit messages for modify_return, it seems it was never the intention that it should be possible to attach a tracing program with expected_attach_type == BPF_MODIFY_RETURN to another BPF program. However, check_attach_modify_return() will only lo

[PATCH bpf-next v7 02/10] bpf: change logging calls from verbose() to bpf_log() and use log pointer

From: Toke Høiland-Jørgensen In preparation for moving code around, change a bunch of references to env->log (and the verbose() logging helper) to use bpf_log() and a direct pointer to struct bpf_verifier_log. While we're touching the function signature, mark the 'prog' argument to bpf_check_type

[PATCH bpf-next v7 08/10] selftests: add test for multiple attachments of freplace program

From: Toke Høiland-Jørgensen This adds a selftest for attaching an freplace program to multiple targets simultaneously. Signed-off-by: Toke Høiland-Jørgensen --- .../selftests/bpf/prog_tests/fexit_bpf2bpf.c | 157 .../selftests/bpf/progs/freplace_get_constant.c|

[PATCH bpf-next v7 10/10] selftests: Add selftest for disallowing modify_return attachment to freplace

From: Toke Høiland-Jørgensen This adds a selftest that ensures that modify_return tracing programs cannot be attached to freplace programs. The security_ prefix is added to the freplace program because that would otherwise let it pass the check for modify_return. Signed-off-by: Toke Høiland-Jørg

[PATCH bpf-next v7 05/10] bpf: support attaching freplace programs to multiple attach points

From: Toke Høiland-Jørgensen This enables support for attaching freplace programs to multiple attach points. It does this by amending the UAPI for bpf_link_Create with a target btf ID that can be used to supply the new attachment point along with the target program fd. The target must be compatib

[PATCH bpf-next v7 09/10] selftests/bpf: Adding test for arg dereference in extension trace

From: Jiri Olsa Adding test that setup following program: SEC("classifier/test_pkt_md_access") int test_pkt_md_access(struct __sk_buff *skb) with its extension: SEC("freplace/test_pkt_md_access") int test_pkt_md_access_new(struct __sk_buff *skb) and tracing that extension with: SEC

[PATCH bpf-next v7 07/10] libbpf: add support for freplace attachment in bpf_link_create

From: Toke Høiland-Jørgensen This adds support for supplying a target btf ID for the bpf_link_create() operation, and adds a new bpf_program__attach_freplace() high-level API for attaching freplace functions with a target. Signed-off-by: Toke Høiland-Jørgensen --- tools/lib/bpf/bpf.c |

[PATCH bpf-next v7 04/10] bpf: move prog->aux->linked_prog and trampoline into bpf_link on attach

From: Toke Høiland-Jørgensen In preparation for allowing multiple attachments of freplace programs, move the references to the target program and trampoline into the bpf_tracing_link structure when that is created. To do this atomically, introduce a new mutex in prog->aux to protect writing to th

[PATCH bpf-next v7 03/10] bpf: verifier: refactor check_attach_btf_id()

From: Toke Høiland-Jørgensen The check_attach_btf_id() function really does three things: 1. It performs a bunch of checks on the program to ensure that the attachment is valid. 2. It stores a bunch of state about the attachment being requested in the verifier environment and struct bpf_p

[PATCH bpf-next v7 00/10] bpf: Support multi-attach for freplace programs

This series adds support attaching freplace BPF programs to multiple targets. This is needed to support incremental attachment of multiple XDP programs using the libxdp dispatcher model. The first patch fixes an issue that came up in review: The verifier will currently allow MODIFY_RETURN tracing

[PATCH bpf-next v7 06/10] bpf: Fix context type resolving for extension programs

From: Toke Høiland-Jørgensen Eelco reported we can't properly access arguments if the tracing program is attached to extension program. Having following program: SEC("classifier/test_pkt_md_access") int test_pkt_md_access(struct __sk_buff *skb) with its extension: SEC("freplace/test_pkt

Re: [PATCH] SUNRPC: Flush dcache only when receiving more seeking

On 9/19/20 12:23 AM, Chuck Lever wrote: > >> On Sep 18, 2020, at 8:50 AM, zhe...@windriver.com wrote: >> >> From: He Zhe >> >> commit ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()") introduces >> svc_flush_bvec to after sock_recvmsg, but sometimes we receive less than we >> seek, which trigger

RE: let import_iovec deal with compat_iovecs as well

From: Christoph Hellwig > Sent: 18 September 2020 13:45 > > this series changes import_iovec to transparently deal with comat iovec > structures, and then cleanups up a lot of code dupliation. But to get > there it first has to fix the pre-existing bug that io_uring compat > contexts don't trigge

[PATCH net-next RFC v1 2/4] net: dsa: Add devlink port regions support to DSA

Allow DSA drivers to make use of devlink port regions, via simple wrappers. Signed-off-by: Andrew Lunn --- include/net/dsa.h | 5 + net/core/devlink.c | 3 +-- net/dsa/dsa.c | 14 ++ 3 files changed, 20 insertions(+), 2 deletions(-) diff --git a/include/net/dsa.h b/inclu

[PATCH net-next RFC v1 3/4] net: dsa: Add helper for converting devlink port to ds and port

Hide away from DSA drivers how devlink works. Signed-off-by: Andrew Lunn --- include/net/dsa.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/include/net/dsa.h b/include/net/dsa.h index 01da896b2998..a24d5158ee0c 100644 --- a/include/net/dsa.h +++ b/include/net/dsa.h @@ -685

[PATCH net-next RFC v1 4/4] net: dsa: mv88e6xxx: Add per port devlink regions

Add a devlink region to return the per port registers. Signed-off-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx/chip.c| 8 drivers/net/dsa/mv88e6xxx/devlink.c | 61 + drivers/net/dsa/mv88e6xxx/devlink.h | 6 ++- 3 files changed, 74 insertions(+), 1 deletion

[PATCH net-next RFC v1 1/4] net: devlink: Add support for port regions

Allow regions to be registered to a devlink port. The same netlink API is used, but the port index is provided to indicate when a region is a port region as opposed to a device region. Signed-off-by: Andrew Lunn --- include/net/devlink.h | 27 + net/core/devlink.c| 251 +

[PATCH net-next RFC v1 0/4] Add per port devlink regions

This patchset extends devlink regions to support per port regions, and them makes use of them to support the ports of the mv88e6xxx switches. root@rap:~# devlink region show mdio_bus/gpio-0:00/global1: size 64 snapshot [] mdio_bus/gpio-0:00/global2: size 64 snapshot [] mdio_bus/gpio-0:00/atu: size

RE: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

From: Al Viro > Sent: 18 September 2020 14:58 > > On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote: > > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote: > > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */ > > > > - return pt_regs_trap_type(current_pt_regs(

Re: investment interest from Engr: Kofi Sarpong Please go through and get back to me.

Lukoil Overseas Gh. Ltd. Oil & Gas Extraction Companies No. 68 Mankralo Street East Cantonments Accra Ghana. Dear: Reem Awwaad My name is Engr: Kofi Koduah Sarpong. I am the Chief Executive Officer of Lukoil Overseas Gh. Ltd Ghana. I will be retiring from my work by June next year. I write to inf

Re: investment interest from Engr: Kofi Sarpong Please go through and get back to me.

Lukoil Overseas Gh. Ltd. Oil & Gas Extraction Companies No. 68 Mankralo Street East Cantonments Accra Ghana. Dear: Sir My name is Engr: Kofi Koduah Sarpong. I am the Chief Executive Officer of Lukoil Overseas Gh. Ltd Ghana. I will be retiring from my work by June next year. I write to inform you

Re: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook

Hi Daniel, Long time no see, unfortunately this complicated situation is keeping us away from personal reach, that's unfortunate. Now, looking into this topic... On Fri, Sep 18, 2020 at 10:31:09PM +0200, Daniel Borkmann wrote: > [...] That is if there is an opt-in to such data path being used, th

Re: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook

Hi Lukas, On Thu, Aug 27, 2020 at 10:55:03AM +0200, Lukas Wunner wrote: [...] > Overall, performance improves with this commit if neither netfilter nor > traffic control is used. However it degrades a little if only traffic > control is used, due to the "noinline", the additional outer static key

Re: [PATCH iproute2-next] ip: promote missed packets to the -s row

On Fri, 18 Sep 2020 22:52:56 -0600 David Ahern wrote: > On 9/18/20 9:48 AM, Jakub Kicinski wrote: > > On Fri, 18 Sep 2020 09:44:35 -0600 David Ahern wrote: > >> On 9/16/20 1:42 PM, Jakub Kicinski wrote: > >>> 2: eth0: mtu 1500 qdisc mq state UP > >>> mode DEFAULT group default qlen 1000 > >

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote: > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > Said that, why not provide a variant that would take an explicit > > "is it compat" argument and use it there? And have the normal > > one pass in_compat_syscall() to that...

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 11:30 AM Greg Kroah-Hartman wrote: > > On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote: > > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Sep 18, 2020 at 03:19:05PM +0300, Leon Romanovsky wrote: > > > > > So we do have an

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote: > On Sat, Sep 19, 2020 at 11:30 AM Greg Kroah-Hartman > wrote: > > > > On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote: > > > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote: > > > > On Fri, Sep 18, 202

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote: > It's probably heresy, but why do I need to integrate into the RDMA subsystem ? Hi Oded I don't know the RDMA subsystem at all. So i will give a more generic answer. Are you reinventing things which a subsystem core already has? The su

[PATCH RFC/RFT 0/2] W=1 by default for Ethernet PHY subsystem

There is a movement to make the code base compile clean with W=1. Some subsystems are already clean. In order to keep them clean, we need developers to build new code with W=1 by default in these subsystems. This patchset refactors the core Makefile warning code to allow the additional warnings W=

[PATCH RFC/RFT 2/2] net: phylib: Enable W=1 by default

Add to the subdirectory ccflags variable the additional compiler warnings which W=1 adds at the top level when enabled. Signed-off-by: Andrew Lunn --- drivers/net/mdio/Makefile | 3 +++ drivers/net/pcs/Makefile | 3 +++ drivers/net/phy/Makefile | 3 +++ 3 files changed, 9 insertions(+) diff -

[PATCH RFC/RFT 1/2] scripts: Makefile.extrawarn: Add W=1 warnings to a symbol

There is a desire that subtrees can enable W=1 by default. To make this possible, put the extra compiler flags into an exported variable, so other Makefiles can make use of them. Signed-off-by: Andrew Lunn --- scripts/Makefile.extrawarn | 33 ++--- 1 file changed, 18

Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver

On Sat, Sep 19, 2020 at 07:27:30PM +0200, Greg Kroah-Hartman wrote: > > It's probably heresy, but why do I need to integrate into the RDMA > > subsystem ? > > I understand your reasoning about networking (Ethernet) as the driver > > connects to the kernel networking stack (netdev), but with RDMA t

[PATCH v2] net: dsa: mt7530: Add some return-value checks

In mt7531_cpu_port_config(), if the variable port is neither 5 nor 6, then variable interface will be used uninitialised. Change the function to return -EINVAL in this case. As the return value of mt7531_cpu_port_config() is never checked (even though it returns an int) add a check in the correct

Re: [PATCH net-next] net: microchip: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 10:37:32 +0800 > `ret` is never used, so remove it. You are not removing it: > @@ -3053,7 +3053,7 @@ static int lan743x_pm_suspend(struct device *dev) > /* Host sets PME_En, put D3hot */ > ret = pci_prepare_to_sleep(pdev); > > - retur

Re: [PATCH net-next] net: microchip: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 10:39:09 +0800 > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/net/ethernet/microchip/lan743x_main.c: In function lan743x_pm_suspend: > drivers/net/ethernet/microchip/lan743x_main.c:3041:6: warning: variable ‘ret’ > set but not used [-Wunu

Re: [PATCH net-next] net: natsemi: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 10:46:44 +0800 > @@ -1226,8 +1226,8 @@ static int ns83820_get_link_ksettings(struct net_device > *ndev, > > /* read current configuration */ > cfg = readl(dev->base + CFG) ^ SPDSTS_POLARITY; > - tanar = readl(dev->base + TANAR); >

Re: 答复: [PATCH net-next] net: microchip: Remove set but not used variable

From: zhengyongjun Date: Sat, 19 Sep 2020 03:02:39 + > This is the bad patch, please ignore it, thank you very much. Please do not quote your entire patch when you reply like this. It makes the reply look like a brand new patch to our patchwork tracking system, which makes more work for us.

Re: [PATCH net-next] net: marvell: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 10:05:50 +0800 > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/net/ethernet/marvell/pxa168_eth.c: In function pxa168_eth_change_mtu: > drivers/net/ethernet/marvell/pxa168_eth.c:1190:6: warning: variable ‘retval’ > set but not used [-Wunuse

Re: [PATCH net-next] net: e1000: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 09:50:20 +0800 > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/net/ethernet/intel/e1000/e1000_hw.c: In function > e1000_phy_init_script: > drivers/net/ethernet/intel/e1000/e1000_hw.c:132:6: warning: variable > ‘ret_val’ set but not used [

Re: [PATCH net-next] net: liquidio: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 09:31:23 +0800 > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function > lio_pci_readq: > drivers/net/ethernet/cavium/liquidio/octeon_device.c:1327:6: warning: > variable ‘val32’ set but n

Re: [PATCH net-next] net: micrel: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 10:32:35 +0800 > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/net/ethernet/micrel/ksz884x.c: In function rx_proc: > drivers/net/ethernet/micrel/ksz884x.c:4981:6: warning: variable ‘rx_status’ > set but not used [-Wunused-but-set-variable]

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote: > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote: > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > > Said that, why not provide a variant that would take an explicit > > > "is it compat" argument and use it there? An

Re: [PATCH net-next] net: neterion: Remove set but not used variable

From: Zheng Yongjun Date: Sat, 19 Sep 2020 15:40:47 +0800 > @@ -179,7 +175,7 @@ enum vxge_hw_status vxge_hw_vpath_intr_disable( > (u32)VXGE_HW_INTR_MASK_ALL, > &vp_reg->vpath_general_int_mask); > > - val64 = VXGE_HW_TIM_CLR_INT_EN_VP(1 << (16 - vpath->vp_id)); >

Re: [PATCH net-next] net: qed: use true,false for bool variables

From: Jason Yan Date: Sat, 19 Sep 2020 15:45:43 +0800 > This addresses the following coccinelle warning: > > drivers/net/ethernet/qlogic/qed/qed_rdma.c:1465:2-13: WARNING: > Assignment of 0/1 to bool variable > drivers/net/ethernet/qlogic/qed/qed_rdma.c:1468:2-14: WARNING: > Assignment of 0/1 to

Re: [PATCH net-next] net: b44: use true,false for bool variables

From: Jason Yan Date: Sat, 19 Sep 2020 15:45:27 +0800 > This addresses the following coccinelle warning: > > drivers/net/ethernet/broadcom/b44.c:2213:6-20: WARNING: Assignment of > 0/1 to bool variable > drivers/net/ethernet/broadcom/b44.c:2218:2-16: WARNING: Assignment of > 0/1 to bool variable

Re: [PATCH net-next] bnx2x: use true,false for bool variables

From: Jason Yan Date: Sat, 19 Sep 2020 15:45:56 +0800 > This addresses the following coccinelle warning: > > drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:15415:1-26: WARNING: > Assignment of 0/1 to bool variable > drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:12393:2-17: WARNING: > Assign

Re: [PATCH net-next] 8139too: use true,false for bool variables

From: Jason Yan Date: Sat, 19 Sep 2020 15:46:09 +0800 > This addresses the following coccinelle warning: > > drivers/net/ethernet/realtek/8139too.c:981:2-8: WARNING: Assignment of > 0/1 to bool variable > > Reported-by: Hulk Robot > Signed-off-by: Jason Yan Applied.

Re: [PATCH net-next] net: ethernet: ti: cpsw: use true,false for bool variables

From: Jason Yan Date: Sat, 19 Sep 2020 15:46:17 +0800 > This addresses the following coccinelle warning: > > drivers/net/ethernet/ti/cpsw.c:1599:2-17: WARNING: Assignment of 0/1 to > bool variable > drivers/net/ethernet/ti/cpsw.c:1300:2-17: WARNING: Assignment of 0/1 to > bool variable > > Repo

[PATCH 1/4] mtd: Add nvmem support for mtd nvmem-providers

Introduce 2 new bindings for the mtd structure. Mtd partitions can be set as 'nvmem-provider' and any subpartition defined with the tag 'nvmem-cell' are skipped by the 'fixed-partitions' parser and registred as a nvmem cell by the nvmem api. Signed-off-by: Ansuel Smith --- drivers/mtd/mtdcore.c

[PATCH 2/4] dt-bindings: mtd: partition: Document use of nvmem-provider

Document the use of this 2 new bindings, nvmem-provider and nvmem-cell, used to describe the nvmem cell that the subpartition provide to the nvmem api and the system. Nvmem cell are direct subnode of the subpartition and are skipped by the 'fixed-partitions' parser if they contain the 'nvmem-cell'

[PATCH 3/4] of_net: add mac-address-increment support

Lots of embedded devices use the mac-address of other interface extracted from nvmem cells and increments it by one or two. Add two bindings to integrate this and directly use the right mac-address for the interface. Some example are some routers that use the gmac mac-address stored in the art part

[PATCH 4/4] dt-bindings: net: Document use of mac-address-increment

Two new bindings are now supported by the of_net driver to increase (or decrease) a mac-address. This can be very useful in case where the system extract the mac-address for the device from a dedicated partition and have a generic mac-address that needs to be incremented based on the device number.

[PATCH 0/4] Actually implement nvmem support for mtd

The mtd support for the nvmem api has been stalled from 2018 with a patch half pushed hoping that a scheme is found for the mtd name later. This pathset try to address this and add a very needed feature for the mac-address. My solution to the already discussed problem here [1] is to keep it simple

[PATCH] net: dsa: rtl8366rb: Roof MTU for switch

The MTU setting for this DSA switch is global so we need to keep track of the MTU set for each port, then as soon as any MTU changes, roof the MTU to the biggest common denominator and poke that into the switch MTU setting. To achieve this we need a per-chip-variant state container for the RTL8366

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, 19 Sep 2020, Arnd Bergmann wrote: > On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote: > > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote: > > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > > > Said that, why not provide a variant that would take an explicit

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > Said that, why not provide a variant that would take an explicit > > "is it compat" argument and use it there? And have the normal > > one pass in_compat_syscall() to t

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote: > > On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote: >>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote: >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: Said that, why not provide a variant that would take a

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

> On Sep 19, 2020, at 3:09 PM, Al Viro wrote: > > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: >>> Said that, why not provide a variant that would take an explicit >>> "is it compat" argument and use it there?

[PATCH v2 0/4] Actually implement nvmem support for mtd

The mtd support for the nvmem api has been stalled from 2018 with a patch half pushed hoping that a scheme is found for the mtd name later. This pathset try to address this and add a very needed feature for the mac-address. My solution to the already discussed problem here [1] is to keep it simple

[PATCH v2 1/4] mtd: Add nvmem support for mtd nvmem-providers

Introduce 2 new bindings for the mtd structure. Mtd partitions can be set as 'nvmem-provider' and any subpartition defined with the tag 'nvmem-cell' are skipped by the 'fixed-partitions' parser and registred as a nvmem cell by the nvmem api. Signed-off-by: Ansuel Smith --- drivers/mtd/mtdcore.c

[PATCH v2 4/4] dt-bindings: net: Document use of mac-address-increment

Two new bindings are now supported by the of_net driver to increase (or decrease) a mac-address. This can be very useful in case where the system extract the mac-address for the device from a dedicated partition and have a generic mac-address that needs to be incremented based on the device number.

[PATCH v2 2/4] dt-bindings: mtd: partition: Document use of nvmem-provider

Document the use of this 2 new bindings, nvmem-provider and nvmem-cell, used to describe the nvmem cell that the subpartition provide to the nvmem api and the system. Nvmem cell are direct subnode of the subpartition and are skipped by the 'fixed-partitions' parser if they contain the 'nvmem-cell'

[PATCH v2 3/4] of_net: add mac-address-increment support

Lots of embedded devices use the mac-address of other interface extracted from nvmem cells and increments it by one or two. Add two bindings to integrate this and directly use the right mac-address for the interface. Some example are some routers that use the gmac mac-address stored in the art part

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote: > > > On Sep 19, 2020, at 3:09 PM, Al Viro wrote: > > > > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: > >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > >>> Said that, why not provide a variant

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

> On Sep 19, 2020, at 3:41 PM, Al Viro wrote: > > On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote: >> On Sep 19, 2020, at 3:09 PM, Al Viro wrote: >>> >>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: > On Fri, Sep 18, 2020 at 02:58:22PM +0100,

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote: > > It would not be a win - most of the syscalls don't give a damn > > about 32bit vs. 64bit... > > Any reasonable implementation would optimize it out for syscalls that don’t > care. Or it could be explicit: > > DEFINE_MULTIARCH

Re: [PATCH 1/2] ethtool: improve compat ioctl handling

From: Arnd Bergmann Date: Fri, 18 Sep 2020 14:05:18 +0200 > --- a/net/ethtool/ioctl.c > +++ b/net/ethtool/ioctl.c ... > +static inline bool ethtool_translate_compat(void) > +{ Please don't use the inline keyword in foo.c files. Thank you.

Re: [PATCH net-next] net/packet: Fix a comment about network_header

From: Xie He Date: Fri, 18 Sep 2020 06:56:16 -0700 > skb->nh.raw has been renamed as skb->network_header in 2007, in > commit b0e380b1d8a8 ("[SK_BUFF]: unions of just one member don't get > anything done, kill them") > > So here we change it to the new name. > > Cc: Willem

Re: [pull request][net 00/15] mlx5 Fixes 2020-09-18

From: sa...@kernel.org Date: Fri, 18 Sep 2020 10:28:24 -0700 > ('net/mlx5e: Protect encap route dev from concurrent release') I'm being asked to queue this up for -stable, but this change does not exist in this pull request. Please sort this out and resubmit. Thank you.

Re: [PATCH 1/3] gve: Add support for raw addressing device option

From: David Awogbemila Date: Fri, 18 Sep 2020 11:07:18 -0700 > @@ -514,10 +517,54 @@ int gve_adminq_describe_device(struct gve_priv *priv) > priv->rx_pages_per_qpl = be16_to_cpu(descriptor->rx_pages_per_qpl); > if (priv->rx_pages_per_qpl < priv->rx_desc_cnt) { > dev_err(

Re: [PATCH 2/3] gve: Add support for raw addressing to the rx path

From: David Awogbemila Date: Fri, 18 Sep 2020 11:07:19 -0700 > @@ -514,11 +516,11 @@ int gve_adminq_describe_device(struct gve_priv *priv) > mac = descriptor->mac; > dev_info(&priv->pdev->dev, "MAC addr: %pM\n", mac); > priv->tx_pages_per_qpl = be16_to_cpu(descriptor->tx_pages_p

Re: [PATCH net-next v2 0/3] 100base Fx link modes

From: Dan Murphy Date: Fri, 18 Sep 2020 14:14:50 -0500 > As per patch https://lore.kernel.org/patchwork/patch/1300241/ the link > modes for 100base FX full and half duplex modes did not exist. Adding these > link modes to the core and ethtool allow devices like the DP83822, DP83869 and > Broadco

Re: [PATCH] net: dsa: rtl8366rb: Roof MTU for switch

> static int rtl8366rb_setup(struct dsa_switch *ds) > { > struct realtek_smi *smi = ds->priv; > + struct rtl8366rb *rb = smi->chip_data; > const u16 *jam_table; > u32 chip_ver = 0; > u32 chip_id = 0; Hi Linus Reverse Christmas tree means you need to do the assignment

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

On Sat, Sep 19, 2020 at 4:24 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote: > > > > It would not be a win - most of the syscalls don't give a damn > > > about 32bit vs. 64bit... > > > > Any reasonable implementation would optimize it out for syscalls that do

  1   2   >