Re: [PATCH net] net: ll_temac: Fix potential NULL dereference in temac_probe()

2020-12-08 Thread David Miller
From: Zhang Changzhong 
Date: Tue, 8 Dec 2020 09:53:42 +0800

> platform_get_resource() may fail and in this case a NULL dereference
> will occur.
> 
> Fix it to use devm_platform_ioremap_resource() instead of calling
> platform_get_resource() and devm_ioremap().
> 
> This is detected by Coccinelle semantic patch.
> 
> @@
> expression pdev, res, n, t, e, e1, e2;
> @@
> 
> res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n);
> + if (!res)
> +   return -EINVAL;
> ... when != res == NULL
> e = devm_ioremap(e1, res->start, e2);
> 
> Fixes: 8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree 
> platforms")
> Signed-off-by: Zhang Changzhong 

Applied, thanks.


Re: [PATCH] net: sched: fix spelling mistake in Kconfig "trys" -> "tries"

2020-12-08 Thread David Miller
From: Colin King 
Date: Mon,  7 Dec 2020 16:12:31 +

> From: Colin Ian King 
> 
> There is a spelling mistake in the Kconfig help text. Fix it.
> 
> Signed-off-by: Colin Ian King 

Applied, thanks.


Re: [PATCH] net: tipc: prevent possible null deref of link

2020-12-08 Thread David Miller
From: Cengiz Can 
Date: Mon,  7 Dec 2020 11:14:24 +0300

> `tipc_node_apply_property` does a null check on a `tipc_link_entry`
> pointer but also accesses the same pointer out of the null check block.
> 
> This triggers a warning on Coverity Static Analyzer because we're
> implying that `e->link` can BE null.
> 
> Move "Update MTU for node link entry" line into if block to make sure
> that we're not in a state that `e->link` is null.
> 
> Signed-off-by: Cengiz Can 
> ---

Applied, thanks.,


Re: [PATCH net] net: hns3: remove a misused pragma packed

2020-12-06 Thread David Miller
From: Huazhong Tan 
Date: Mon, 7 Dec 2020 15:20:25 +0800

> hclge_dbg_reg_info[] is defined as an array of packed structure
> accidentally. However, this array contains pointers, which are
> no longer aligned naturally, and cannot be relocated on PPC64.
> Hence, when compile-testing this driver on PPC64 with
> CONFIG_RELOCATABLE=y (e.g. PowerPC allyesconfig), there will be
> some warnings.
> 
> Since each field in structure hclge_qos_pri_map_cmd and
> hclge_dbg_bitmap_cmd is type u8, the pragma packed is unnecessary
> for these two structures as well, so remove the pragma packed in
> hclge_debugfs.h to fix this issue, and this increases
> hclge_dbg_reg_info[] by 4 bytes per entry.
> 
> Fixes: a582b78dfc33 ("net: hns3: code optimization for debugfs related to 
> "dump reg"")
> Reported-by: Stephen Rothwell 
> Signed-off-by: Huazhong Tan 

Applied, thank you.


Re: [PATCH net 0/6] rxrpc: Miscellaneous fixes

2020-10-06 Thread David Miller
From: David Howells 
Date: Mon, 05 Oct 2020 17:18:44 +0100

> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-fixes-20201005.txt

I think the ".txt" at the end of the branch name is a mistake.

It's really hard to send a clean working pull request isn't it? :-)

Pulled, thanks David.


Re: [PATCH v4] net: usb: rtl8150: set random MAC address when set_ethernet_addr() fails

2020-10-06 Thread David Miller
From: Anant Thazhemadam 
Date: Mon,  5 Oct 2020 18:59:58 +0530

> When get_registers() fails in set_ethernet_addr(),the uninitialized
> value of node_id gets copied over as the address.
> So, check the return value of get_registers().
> 
> If get_registers() executed successfully (i.e., it returns
> sizeof(node_id)), copy over the MAC address using ether_addr_copy()
> (instead of using memcpy()).
> 
> Else, if get_registers() failed instead, a randomly generated MAC
> address is set as the MAC address instead.
> 
> Reported-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
> Tested-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
> Acked-by: Petko Manolov 
> Signed-off-by: Anant Thazhemadam 

Applied, thank you.


Re: [PATCH v3] net: qrtr: ns: Fix the incorrect usage of rcu_read_lock()

2020-10-06 Thread David Miller
From: Manivannan Sadhasivam 
Date: Mon,  5 Oct 2020 12:46:42 +0530

> The rcu_read_lock() is not supposed to lock the kernel_sendmsg() API
> since it has the lock_sock() in qrtr_sendmsg() which will sleep. Hence,
> fix it by excluding the locking for kernel_sendmsg().
> 
> While at it, let's also use radix_tree_deref_retry() to confirm the
> validity of the pointer returned by radix_tree_deref_slot() and use
> radix_tree_iter_resume() to resume iterating the tree properly before
> releasing the lock as suggested by Doug.
> 
> Fixes: a7809ff90ce6 ("net: qrtr: ns: Protect radix_tree_deref_slot() using 
> rcu read locks")
> Reported-by: Douglas Anderson 
> Reviewed-by: Douglas Anderson 
> Tested-by: Douglas Anderson 
> Tested-by: Alex Elder 
> Signed-off-by: Manivannan Sadhasivam 

Applied, thank you.


Re: linux tooling mailing list

2020-10-05 Thread David Miller
From: Nick Desaulniers 
Date: Mon, 5 Oct 2020 10:50:35 -0700

> Now that the lore archive has been set up
> (https://lore.kernel.org/linux-toolchains/), would you mind linking to
> it from http://vger.kernel.org/vger-lists.html under archives of
> linux-toolchains?

Done.


Re: [PATCH] net: phy: marvell: Use phy_read_paged() instead of open coding it

2020-10-05 Thread David Miller
From: Jisheng Zhang 
Date: Mon, 5 Oct 2020 17:19:50 +0800

> Convert m88e1318_get_wol() to use the well implemented phy_read_paged()
> instead of open coding it.
> 
> Signed-off-by: Jisheng Zhang 

Applied, thanks!


[GIT] Networking

2020-10-04 Thread David Miller


1) Make sure SKB control block is in the proper state during IPSEC
   ESP-in-TCP encapsulation.  From Sabrina Dubroca.

2) Various kinds of attributes were not being cloned properly when
   we build new xfrm_state objects from existing ones.  Fix from
   Antony Antony.

3) Make sure to keep BTF sections, from Tony Ambardar.

4) TX DMA channels need proper locking in lantiq driver, from Hauke
   Mehrtens.

5) Honour route MTU during forwarding, always.  From Maciej
   Żenczykowski.

6) Fix races in kTLS which can result in crashes, from Rohit
   Maheshwari.

7) Skip TCP DSACKs with rediculous sequence ranges, from Priyaranjan
   Jha.

8) Use correct address family in xfrm state lookups, from Herbert Xu.

9) A bridge FDB flush should not clear out user managed fdb entries
   with the ext_learn flag set, from Nikolay Aleksandrov.

10) Fix nested locking of netdev address lists, from Taehee Yoo.

11) Fix handling of 32-bit DATA_FIN values in mptcp, from Mat Martineau.

12) Fix r8169 data corruptions on RTL8402 chips, from Heiner Kallweit.

13) Don't free command entries in mlx5 while comp handler could still
be running, from Eran Ben Elisha.

14) Error flow of request_irq() in mlx5 is busted, due to an off by one
we try to free and IRQ never allocated.  From Maor Gottlieb.

15) Fix leak when dumping netlink policies, from Johannes Berg.

16) Sendpage cannot be performed when a page is a slab page, or the
page count is < 1.  Some subsystems such as nvme were doing so.
Create a "sendpage_ok()" helper and use it as needed, from
Coly Li.

17) Don't leak request socket when using syncookes with mptcp, from
Paolo Abeni.

Please pull, thanks a lot!!

The following changes since commit 805c6d3c19210c90c109107d189744e960eae025:

  Merge branch 'fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2020-09-22 15:08:41 
-0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git 

for you to fetch changes up to 4296adc3e32f5d544a95061160fe7e127be1b9ff:

  net/core: check length before updating Ethertype in skb_mpls_{push,pop} 
(2020-10-04 15:09:26 -0700)


Anant Thazhemadam (1):
  net: team: fix memory leak in __team_options_register

Andrii Nakryiko (1):
  libbpf: Fix XDP program load regression for old kernels

Anirudh Venkataramanan (1):
  ice: Fix call trace on suspend

Antony Antony (4):
  xfrm: clone XFRMA_SET_MARK in xfrm_do_migrate
  xfrm: clone XFRMA_REPLAY_ESN_VAL in xfrm_do_migrate
  xfrm: clone XFRMA_SEC_CTX in xfrm_do_migrate
  xfrm: clone whole liftime_cur structure in xfrm_do_migrate

Aya Levin (6):
  net/mlx5e: Fix error path for RQ alloc
  net/mlx5e: Add resiliency in Striding RQ mode for packets larger than MTU
  net/mlx5e: Fix driver's declaration to support GRE offload
  net/mlx5e: Fix return status when setting unsupported FEC mode
  net/mlx5e: Fix VLAN cleanup flow
  net/mlx5e: Fix VLAN create flow

Christophe JAILLET (1):
  net: typhoon: Fix a typo Typoon --> Typhoon

Coly Li (7):
  net: introduce helper sendpage_ok() in include/linux/net.h
  net: add WARN_ONCE in kernel_sendpage() for improper zero-copy send
  nvme-tcp: check page by sendpage_ok() before calling kernel_sendpage()
  tcp: use sendpage_ok() to detect misused .sendpage
  drbd: code cleanup by using sendpage_ok() to check page for 
kernel_sendpage()
  scsi: libiscsi: use sendpage_ok() in iscsi_tcp_segment_map()
  libceph: use sendpage_ok() in ceph_tcp_sendpage()

Cong Wang (4):
  net_sched: defer tcf_idr_insert() in tcf_action_init_1()
  net_sched: commit action insertions together
  net_sched: remove a redundant goto chain check
  net_sched: check error pointer in tcf_dump_walker()

David S. Miller (14):
  Merge branch 'net_sched-fix-a-UAF-in-tcf_action_init'
  Merge tag 'wireless-drivers-2020-09-25' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch '100GbE' of git://git.kernel.org/.../jkirsher/net-queue
  Merge branch 'bonding-team-basic-dev-needed_headroom-support'
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge branch 'net-core-fix-a-lockdep-splat-in-the-dev_addr_list'
  Merge branch 'More-incorrect-VCAP-offsets-for-mscc_ocelot-switch'
  Merge branch 'via-rhine-Resume-fix-and-other-maintenance-work'
  Merge branch 'mptcp-Fix-for-32-bit-DATA_FIN'
  Merge git://git.kernel.org/.../bpf/bpf
  Merge branch '100GbE' of https://github.com/anguy11/net-queue
  Merge branch 'Fix-bugs-in-Octeontx2-netdev-driver'
  Merge branch 
'Introduce-sendpage_ok-to-detect-misused-sendpage-in-network-related-drivers'
  Merge tag 'mlx5-fixes-2020-09-30' of git://git.kernel.org/.../saeed/linux

Eran Ben Elisha (4):
  net/mlx5: Fix a race when moving command interface to polling mode
  net/mlx5: Avoid 

Re: [PATCH net-next v2 0/2] net: Constify struct genl_small_ops

2020-10-04 Thread David Miller
From: Rikard Falkeborn 
Date: Mon,  5 Oct 2020 01:44:15 +0200

> Make a couple of static struct genl_small_ops const to allow the compiler
> to put them in read-only memory. Patches are independent.
> 
> v2: Rebase on net-next, genl_ops -> genl_small_ops

Applied, thank you.


Re: [PATCH net] drivers/net/wan: lapb: Replace the skb->len checks with pskb_may_pull

2020-10-04 Thread David Miller
From: Xie He 
Date: Sat,  3 Oct 2020 17:46:19 -0700

> The purpose of these skb->len checks in these drivers is to ensure that
> there is a header in the skb available to be read and pulled.
> 
> However, we already have the pskb_may_pull function for this purpose.
> 
> The pskb_may_pull function also correctly handles non-linear skbs.
> 
> (Also delete the word "check" in the comments because pskb_may_pull may
> do things other than simple checks in the case of non-linear skbs.)
> 
> Cc: Willem de Bruijn 
> Cc: Martin Schiller 
> Signed-off-by: Xie He 

This is excessive.

On transmit the header will be in the linear area, especially
if it is only one byte in size.

You're adding a lot of extra checks, function calls, etc. which are
frankly unnecessary.

I'm not applying this unless you can prove that a non-linear single
header byte is possible in these code paths.  And you'll need to add
such proof to your commit message.

Thank you.


Re: [PATCH net-next] drivers/net/wan/hdlc_fr: Improvements to the code of pvc_xmit

2020-10-04 Thread David Miller
From: Xie He 
Date: Sat,  3 Oct 2020 15:41:05 -0700

> 1. Keep the code for the normal (non-error) flow at the lowest
> indentation level. And use "goto drop" for all error handling.
> 
> 2. Replace code that pads short Ethernet frames with a "__skb_pad" call.
> 
> 3. Change "dev_kfree_skb" to "kfree_skb" in error handling code.
> "kfree_skb" is the correct function to call when dropping an skb due to
> an error. "dev_kfree_skb", which is an alias of "consume_skb", is for
> dropping skbs normally (not due to an error).
> 
> Cc: Krzysztof Halasa 
> Cc: Stephen Hemminger 
> Signed-off-by: Xie He 

Applied, thank you.


Re: [PATCH] net: mvneta: fix double free of txq->buf

2020-10-04 Thread David Miller
From: t...@redhat.com
Date: Sat,  3 Oct 2020 11:51:21 -0700

> From: Tom Rix 
> 
> clang static analysis reports this problem:
> 
> drivers/net/ethernet/marvell/mvneta.c:3465:2: warning:
>   Attempt to free released memory
> kfree(txq->buf);
> ^~~
> 
> When mvneta_txq_sw_init() fails to alloc txq->tso_hdrs,
> it frees without poisoning txq->buf.  The error is caught
> in the mvneta_setup_txqs() caller which handles the error
> by cleaning up all of the txqs with a call to
> mvneta_txq_sw_deinit which also frees txq->buf.
> 
> Since mvneta_txq_sw_deinit is a general cleaner, all of the
> partial cleaning in mvneta_txq_sw_deinit()'s error handling
> is not needed.
> 
> Fixes: 2adb719d74f6 ("net: mvneta: Implement software TSO")
> Signed-off-by: Tom Rix 

Applied and queued up for -stable, thank you.


Re: [PATCH net-next 0/2] net: Constify struct genl_ops

2020-10-04 Thread David Miller
From: Rikard Falkeborn 
Date: Sun,  4 Oct 2020 23:58:08 +0200

> Make a couple of static struct genl_ops const to allow the compiler to put
> them in read-only memory. Patches are independent.

These do not apply cleanly to net-next, please respin.


Re: [PATCH] net: team: fix memory leak in __team_options_register

2020-10-04 Thread David Miller
From: Anant Thazhemadam 
Date: Mon,  5 Oct 2020 02:25:36 +0530

> The variable "i" isn't initialized back correctly after the first loop
> under the label inst_rollback gets executed.
> 
> The value of "i" is assigned to be option_count - 1, and the ensuing 
> loop (under alloc_rollback) begins by initializing i--. 
> Thus, the value of i when the loop begins execution will now become 
> i = option_count - 2.
> 
> Thus, when kfree(dst_opts[i]) is called in the second loop in this 
> order, (i.e., inst_rollback followed by alloc_rollback), 
> dst_optsp[option_count - 2] is the first element freed, and 
> dst_opts[option_count - 1] does not get freed, and thus, a memory 
> leak is caused.
> 
> This memory leak can be fixed, by assigning i = option_count (instead of
> option_count - 1).
> 
> Fixes: 80f7c6683fe0 ("team: add support for per-port options")
> Reported-by: syzbot+69b804437cfec30de...@syzkaller.appspotmail.com
> Tested-by: syzbot+69b804437cfec30de...@syzkaller.appspotmail.com
> Signed-off-by: Anant Thazhemadam 

Applied and queued up for -stable, thank you.


Re: [PATCH net-next] mptcp: ADD_ADDRs with echo bit are smaller

2020-10-03 Thread David Miller
From: Matthieu Baerts 
Date: Sat,  3 Oct 2020 17:36:56 +0200

> The MPTCP ADD_ADDR suboption with echo-flag=1 has no HMAC, the size is
> smaller than the one initially sent without echo-flag=1. We then need to
> use the correct size everywhere when we need this echo bit.
> 
> Before this patch, the wrong size was reserved but the correct amount of
> bytes were written (and read): the remaining bytes contained garbage.
> 
> Fixes: 6a6c05a8b016 ("mptcp: send out ADD_ADDR with echo flag")
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/95
> Reported-and-tested-by: Davide Caratti 
> Acked-by: Geliang Tang 
> Signed-off-by: Matthieu Baerts 

Applied.


Re: [PATCH][next] bnx2x: Use fallthrough pseudo-keyword

2020-10-03 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Fri, 2 Oct 2020 18:26:11 -0500

> Replace /* no break */ comments with the new pseudo-keyword macro
> fallthrough[1].
> 
> [1] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH][next] usbnet: Use fallthrough pseudo-keyword

2020-10-03 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Fri, 2 Oct 2020 17:53:15 -0500

> Replace // FALLTHROUGH comment with the new pseudo-keyword macro
> fallthrough[1].
> 
> [1] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH][next] net: bna: Use fallthrough pseudo-keyword

2020-10-03 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Fri, 2 Oct 2020 18:00:01 -0500

> Replace /* !!! fall through !!! */ comments with the new pseudo-keyword
> macro fallthrough[1].
> 
> [1] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH][next] net: ksz884x: Use fallthrough pseudo-keyword

2020-10-03 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Fri, 2 Oct 2020 18:02:59 -0500

> Replace /* Fallthrough... */ comment with the new pseudo-keyword macro
> fallthrough[1].
> 
> [1] 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH] net: typhoon: Fix a typo Typoon --> Typhoon

2020-10-03 Thread David Miller
From: Christophe JAILLET 
Date: Fri,  2 Oct 2020 21:47:43 +0200

> s/Typoon/Typhoon/
> 
> Signed-off-by: Christophe JAILLET 

Applied, thank you.


Re: [PATCH][next] net: phy: dp83869: fix unsigned comparisons against less than zero values

2020-10-03 Thread David Miller
From: Colin King 
Date: Fri,  2 Oct 2020 17:54:22 +0100

> From: Colin Ian King 
> 
> Currently the comparisons of u16 integers value and sopass_val with
> less than zero for error checking is always false because the values
> are unsigned. Fix this by making these variables int.  This does not
> affect the shift and mask operations performed on these variables
> 
> Addresses-Coverity: ("Unsigned compared against zero")
> Fixes: 49fc23018ec6 ("net: phy: dp83869: support Wake on LAN")
> Signed-off-by: Colin Ian King 

Applied, thank you.


Re: [PATCH v4 net-next 0/2] Add Seville Ethernet switch to T1040RDB

2020-10-03 Thread David Miller
From: Vladimir Oltean 
Date: Fri,  2 Oct 2020 16:41:04 +0300

> Seville is a DSA switch that is embedded inside the T1040 SoC, and
> supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
> 
> This series adds this switch to the SoC's dtsi files and to the T1040RDB
> board file.
> 
> I would like to send this series through net-next. There is no conflict
> with other patches submitted to T1040 device tree. Maybe this could at
> least get an ACK from devicetree maintainers.

Series applied, thank you.


Re: [PATCH v2] net: hso: do not call unregister if not registered

2020-10-03 Thread David Miller
From: Greg KH 
Date: Fri, 2 Oct 2020 13:43:23 +0200

> @@ -2366,7 +2366,8 @@ static void hso_free_net_device(struct hso_device 
> *hso_dev, bool bailout)
>  
>   remove_net_device(hso_net->parent);
>  
> - if (hso_net->net)
> + if (hso_net->net &&
> + hso_net->net->reg_state == NETREG_REGISTERED)
>   unregister_netdev(hso_net->net);
>  
>   /* start freeing */

I really want to get out of the habit of drivers testing the internal
netdev registration state to make decisions.

Instead, please track this internally.  You know if you registered the
device or not, therefore use that to control whether you try to
unregister it or not.

Thank you.


Re: [PATCH v2 net] net: stmmac: Modify configuration method of EEE timers

2020-10-03 Thread David Miller
From: Voon Weifeng 
Date: Thu,  1 Oct 2020 23:56:09 +0800

> From: "Vineetha G. Jaya Kumaran" 
> 
> Ethtool manual stated that the tx-timer is the "the amount of time the
> device should stay in idle mode prior to asserting its Tx LPI". The
> previous implementation for "ethtool --set-eee tx-timer" sets the LPI TW
> timer duration which is not correct. Hence, this patch fixes the
> "ethtool --set-eee tx-timer" to configure the EEE LPI timer.
> 
> The LPI TW Timer will be using the defined default value instead of
> "ethtool --set-eee tx-timer" which follows the EEE LS timer implementation.
> 
> Fixes: d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")
> Signed-off-by: Vineetha G. Jaya Kumaran 
> Signed-off-by: Voon Weifeng 
> 
> Changelog V2
> *Not removing/modifying the eee_timer.
> *EEE LPI timer can be configured through ethtool and also the eee_timer
> module param.
> *EEE TW Timer will be configured with default value only, not able to be
> configured through ethtool or module param. This follows the implementation
> of the EEE LS Timer.

Please put the Changelog above the various signoffs and other tags, as those
should be at the end of the commit log message.

Just out of curiousity, where did you see put the changelog after the
tags, and thus caused you to use this layout?  If you decided that on
your own, this is pretty much always a bad idea.  Look to other
patches which have been accepted as a guide for how to format your commit
log message.

Applied, thank you.


Re: [PATCH net-next 00/23] rxrpc: Fixes and preparation for RxGK

2020-10-03 Thread David Miller
From: David Howells 
Date: Sat, 03 Oct 2020 22:24:55 +0100

> David Miller  wrote:
> 
>> > Since the fixes in the set need to go after the patches in net-next, 
>> > should I
>> > resubmit just those for net-next, or sit on them till -rc1?
>> 
>> My 'net' tree is always open for bug fixes, and that's where bug fixes
>> belong.  Not 'net-next'.
> 
> "Need to go after the patches in net-next" - ie. there's a dependency.

If the bugs exist before your net-next changes, that doesn't make any
sense.  The fixes have to be against whatever is in 'net'.

If the fixes are introduced by your net-next changes, you should
integrate them into your net-next changes.


Re: [PATCH net-next 00/23] rxrpc: Fixes and preparation for RxGK

2020-10-03 Thread David Miller
From: David Howells 
Date: Sat, 03 Oct 2020 21:01:49 +0100

> Since the fixes in the set need to go after the patches in net-next, should I
> resubmit just those for net-next, or sit on them till -rc1?

My 'net' tree is always open for bug fixes, and that's where bug fixes
belong.  Not 'net-next'.


Re: [PATCH net-next 7/8] net: ethernet: ti: am65-cpsw: prepare xmit/rx path for multi-port devices in mac-only mode

2020-10-02 Thread David Miller
From: Grygorii Strashko 
Date: Thu, 1 Oct 2020 13:52:57 +0300

> This patch adds multi-port support to TI AM65x CPSW driver xmit/rx path in
> preparation for adding support for multi-port devices, like Main CPSW0 on
> K3 J721E SoC or future CPSW3g on K3 AM64x SoC.
> Hence DMA channels are common/shared for all ext Ports and the RX/TX NAPI
> and DMA processing going to be assigned to first netdev this patch:
>  - ensures all RX descriptors fields are initialized;
>  - adds synchronization for TX DMA push/pop operation (locking) as
> Networking core is not enough any more;
>  - updates TX bql processing for every packet in
> am65_cpsw_nuss_tx_compl_packets() as every completed TX skb can have
> different ndev assigned (come from different netdevs).
> 
> Signed-off-by: Grygorii Strashko 

This locking is unnecessary in single-port non-shared DMA situations
and therefore will impose unnecessary performance loss for basically
all existing supported setups.

Please do this another way.

In fact, I would encourage you to find a way to avoid the new atomic
operations even in multi-port configurations.

Thank you.


Re: [Linux-kernel-mentees][PATCH 0/2] reorder members of structures in virtio_net for optimization

2020-10-02 Thread David Miller
From: Anant Thazhemadam 
Date: Wed, 30 Sep 2020 10:47:20 +0530

> The structures virtnet_info and receive_queue have byte holes in 
> middle, and their members could do with some rearranging 
> (order-of-declaration wise) in order to overcome this.
> 
> Rearranging the members helps in:
>   * elimination the byte holes in the middle of the structures
>   * reduce the size of the structure (virtnet_info)
>   * have more members stored in one cache line (as opposed to 
> unnecessarily crossing the cacheline boundary and spanning
> different cachelines)
> 
> The analysis was performed using pahole.
> 
> These patches may be applied in any order.

What effects do these changes have on performance?

The cache locality for various TX and RX paths could be effected.

I'm not applying these patches without some data on the performance
impact.

Thank you.



Re: [PATCH net-next 00/23] rxrpc: Fixes and preparation for RxGK

2020-10-02 Thread David Miller
From: David Howells 
Date: Thu, 01 Oct 2020 15:56:43 +0100

> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-next-20201010

No, they aren't.


git pull --no-ff 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
rxrpc-next-20201010
fatal: couldn't find remote ref rxrpc-next-20201010


Also, you have to submit changes much much much earlier.  Don't let your
patch sets get into the 20+ patch range, it's much to large and a huge
burdon for patch reviewers.

Make this patch series smaller, fix the GIT stuff, and resubmit.

Thank you.


Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

2020-10-02 Thread David Miller
From: Jarod Wilson 
Date: Fri, 2 Oct 2020 16:23:46 -0400

> I'd had a bit of feedback that people would rather see both, and be
> able to toggle off the old ones, rather than only having one or the
> other, depending on the toggle, so I thought I'd give this a try. I
> kind of liked the one or the other route, but I see the problems with
> that too.

Please keep everything for the entire deprecation period, unconditionally.

Thank you.


Re: [PATCH net-next v2 5/6] bonding: update Documentation for port/bond terminology

2020-10-02 Thread David Miller
From: Jarod Wilson 
Date: Fri, 2 Oct 2020 16:12:49 -0400

> The documentation was updated to point to the new names, but the old
> ones still exist across the board, there should be no userspace
> breakage here. (My lnst bonding tests actually fall flat currently
> if the old names are gone).

The documentation is the reference point for people reading code in
userspace that manipulates bonding devices.

So people will come across the deprecated names in userland code and
therefore will try to learn what they do and what they mean.

Which means that the documentation must reference the old names.

You can mark them "(DEPRECATED)" or similar, but you must not remove
them.


Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

2020-10-02 Thread David Miller
From: Stephen Hemminger 
Date: Fri, 2 Oct 2020 12:13:17 -0700

> On Fri,  2 Oct 2020 13:40:01 -0400
> Jarod Wilson  wrote:
> 
>> By default, enable retaining all user-facing API that includes the use of
>> master and slave, but add a Kconfig knob that allows those that wish to
>> remove it entirely do so in one shot.
> 
> This is problematic. You are printing both old and new values.
> Also every distribution will have to enable it.
> 
> This looks like too much of change to users.

Agreed, no Kconfig knob.

Keep everything during the deprecation period, then you can kill off
the old names at the end of the deprecation period.

I don't want to create a situation where distribution X lists as a
"feature" that they are able to enable this Kconfig value even though
it breaks UAPI for legacy external code out there.

That's the wrong way to go about this and creates the wrong incentive
system.

I also agree that you can't change the docs to stop mentioning the old
names.  It's almost like we are pretending we aren't doing the
transition and that only the new names matter.  The old names matter
and must therefore be acknowledged, exist, and be referencable in the
documentation until the end of the deprecation period.  You can mark
them "(DEPRECATED)" or similar, but they can't be removed just yet.

Thank you.


Re: [PATCH 1/2] sparc32: Move ioremap/iounmap declaration before asm-generic/io.h include

2020-10-02 Thread David Miller
From: Lorenzo Pieralisi 
Date: Fri, 2 Oct 2020 15:50:29 +0100

> On Tue, Sep 15, 2020 at 01:11:21PM -0700, David Miller wrote:
>> From: Lorenzo Pieralisi 
>> Date: Tue, 15 Sep 2020 10:32:02 +0100
>> 
>> > Move the ioremap/iounmap declaration before asm-generic/io.h is
>> > included so that it is visible within it.
>> > 
>> > Signed-off-by: Lorenzo Pieralisi 
>> 
>> Acked-by: David S. Miller 
> 
> Hi David,
> 
> can I apply your Acked-by to v2 (where I had to split this patch in 2):
> 
> https://lore.kernel.org/lkml/cover.1600254147.git.lorenzo.pieral...@arm.com
> I am about to merge it - please let me know.

Yes, you can.


Re: [PATCH v2] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

2020-10-02 Thread David Miller
From: Anant Thazhemadam 
Date: Fri, 2 Oct 2020 17:04:13 +0530

> But this patch is about ensuring that an uninitialized variable's
> value (whatever that may be) is not set as the ethernet address
> blindly (without any form of checking if get_registers() worked
> as expected, or not).

Right, and if you are going to check for errors then you have to
handle the error properly.

And the proper way to handle this error is to set a random ethernet
address on the device.


Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-02 Thread David Miller
From: Coly Li 
Date: Fri, 2 Oct 2020 16:30:12 +0800

> Obviously my fault and no excuse for leaking this uncompleted version to
> you. I just re-post a v10 version which I make sure all patches are the
> latest version.
> 
> Sorry for the inconvenience and thank you in advance for taking this set.

How did this happen?

How did you functionally test the patch set if it didn't even compile?

I want you to explain why you sent a completely untested patch set.


Re: [PATCH v10 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-02 Thread David Miller
From: Coly Li 
Date: Fri,  2 Oct 2020 16:27:27 +0800

> As Sagi Grimberg suggested, the original fix is refind to a more common
> inline routine:
> static inline bool sendpage_ok(struct page *page)
> {
> return  (!PageSlab(page) && page_count(page) >= 1);
> }
> If sendpage_ok() returns true, the checking page can be handled by the
> concrete zero-copy sendpage method in network layer.

Series applied.

> The v10 series has 7 patches, fixes a WARN_ONCE() usage from v9 series,
 ...

I still haven't heard from you how such a fundamental build failure
was even possible.

If the v9 patch series did not even compile, how in the world did you
perform functional testing of these changes?

Please explain this to me, instead of just quietly fixing it and
posting an updated series.

Thank you.


Re: Why ping latency is smaller with shorter send interval?

2020-10-02 Thread David Miller


Can you please not send the same posting to the mailing list
three times, from three different email addresses?

Once is enough, thank you.


Re: [PATCH 1/6] net: core: document two new elements of struct net_device

2020-10-02 Thread David Miller
From: Mauro Carvalho Chehab 
Date: Fri,  2 Oct 2020 07:49:45 +0200

> As warned by "make htmldocs", there are two new struct elements
> that aren't documented:
> 
>   ../include/linux/netdevice.h:2159: warning: Function parameter or 
> member 'unlink_list' not described in 'net_device'
>   ../include/linux/netdevice.h:2159: warning: Function parameter or 
> member 'nested_level' not described in 'net_device'
> 
> Fixes: 1fc70edb7d7b ("net: core: add nested_level variable in net_device")
> Signed-off-by: Mauro Carvalho Chehab 

Applied, thank you.


Re: [PATCH net-next 0/4] net: dsa: Improve dsa_untag_bridge_pvid()

2020-10-02 Thread David Miller
From: Florian Fainelli 
Date: Thu,  1 Oct 2020 19:42:11 -0700

> Hi David, Jakub,
> 
> This patch series is based on the recent discussions with Vladimir:
> 
> https://lore.kernel.org/netdev/20201001030623.343535-1-f.faine...@gmail.com/
> 
> the simplest way forward was to call dsa_untag_bridge_pvid() after
> eth_type_trans() has been set which guarantees that skb->protocol is set
> to a correct value and this allows us to utilize
> __vlan_find_dev_deep_rcu() properly without playing or using the bridge
> master as a net_device reference.

Series applied, thanks.


Re: [Linux-kernel-mentees][PATCH v2] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

2020-10-01 Thread David Miller
From: Anant Thazhemadam 
Date: Thu,  1 Oct 2020 13:02:20 +0530

> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
> 
> Checking for the return values appropriately, and handling the case
> wherein set_ethernet_addr() fails like this, helps in avoiding the
> mac address being incorrectly set in this manner.
> 
> Reported-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
> Tested-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
> Signed-off-by: Anant Thazhemadam 
> Acked-by: Petko Manolov 

First, please remove "Linux-kernel-mentees" from the Subject line.

All patch submitters should have their work judged equally, whoever
they are.  So this Subject text gives no extra information, and it
simply makes scanning Subject lines in one's mailer more difficult.

Second, when a MAC address fails to probe a random MAC address should
be selected.  We have helpers for this.  This way an interface still
comes up and is usable, even in the event of a failed MAC address
probe.


Re: [PATCH net v1] net: phy: realtek: Modify 2.5G PHY name to RTL8226

2020-10-01 Thread David Miller
From: Willy Liu 
Date: Wed, 30 Sep 2020 14:48:58 +0800

> Realtek single-chip Ethernet PHY solutions can be separated as below:
> 10M/100Mbps: RTL8201X
> 1Gbps: RTL8211X
> 2.5Gbps: RTL8226/RTL8221X
> RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY.
> Since RTL8226 is single port only, realtek changes its name to RTL8221B from
> the second version.
> PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840.
> 
> RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus
> controller and embedded memory.
> 
> Signed-off-by: Willy Liu 

Applied to net-next as this is just renaming rather than a functional
change.


Re: [PATCH] caif_virtio: Remove redundant initialization of variable err

2020-10-01 Thread David Miller
From: Jing Xiangfeng 
Date: Wed, 30 Sep 2020 09:29:54 +0800

> After commit a8c7687bf216 ("caif_virtio: Check that vringh_config is not
> null"), the variable err is being initialized with '-EINVAL' that is
> meaningless. So remove it.
> 
> Signed-off-by: Jing Xiangfeng 

Applied to net-next.


Re: linux-next: build failure after merge of the net-next tree

2020-10-01 Thread David Miller
From: Stephen Rothwell 
Date: Tue, 29 Sep 2020 13:04:46 +1000

> Caused by commit
> 
>   eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested 
> interface infrastructure")
> 
> interacting with commit
> 
>   e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation")
> 
> also in the net-next tree.

I would argue against that "also" as the first commit is only in the
'net' tree right now. :-)

This is simply something I'll have to resolve the next time net is merged
into net-next.

Thanks.


Re: [PATCH net-next] drivers/net/wan/hdlc_fr: Correctly handle special skb->protocol values

2020-10-01 Thread David Miller
From: Xie He 
Date: Mon, 28 Sep 2020 05:56:43 -0700

> The fr_hard_header function is used to prepend the header to skbs before
> transmission. It is used in 3 situations:
> 1) When a control packet is generated internally in this driver;
> 2) When a user sends an skb on an Ethernet-emulating PVC device;
> 3) When a user sends an skb on a normal PVC device.
> 
> These 3 situations need to be handled differently by fr_hard_header.
> Different headers should be prepended to the skb in different situations.
> 
> Currently fr_hard_header distinguishes these 3 situations using
> skb->protocol. For situation 1 and 2, a special skb->protocol value
> will be assigned before calling fr_hard_header, so that it can recognize
> these 2 situations. All skb->protocol values other than these special ones
> are treated by fr_hard_header as situation 3.
> 
> However, it is possible that in situation 3, the user sends an skb with
> one of the special skb->protocol values. In this case, fr_hard_header
> would incorrectly treat it as situation 1 or 2.
> 
> This patch tries to solve this issue by using skb->dev instead of
> skb->protocol to distinguish between these 3 situations. For situation
> 1, skb->dev would be NULL; for situation 2, skb->dev->type would be
> ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI.
> 
> This way fr_hard_header would be able to distinguish these 3 situations
> correctly regardless what skb->protocol value the user tries to use in
> situation 3.
> 
> Cc: Krzysztof Halasa 
> Signed-off-by: Xie He 

Applied, thank you.


Re: [PATCH v3 devicetree 0/2] Add Seville Ethernet switch to T1040RDB

2020-10-01 Thread David Miller
From: Vladimir Oltean 
Date: Thu,  1 Oct 2020 16:20:11 +0300

> Seville is a DSA switch that is embedded inside the T1040 SoC, and
> supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
> 
> This series adds this switch to the SoC's dtsi files and to the T1040RDB
> board file.

I am assuming the devicetree folks will pick this series up.

Thanks.



Re: [PATCH net-next v4 resend 0/5] net/ravb: Add support for explicit internal clock delay configuration

2020-10-01 Thread David Miller
From: Geert Uytterhoeven 
Date: Thu,  1 Oct 2020 12:10:03 +0200

> Some Renesas EtherAVB variants support internal clock delay
> configuration, which can add larger delays than the delays that are
> typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or
> "[rt]xc-skew-ps" properties).
> 
> Historically, the EtherAVB driver configured these delays based on the
> "rgmii-*id" PHY mode.  This caused issues with PHY drivers that
> implement PHY internal delays properly[1].  Hence a backwards-compatible
> workaround was added by masking the PHY mode[2].
> 
> This patch series implements the next step of the plan outlined in [3],
> and adds proper support for explicit configuration of the MAC internal
> clock delays using new "[rt]x-internal-delay-ps" properties.  If none of
> these properties is present, the driver falls back to the old handling.
 ...

Series applied, thank you.


Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-01 Thread David Miller
From: David Miller 
Date: Thu, 01 Oct 2020 12:43:45 -0700 (PDT)

> Series applied and queued up for -stable, thank you.

Actually, this doesn't even build:

In file included from ./arch/x86/include/asm/bug.h:93,
 from ./include/linux/bug.h:5,
 from ./include/linux/mmdebug.h:5,
 from ./include/linux/mm.h:9,
 from net/socket.c:55:
net/socket.c: In function ‘kernel_sendpage’:
./include/asm-generic/bug.h:97:3: error: too few arguments to function 
‘__warn_printk’
   97 |   __warn_printk(arg); \
  |   ^

Was this even build tested?



Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

2020-10-01 Thread David Miller
From: Coly Li 
Date: Thu,  1 Oct 2020 15:54:01 +0800

> This series was original by a bug fix in nvme-over-tcp driver which only
> checked whether a page was allocated from slab allcoator, but forgot to
> check its page_count: The page handled by sendpage should be neither a
> Slab page nor 0 page_count page.
> 
> As Sagi Grimberg suggested, the original fix is refind to a more common
> inline routine:
> static inline bool sendpage_ok(struct page *page)
> {
> return  (!PageSlab(page) && page_count(page) >= 1);
> }
> If sendpage_ok() returns true, the checking page can be handled by the
> concrete zero-copy sendpage method in network layer.
> 
> The v9 series has 7 patches, no change from v8 series,
> - The 1st patch in this series introduces sendpage_ok() in header file
>   include/linux/net.h.
> - The 2nd patch adds WARN_ONCE() for improper zero-copy send in
>   kernel_sendpage().
> - The 3rd patch fixes the page checking issue in nvme-over-tcp driver.
> - The 4th patch adds page_count check by using sendpage_ok() in
>   do_tcp_sendpages() as Eric Dumazet suggested.
> - The 5th and 6th patches just replace existing open coded checks with
 ...

Series applied and queued up for -stable, thank you.


Re: linux tooling mailing list

2020-09-30 Thread David Miller
From: Nick Desaulniers 
Date: Wed, 30 Sep 2020 12:29:38 -0700

> linux-toolcha...@vger.kernel.org

Created.



Re: [net PATCH v2 0/4] Fix bugs in Octeontx2 netdev driver

2020-09-30 Thread David Miller
From: Geetha sowjanya 
Date: Wed, 30 Sep 2020 21:38:10 +0530

> In existing Octeontx2 network drivers code has issues
> like stale entries in broadcast replication list, missing
> L3TYPE for IPv6 frames, running tx queues on error and 
> race condition in mbox reset.
> This patch set fixes the above issues.

What changed since v1?  Always specify that when you post a new
version of a patch series.

Anyways, series applied.


Re: [net-next PATCH v1 7/7] net/fsl: Use _ADR ACPI object to register PHYs

2020-09-30 Thread David Miller
From: Calvin Johnson 
Date: Wed, 30 Sep 2020 21:34:30 +0530

> @@ -248,6 +250,10 @@ static int xgmac_mdio_probe(struct platform_device *pdev)
>   struct resource *res;
>   struct mdio_fsl_priv *priv;
>   int ret;
> + struct fwnode_handle *fwnode;
> + struct fwnode_handle *child;
> + unsigned long long addr;
> + acpi_status status;
>  

Reverse chrstimas tree here too, please.


Re: [net-next PATCH v1 4/7] net: mdiobus: Introduce fwnode_mdiobus_register_phy()

2020-09-30 Thread David Miller
From: Calvin Johnson 
Date: Wed, 30 Sep 2020 21:34:27 +0530

> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -106,6 +106,46 @@ int mdiobus_unregister_device(struct mdio_device 
> *mdiodev)
>  }
>  EXPORT_SYMBOL(mdiobus_unregister_device);
>  
> +int fwnode_mdiobus_register_phy(struct mii_bus *bus,
> + struct fwnode_handle *child, u32 addr)
> +{
> + struct phy_device *phy;
> + bool is_c45;
> + const char *cp;
> + u32 phy_id;
> + int rc;

Reverse christmas tree here please.


Re: [net-next PATCH v1 2/7] net: phy: Introduce phy related fwnode functions

2020-09-30 Thread David Miller
From: Calvin Johnson 
Date: Wed, 30 Sep 2020 21:34:25 +0530

> +struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode)
> +{
> + struct device *d;
> + struct mdio_device *mdiodev;

Please use reverse christmas tree ordering for local variables.


Re: [PATCH v4 25/52] docs: net: ieee802154.rst: fix C expressions

2020-09-30 Thread David Miller
From: Mauro Carvalho Chehab 
Date: Wed, 30 Sep 2020 15:24:48 +0200

> There are some warnings produced with Sphinx 3.x:
> 
>   Documentation/networking/ieee802154.rst:29: WARNING: Error in 
> declarator or parameters
>   Invalid C declaration: Expecting "(" in parameters. [error at 7]
> int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
> ---^
>   Documentation/networking/ieee802154.rst:134: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 81]
> void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff 
> *skb, u8 lqi):
> 
> -^
>   Documentation/networking/ieee802154.rst:139: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 95]
> void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct 
> sk_buff *skb, bool ifs_handling):
> 
> ---^
>   Documentation/networking/ieee802154.rst:158: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 35]
> int start(struct ieee802154_hw *hw):
> ---^
>   Documentation/networking/ieee802154.rst:162: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 35]
> void stop(struct ieee802154_hw *hw):
> ---^
>   Documentation/networking/ieee802154.rst:166: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 61]
> int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
> -^
>   Documentation/networking/ieee802154.rst:171: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 43]
> int ed(struct ieee802154_hw *hw, u8 *level):
> ---^
>   Documentation/networking/ieee802154.rst:176: WARNING: Invalid C 
> declaration: Expected end of definition. [error at 62]
> int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
> --^
> 
> Caused by some bad c:function: prototypes. Fix them.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: David S. Miller 


Re: [PATCH v4 33/52] docs: net: statistics.rst: remove a duplicated kernel-doc

2020-09-30 Thread David Miller
From: Mauro Carvalho Chehab 
Date: Wed, 30 Sep 2020 15:24:56 +0200

> include/linux/ethtool.h is included twice with kernel-doc,
> both to document ethtool_pause_stats(). The first one is
> at statistics.rst, and the second one at ethtool-netlink.rst.
> 
> Replace one of the references to use the name of the
> function. The automarkup.py extension should create the
> cross-references.
> 
> Solves this warning:
> 
>   ../Documentation/networking/ethtool-netlink.rst: WARNING: Duplicate C 
> declaration, also defined in 'networking/statistics'.
>   Declaration is 'ethtool_pause_stats'.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: David S. Miller 


Re: [PATCH net-next v4 0/5] net/ravb: Add support for explicit internal clock delay configuration

2020-09-30 Thread David Miller
From: Geert Uytterhoeven 
Date: Wed, 30 Sep 2020 14:21:30 +0200

> Is there anything still blocking this series?

If it's not active in networking patchwork, it needs to be resubmitted
or similar.



Re: [PATCH net-next] net: macb: move pdata to private header

2020-09-30 Thread David Miller
From: Alexandre Belloni 
Date: Wed, 30 Sep 2020 12:50:59 +0200

> struct macb_platform_data is only used by macb_pci to register the platform
> device, move its definition to cadence/macb.h and remove platform_data/macb.h
> 
> Signed-off-by: Alexandre Belloni 

Applied, thank you.


Re: [patch V2 00/36] net: in_interrupt() cleanup and fixes

2020-09-29 Thread David Miller
From: Thomas Gleixner 
Date: Tue, 29 Sep 2020 22:25:09 +0200

> in the discussion about preempt count consistency accross kernel 
> configurations:
> 
>   https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
> 
> Linus clearly requested that code in drivers and libraries which changes
> behaviour based on execution context should either be split up so that
> e.g. task context invocations and BH invocations have different interfaces
> or if that's not possible the context information has to be provided by the
> caller which knows in which context it is executing.
> 
> This includes conditional locking, allocation mode (GFP_*) decisions and
> avoidance of code paths which might sleep.
> 
> In the long run, usage of 'preemptible, in_*irq etc.' should be banned from
> driver code completely.
> 
> This is the second version of the first batch of related changes. V1 can be
> found here:
> 
>  https://lore.kernel.org/r/20200927194846.045411...@linutronix.de
 ...

Series applied to net-next, thanks.


Re: [PATCH][next] fddi/skfp: Avoid the use of one-element array

2020-09-29 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Tue, 29 Sep 2020 08:27:51 -0500

> One-element arrays are being deprecated[1]. Replace the one-element array
> with a simple object of type u_char: 'u_char rm_pad1'[2], once it seems
> this is just a placeholder for padding.
> 
> [1] 
> https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
> [2] https://github.com/KSPP/linux/issues/86
> 
> Built-tested-by: kernel test robot 
> Link: 
> https://lore.kernel.org/lkml/5f72c23f.%2fkpbwczbu+w6hkh4%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 

Applied, thanks.


Re: [PATCH net-next 0/7] net: hns3: updates for -next

2020-09-29 Thread David Miller
From: Huazhong Tan 
Date: Tue, 29 Sep 2020 17:31:58 +0800

> There are some misc updates for the HNS3 ethernet driver.
> #1 uses the queried BD number as the limit for TSO.
> #2 renames trace event hns3_over_8bd since #1.
> #3 adds UDP segmentation offload support.
> #4 adds RoCE VF reset support.
> #5 is a minor cleanup.
> #6 & #7 add debugfs for device specifications and TQP enable status.

Series applied, thank you.


Re: [PATCH net v4] net: phy: realtek: fix rtl8211e rx/tx delay config

2020-09-29 Thread David Miller
From: Willy Liu 
Date: Tue, 29 Sep 2020 10:10:49 +0800

> There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> delays to TXC and RXC for TXD/RXD latching. These two pins can config via
> 4.7k-ohm resistor to 3.3V hw setting, but also config via software setting
> (extension page 0xa4 register 0x1c bit13 12 and 11).
> 
> The configuration register definitions from table 13 official PHY datasheet:
> PHYAD[2:0] = PHY Address
> AN[1:0] = Auto-Negotiation
> Mode = Interface Mode Select
> RX Delay = RX Delay
> TX Delay = TX Delay
> SELRGV = RGMII/GMII Selection
> 
> This table describes how to config these hw pins via external pull-high or 
> pull-
> low resistor.
> 
> It is a misunderstanding that mapping it as register bits below:
> 8:6 = PHY Address
> 5:4 = Auto-Negotiation
> 3 = Interface Mode Select
> 2 = RX Delay
> 1 = TX Delay
> 0 = SELRGV
> So I removed these descriptions above and add related settings as below:
> 14 = reserved
> 13 = force Tx RX Delay controlled by bit12 bit11
> 12 = Tx Delay
> 11 = Rx Delay
> 10:0 = Test && debug settings reserved by realtek
> 
> Test && debug settings are not recommend to modify by default.
> 
> Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays config")
> Signed-off-by: Willy Liu 

Applied and queued up for -stable, thank you.


Re: [PATCH][next] net/sched: cls_u32: Replace one-element array with flexible-array member

2020-09-28 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Mon, 28 Sep 2020 10:30:52 -0500

> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
> 
> Refactor the code according to the use of a flexible-array member in
> struct tc_u_hnode and use the struct_size() helper to calculate the
> size for the allocations. Commit 5778d39d070b ("net_sched: fix struct
> tc_u_hnode layout in u32") makes it clear that the code is expected to
> dynamically allocate divisor + 1 entries for ->ht[] in tc_uhnode. Also,
> based on other observations, as the piece of code below:
> 
> 1232 for (h = 0; h <= ht->divisor; h++) {
> 1233 for (n = rtnl_dereference(ht->ht[h]);
> 1234  n;
> 1235  n = rtnl_dereference(n->next)) {
> 1236 if (tc_skip_hw(n->flags))
> 1237 continue;
> 1238
> 1239 err = u32_reoffload_knode(tp, n, add, cb,
> 1240   cb_priv, 
> extack);
> 1241 if (err)
> 1242 return err;
> 1243 }
> 1244 }
> 
> we can assume that, in general, the code is actually expecting to allocate
> that extra space for the one-element array in tc_uhnode, everytime it
> allocates memory for instances of tc_uhnode or tc_u_common structures.
> That's the reason for passing '1' as the last argument for struct_size()
> in the allocation for _root_ht_ and _tp_c_, and 'divisor + 1' in the
> allocation code for _ht_.
> 
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] 
> https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
> 
> Tested-by: kernel test robot 
> Link: https://lore.kernel.org/lkml/5f7062af.z3t9tn9yipv6h5ny%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH][next] qed/qed_ll2: Replace one-element array with flexible-array member

2020-09-28 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Mon, 28 Sep 2020 10:16:17 -0500

> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
> 
> Refactor the code according to the use of a flexible-array member in
> struct qed_ll2_tx_packet, instead of a one-element array and use the
> struct_size() helper to calculate the size for the allocations. Commit
> f5823fe6897c ("qed: Add ll2 option to limit the number of bds per packet")
> was used as a reference point for these changes.
> 
> Also, it's important to notice that flexible-array members should occur
> last in any structure, and structures containing such arrays and that
> are members of other structures, must also occur last in the containing
> structure. That's why _cur_completing_packet_ is now moved to the bottom
> in struct qed_ll2_tx_queue. _descq_mem_ and _cur_send_packet_ are also
> moved for unification.
> 
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] 
> https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
> 
> Tested-by: kernel test robot 

I find such tags enormously misleading, because the kernel test robot
didn't perform any functional testing of this change and honestly
that's the part I'm more concerned about rather than "does it build".

Anyone can check test the build.

> Link: https://lore.kernel.org/lkml/5f707198.pa1ucz8myozyzyar%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH v1 net-next] stmmac: intel: Adding ref clock 1us tic for LPI cntr

2020-09-28 Thread David Miller
From: Voon Weifeng 
Date: Mon, 28 Sep 2020 18:12:12 +0800

> From: Rusaimi Amira Ruslan 
> 
> Adding reference clock (1us tic) for all LPI timer on Intel platforms.
> The reference clock is derived from ptp clk. This also enables all LPI
> counter.
> 
> Signed-off-by: Rusaimi Amira Ruslan 
> Signed-off-by: Voon Weifeng 

Applied.


Re: [PATCH] net/x25: Fix null-ptr-deref in x25_connect

2020-09-28 Thread David Miller
From: Martin Schiller 
Date: Mon, 28 Sep 2020 11:23:27 +0200

> diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
> index 0bbb283f23c9..0524a5530b91 100644
> --- a/net/x25/af_x25.c
> +++ b/net/x25/af_x25.c
> @@ -820,7 +820,7 @@ static int x25_connect(struct socket *sock, struct 
> sockaddr *uaddr,
>  
>   rc = x25_wait_for_connection_establishment(sk);
>   if (rc)
> - goto out_put_neigh;
> + goto out;

If x25_wait_for_connection_establishment() returns because of an interrupting
signal, we are not going to call x25_disconnect().

The case you are fixing only applies _sometimes_ when
x25_wait_for_connection_establishment() returns.  But not always.

That neighbour has to be released at this spot otherwise.


Re: [PATCH] net: usb: ax88179_178a: add MCT usb 3.0 adapter

2020-09-28 Thread David Miller
From: Wilken Gottwalt 
Date: Mon, 28 Sep 2020 11:17:40 +0200

> Adds the driver_info and usb ids of the AX88179 based MCT U3-A9003 USB
> 3.0 ethernet adapter.
> 
> Signed-off-by: Wilken Gottwalt 

Applied.


Re: [PATCH v2] net: usb: ax88179_178a: fix missing stop entry in driver_info

2020-09-28 Thread David Miller
From: Wilken Gottwalt 
Date: Mon, 28 Sep 2020 11:01:04 +0200

> Adds the missing .stop entry in the Belkin driver_info structure.
> 
> Signed-off-by: Wilken Gottwalt 
> ---
> Changes in v2:
> - reposted to proper mailing list

Applied and queued up for -stable, please provide a proper Fixes: tag
next time.


Re: [PATCH net-next 00/10] net: ipa: miscellaneous cleanups

2020-09-28 Thread David Miller
From: Alex Elder 
Date: Mon, 28 Sep 2020 18:04:36 -0500

> This series contains some minor cleanups I've been meaning to get
> around to for a while.  The first few remove the definitions of some
> currently-unused symbols.  Several fix some warnings that are reported
> when the build is done with "W=2".  All are simple and have no effect
> on the operation of the code.

Series applied, thanks Alex.


Re: [PATCH] net: Use kobj_to_dev() API

2020-09-28 Thread David Miller
From: Wang Qing 
Date: Sat, 26 Sep 2020 14:49:18 +0800

> Use kobj_to_dev() instead of container_of().
> 
> Signed-off-by: Wang Qing 

Applied to net-next, thank you.


Re: [PATCH] fs: remove ->sendpage

2020-09-28 Thread David Miller
From: Christoph Hellwig 
Date: Sat, 26 Sep 2020 09:00:49 +0200

> ->sendpage is only called from generic_splice_sendpage.  The only user of
> generic_splice_sendpage is socket_file_ops, which is also the only
> instance that actually implements ->sendpage.  Remove the ->sendpage file
> operation and just open code the logic in the socket code.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 


Re: [PATCH net] drivers/net/wan/x25_asy: Keep the ldisc running even when netif is down

2020-09-28 Thread David Miller
From: Xie He 
Date: Sat, 26 Sep 2020 13:56:10 -0700

> @@ -265,7 +269,9 @@ static void x25_asy_write_wakeup(struct tty_struct *tty)
>* transmission of another packet */
>   sl->dev->stats.tx_packets++;
>   clear_bit(TTY_DO_WRITE_WAKEUP, >flags);
> - x25_asy_unlock(sl);
> + /* FIXME: The netif may go down after netif_running returns */
> + if (netif_running(sl->dev))
> + x25_asy_unlock(sl);
>   return;

It could also go back down and also back up again after you do this
test.  Maybe even 10 or 100 times over.

You can't just leave things so incredibly racy like this, please apply
proper synchronization between netdev state changes and this TTY code.

Thank you.


Re: [PATCH] net: qrtr: ns: Protect radix_tree_deref_slot() using rcu read locks

2020-09-28 Thread David Miller
From: Manivannan Sadhasivam 
Date: Sat, 26 Sep 2020 22:26:25 +0530

> The rcu read locks are needed to avoid potential race condition while
> dereferencing radix tree from multiple threads. The issue was identified
> by syzbot. Below is the crash report:
 ...
> Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from 
> userspace")
> Reported-and-tested-by: syzbot+0f84f6eed90503da7...@syzkaller.appspotmail.com
> Signed-off-by: Manivannan Sadhasivam 

Applied and queued up for -stable, thank you.


Re: [PATCH] atm: atmtcp: Constify atmtcp_v_dev_ops

2020-09-28 Thread David Miller
From: Rikard Falkeborn 
Date: Sun, 27 Sep 2020 23:10:42 +0200

> The only usage of atmtcp_v_dev_ops is to pass its address to
> atm_dev_register() which takes a pointer to const, and comparing its
> address to another address, which does not modify it. Make it const to
> allow the compiler to put it in read-only memory.
> 
> Signed-off-by: Rikard Falkeborn 

Applied to net-next


Re: [RESEND PATCH net-next v5 0/2] DP83869 WoL and Speed optimization

2020-09-28 Thread David Miller
From: Dan Murphy 
Date: Mon, 28 Sep 2020 09:51:33 -0500

> Add the WoL and Speed Optimization (aka downshift) support for the DP83869
> Ethernet PHY.

Series applied.


Re: [PATCH net-next v5 1/2] net: phy: dp83869: support Wake on LAN

2020-09-28 Thread David Miller
From: Dan Murphy 
Date: Mon, 28 Sep 2020 09:47:24 -0500

> Hello
> 
> On 9/28/20 9:46 AM, Dan Murphy wrote:
>> This adds WoL support on TI DP83869 for magic, magic secure, unicast
>> and
>> broadcast.
>>
>> Signed-off-by: Dan Murphy 
>> ---
>>
>> v5 - Fixed 0-day warning for u16
>>
>>   arch/arm/configs/ti_sdk_omap2_debug_defconfig | 2335 +
> 
> I have to repost this patch as this got added when updating the
> patches when I was testing.

Next time, don't make it a "repost", make it 'v6' instead.

Thank you.


Re: [PATCH net] net: ethernet: ave: Replace alloc_etherdev() with devm_alloc_etherdev()

2020-09-28 Thread David Miller
From: Kunihiko Hayashi 
Date: Mon, 28 Sep 2020 19:04:53 +0900

> Use devm_alloc_etherdev() to simplify the code instead of alloc_etherdev().
> 
> Signed-off-by: Kunihiko Hayashi 

Applied to net-next, thanks.


Re: [PATCH v1 net] net: stmmac: Modify configuration method of EEE timers

2020-09-28 Thread David Miller
From: Voon Weifeng 
Date: Mon, 28 Sep 2020 18:02:41 +0800

> @@ -90,11 +90,12 @@ static const u32 default_msg_level = (NETIF_MSG_DRV | 
> NETIF_MSG_PROBE |
> NETIF_MSG_LINK | NETIF_MSG_IFUP |
> NETIF_MSG_IFDOWN | NETIF_MSG_TIMER);
>  
> -#define STMMAC_DEFAULT_LPI_TIMER 1000
> -static int eee_timer = STMMAC_DEFAULT_LPI_TIMER;
> -module_param(eee_timer, int, 0644);
> -MODULE_PARM_DESC(eee_timer, "LPI tx expiration time in msec");
> -#define STMMAC_LPI_T(x) (jiffies + msecs_to_jiffies(x))
> +#define STMMAC_DEFAULT_LPI_TIMER 100
> +#define STMMAC_LPI_T(x)  (jiffies + usecs_to_jiffies(x))
> +
> +static int tw_timer = STMMAC_DEFAULT_TWT_LS;
> +module_param(tw_timer, int, 0644);
> +MODULE_PARM_DESC(tw_timer, "LPI TW timer value in msec");

This is a great example of one of the many reasons why we disallow
module parameters in networking drivers.

This is a user facing value, and now you changed the name which breaks
things for anyone who was accessing this module parameter previously.

You have to find a way to specify this value using existing kernel
infrastructure such as ethtool or devlink, and not using a module
parameter.

So please get rid of this module parameter, and add a way to set this
value portably.


Re: [PATCH net-next] net: vlan: Fixed signedness in vlan_group_prealloc_vid()

2020-09-28 Thread David Miller
From: Florian Fainelli 
Date: Sun, 27 Sep 2020 19:31:50 -0700

> After commit d0186842ec5f ("net: vlan: Avoid using BUG() in
> vlan_proto_idx()"), vlan_proto_idx() was changed to return a signed
> integer, however one of its called: vlan_group_prealloc_vid() was still
> using an unsigned integer for its return value, fix that.
> 
> Fixes: d0186842ec5f ("net: vlan: Avoid using BUG() in vlan_proto_idx()")
> Reported-by: kernel test robot 
> Signed-off-by: Florian Fainelli 

Applied, thanks Florian.


Re: [patch 00/35] net: in_interrupt() cleanup and fixes

2020-09-27 Thread David Miller
From: Thomas Gleixner 
Date: Sun, 27 Sep 2020 21:48:46 +0200

> in the discussion about preempt count consistency accross kernel 
> configurations:

Please respin this against net-next, some of the patches in here are already
in net-next (the wireless debug macro one) and even after that the series
doesn't build:

drivers/net/ethernet/cisco/enic/enic_main.c: In function ‘enic_reset’:
drivers/net/ethernet/cisco/enic/enic_main.c:2315:2: error: implicit declaration 
of function ‘enic_set_api_state’; did you mean ‘enic_set_api_busy’? 
[-Werror=implicit-function-declaration]
 2315 |  enic_set_api_state(enic, true);
  |  ^~
  |  enic_set_api_busy
At top level:
drivers/net/ethernet/cisco/enic/enic_main.c:2298:13: warning: 
‘enic_set_api_busy’ defined but not used [-Wunused-function]
 2298 | static void enic_set_api_busy(struct enic *enic, bool busy)
  | ^


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

2020-09-27 Thread David Miller
From: Lad Prabhakar 
Date: Sun, 27 Sep 2020 13:34:39 +0100

> From: Marian-Cristian Rotariu 
> 
> Document RZ/G2H (R8A774E1) SoC bindings.
> 
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
> Acked-by: Rob Herring 

Applied.


Re: [PATCH] ptp: add stub function for ptp_get_msgtype()

2020-09-27 Thread David Miller
From: Yangbo Lu 
Date: Sun, 27 Sep 2020 16:01:50 +0800

> Added the missing stub function for ptp_get_msgtype().
> 
> Reported-by: Randy Dunlap 
> Fixes: 036c508ba95e ("ptp: Add generic ptp message type function")
> Signed-off-by: Yangbo Lu 

Applied to net-next, thanks.


Re: [PATCH net-next 00/10] net: hns3: updates for -next

2020-09-27 Thread David Miller
From: Huazhong Tan 
Date: Sun, 27 Sep 2020 15:12:38 +0800

> To facilitate code maintenance and compatibility, #1 and #2 add
> device version to replace pci revision, #3 to #9 adds support for
> querying device capabilities and specifications, then the driver
> can use these query results to implement corresponding features
> (some features will be implemented later).
> 
> And #10 is a minor cleanup since too many parameters for
> hclge_shaper_para_calc().

Series applied, thank you.


Re: [PATCH][next] dpaa2-mac: Fix potential null pointer dereference

2020-09-25 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Fri, 25 Sep 2020 12:03:23 -0500

> There is a null-check for _pcs_, but it is being dereferenced
> prior to this null-check. So, if _pcs_ can actually be null,
> then there is a potential null pointer dereference that should
> be fixed by null-checking _pcs_ before being dereferenced.
> 
> Addresses-Coverity-ID: 1497159 ("Dereference before null check")
> Fixes: 94ae899b2096 ("dpaa2-mac: add PCS support through the Lynx module")
> Signed-off-by: Gustavo A. R. Silva 

Applied, thanks.


Re: [PATCH v2] net: usb: ax88179_178a: add Toshiba usb 3.0 adapter

2020-09-25 Thread David Miller
From: Wilken Gottwalt 
Date: Fri, 25 Sep 2020 15:58:57 +0200

> Adds the driver_info and usb ids of the AX88179 based Toshiba USB 3.0
> ethernet adapter.
> 
> Signed-off-by: Wilken Gottwalt 

Applied.


Re: [PATCH V2 0/5 net-next] vxlan: clean-up

2020-09-25 Thread David Miller
From: Fabian Frederick 
Date: Fri, 25 Sep 2020 15:15:41 +0200

> This small patchet does some clean-up on vxlan.
> Second version removes VXLAN_NL2FLAG macro relevant patches as suggested by 
> Michal and David
> 
> I hope to have some feedback/ACK from vxlan developers.

Series applied, thanks.


Re: [PATCH] net: ethernet: cavium: octeon_mgmt: use phy_start and phy_stop

2020-09-25 Thread David Miller
From: Ivan Khoronzhuk 
Date: Fri, 25 Sep 2020 15:44:39 +0300

> To start also "phy state machine", with UP state as it should be,
> the phy_start() has to be used, in another case machine even is not
> triggered. After this change negotiation is supposed to be triggered
> by SM workqueue.
> 
> It's not correct usage, but it appears after the following patch,
> so add it as a fix.
> 
> Fixes: 74a992b3598a ("net: phy: add phy_check_link_status")
> Signed-off-by: Ivan Khoronzhuk 

Applied and queued up for -stable, thanks.


Re: [PATCH net 1/1] net: stmmac: Fix clock handling on remove path

2020-09-25 Thread David Miller
From: Wong Vee Khee 
Date: Fri, 25 Sep 2020 17:54:06 +0800

> While unloading the dwmac-intel driver, clk_disable_unprepare() is
> being called twice in stmmac_dvr_remove() and
> intel_eth_pci_remove(). This causes kernel panic on the second call.
> 
> Removing the second call of clk_disable_unprepare() in
> intel_eth_pci_remove().
> 
> Fixes: 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove 
> paths")
> Cc: Andy Shevchenko 
> Reviewed-by: Voon Weifeng 
> Signed-off-by: Wong Vee Khee 

Applied, thanks.


Re: [PATCH net-next 1/1] net: stmmac: Add option for VLAN filter fail queue enable

2020-09-25 Thread David Miller
From: Wong Vee Khee 
Date: Fri, 25 Sep 2020 17:40:41 +0800

> From: "Chuah, Kim Tatt" 
> 
> Add option in plat_stmmacenet_data struct to enable VLAN Filter Fail
> Queuing. This option allows packets that fail VLAN filter to be routed
> to a specific Rx queue when Receive All is also set.
> 
> When this option is enabled:
> - Enable VFFQ only when entering promiscuous mode, because Receive All
>   will pass up all rx packets that failed address filtering (similar to
>   promiscuous mode).
> - VLAN-promiscuous mode is never entered to allow rx packet to fail VLAN
>   filters and get routed to selected VFFQ Rx queue.
> 
> Reviewed-by: Voon Weifeng 
> Reviewed-by: Ong Boon Leong 
> Signed-off-by: Chuah, Kim Tatt 
> Signed-off-by: Ong Boon Leong 

Applied.


Re: [PATCH net] vmxnet3: fix cksum offload issues for non-udp tunnels

2020-09-25 Thread David Miller
From: Ronak Doshi 
Date: Thu, 24 Sep 2020 23:11:29 -0700

> Commit dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload
> support") added support for encapsulation offload. However, the inner
> offload capability is to be restrictued to UDP tunnels.
> 
> This patch fixes the issue for non-udp tunnels by adding features
> check capability and filtering appropriate features for non-udp tunnels.
> 
> Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support")
> Signed-off-by: Ronak Doshi 

Applied and queued up for -stable, thanks.


Re: [PATCH] net: stmmac: dwmac-meson8b: add calibration registers

2020-09-25 Thread David Miller
From: Martin Blumenstingl 
Date: Fri, 25 Sep 2020 23:56:29 +0200

> The Amlogic dwmac Ethernet IP glue has two registers:
> - PRG_ETH0 with various configuration bits
> - PRG_ETH1 with various calibration and information related bits
> 
> Add the register definitions with comments from different drivers in
> Amlogic's vendor u-boot and Linux.
> 
> The most important part is PRG_ETH1_AUTO_CALI_IDX_VAL which is needed on
> G12A (and later: G12B, SM1) with RGMII PHYs. Ethernet is only working up
> to 100Mbit/s speeds if u-boot does not initialize these bits correctly.
> On 1Gbit/s links no traffic is flowing (similar to when the RGMII delays
> are set incorrectly). The logic to write this register will be added
> later.
> 
> Signed-off-by: Martin Blumenstingl 

Please add these definitions alongside actual uses of them.

Thank you.


Re: [PATCH net-next v2] net: vlan: Avoid using BUG() in vlan_proto_idx()

2020-09-25 Thread David Miller
From: Florian Fainelli 
Date: Thu, 24 Sep 2020 17:27:44 -0700

> While we should always make sure that we specify a valid VLAN protocol
> to vlan_proto_idx(), killing the machine when an invalid value is
> specified is too harsh and not helpful for debugging. All callers are
> capable of dealing with an error returned by vlan_proto_idx() so check
> the index value and propagate it accordingly.
> 
> Signed-off-by: Florian Fainelli 
> ---
> Changes in v2:
> - changed signature to return int
> - changed message to use ntohs()
> - renamed an index variable to 'pidx' instead of 'pdix'

Applied, thanks Florian.


Re: [RFC] openprom: Fix 'opiocnextprop'; ensure integer conversions; use string size

2020-09-25 Thread David Miller
From: Michael Witten 
Date: Fri, 25 Sep 2020 20:20:20 -

> Are we trying to improve the code or not?

Do you want me to apply your patch or not?

I want to see the most minimal code change necessary to fix the bug,
so we can easily backport it to -stable releases etc.

If you want to perform a variable name or other similar cosmetic
improvement, you can send a follow-up patch that does so.

Thank you.


Re: [PATCH net-next 0/6] net: hns3: updates for -next

2020-09-24 Thread David Miller
From: Huazhong Tan 
Date: Fri, 25 Sep 2020 08:26:12 +0800

> There are some updates for the HNS3 ethernet driver.
> #1 & #2 are two cleanups.
> #3 adds new hardware error for the client.
> #4 adds debugfs support the pf's interrupt resource.
> #5 adds new pci device id for 200G device.
> #6 renames the unsuitable macro of vf's pci device id.

Series applied, thank you.


Re: [PATCH] net/ethernet/broadcom: fix spelling typo

2020-09-24 Thread David Miller
From: Wang Qing 
Date: Thu, 24 Sep 2020 14:50:24 +0800

> Modify the comment typo: "compliment" -> "complement".
> 
> Signed-off-by: Wang Qing 

Applied, thank you.


Re: [net] net: mscc: ocelot: fix fields offset in SG_CONFIG_REG_3

2020-09-24 Thread David Miller
From: Xiaoliang Yang 
Date: Thu, 24 Sep 2020 10:11:13 +0800

> INIT_IPS and GATE_ENABLE fields have a wrong offset in SG_CONFIG_REG_3.
> This register is used by stream gate control of PSFP, and it has not
> been used before, because PSFP is not implemented in ocelot driver.
> 
> Signed-off-by: Xiaoliang Yang 

Applied and queued up for -stable.


Re: [PATCH net] hinic: fix wrong return value of mac-set cmd

2020-09-24 Thread David Miller
From: Luo bin 
Date: Thu, 24 Sep 2020 09:31:51 +0800

> It should also be regarded as an error when hw return status=4 for PF's
> setting mac cmd. Only if PF return status=4 to VF should this cmd be
> taken special treatment.
> 
> Fixes: 7dd29ee12865 ("hinic: add sriov feature support")
> Signed-off-by: Luo bin 

Applied and queued up for -stable.


Re: [net] net: dsa: felix: convert TAS link speed based on phylink speed

2020-09-24 Thread David Miller
From: Xiaoliang Yang 
Date: Thu, 24 Sep 2020 09:57:46 +0800

> state->speed holds a value of 10, 100, 1000 or 2500, but
> QSYS_TAG_CONFIG_LINK_SPEED expects a value of 0, 1, 2, 3. So convert the
> speed to a proper value.
> 
> Fixes: de143c0e274b ("net: dsa: felix: Configure Time-Aware Scheduler via 
> taprio offload")
> Signed-off-by: Xiaoliang Yang 
> Reviewed-by: Vladimir Oltean 

Applied and queued up for -stable.


Re: [MPTCP][PATCH net-next 00/16] mptcp: RM_ADDR/ADD_ADDR enhancements

2020-09-24 Thread David Miller
From: Geliang Tang 
Date: Thu, 24 Sep 2020 08:29:46 +0800

> This series include two enhancements for the MPTCP path management,
> namely RM_ADDR support and ADD_ADDR echo support, as specified by RFC
> sections 3.4.1 and 3.4.2.
> 
> 1 RM_ADDR support include 9 patches (1-3 and 8-13):
> 
> Patch 1 is the helper for patch 2, these two patches add the RM_ADDR
> outgoing functions, which are derived from ADD_ADDR's corresponding
> functions.
> 
> Patch 3 adds the RM_ADDR incoming logic, when RM_ADDR suboption is
> received, close the subflow matching the rm_id, and update PM counter.
> 
> Patch 8 is the main remove routine. When the PM netlink removes an address,
> we traverse all the existing msk sockets to find the relevant sockets. Then
> trigger the RM_ADDR signal and remove the subflow which using this local
> address, this subflow removing functions has been implemented in patch 9.
> 
> Finally, patches 10-13 are the self-tests for RM_ADDR.
> 
> 2 ADD_ADDR echo support include 7 patches (4-7 and 14-16).
> 
> Patch 4 adds the ADD_ADDR echo logic, when the ADD_ADDR suboption has been
> received, send out the same ADD_ADDR suboption with echo-flag, and no HMAC
> included.
> 
> Patches 5 and 6 are the self-tests for ADD_ADDR echo. Patch 7 is a little
> cleaning up.
> 
> Patch 14 and 15 are the helpers for patch 16. These three patches add
> the ADD_ADDR retransmition when no ADD_ADDR echo is received.

Series applied, thank you.


<    1   2   3   4   5   6   7   8   9   10   >