Re: [PATCH net v2] drivers/net/wan/x25_asy: Correct the ndo_open and ndo_stop functions

2020-09-24 Thread David Miller
From: Xie He 
Date: Wed, 23 Sep 2020 11:18:18 -0700

> 1.
> Move the lapb_register/lapb_unregister calls into the ndo_open/ndo_stop
> functions.
> This makes the LAPB protocol start/stop when the network interface
> starts/stops. When the network interface is down, the LAPB protocol
> shouldn't be running and the LAPB module shoudn't be generating control
> frames.
> 
> 2.
> Move netif_start_queue/netif_stop_queue into the ndo_open/ndo_stop
> functions.
> This makes the TX queue start/stop when the network interface
> starts/stops.
> (netif_stop_queue was originally in the ndo_stop function. But to make
> the code look better, I created a new function to use as ndo_stop, and
> made it call the original ndo_stop function. I moved netif_stop_queue
> from the original ndo_stop function to the new ndo_stop function.)
> 
> Cc: Martin Schiller 
> Signed-off-by: Xie He 

Applied, thank you.


Re: [PATCH net-next v3 0/2] net: dsa: b53: Configure VLANs while not filtering

2020-09-23 Thread David Miller
From: Florian Fainelli 
Date: Wed, 23 Sep 2020 14:40:36 -0700

> These two patches allow the b53 driver which always configures its CPU
> port as egress tagged to behave correctly with VLANs being always
> configured whenever a port is added to a bridge.
> 
> Vladimir provides a patch that aligns the bridge with vlan_filtering=0
> receive path to behave the same as vlan_filtering=1. Per discussion with
> Nikolay, this behavior is deemed to be too DSA specific to be done in
> the bridge proper.
> 
> This is a preliminary series for Vladimir to make
> configure_vlan_while_filtering the default behavior for all DSA drivers
> in the future.
 ...

Series applied, thanks Florian.


Re: [PATCH] net: mdio: Remove redundant parameter and check

2020-09-23 Thread David Miller
From: Tang Bin 
Date: Wed, 23 Sep 2020 18:05:32 +0800

> @@ -125,12 +124,9 @@ ipq8064_mdio_probe(struct platform_device *pdev)
>   return PTR_ERR(priv->base);
>   }
>  
> - ret = of_mdiobus_register(bus, np);
> - if (ret)
> - return ret;
> -
>   platform_set_drvdata(pdev, bus);
> - return 0;
> +
> + return of_mdiobus_register(bus, np);
>  }

You are changing the code rather than simplifying the return sequence.

The author of this code intended the platform_set_drvdata() to only
happen if all operations of this function succeeded.

I am not applying this patch, sorry.


Re: [PATCH v1 net] net: stmmac: removed enabling eee in EEE set callback

2020-09-23 Thread David Miller
From: Voon Weifeng 
Date: Wed, 23 Sep 2020 16:56:14 +0800

> EEE should be only be enabled during stmmac_mac_link_up() when the
> link are up and being set up properly. set_eee should only do settings
> configuration and disabling the eee.
> 
> Without this fix, turning on EEE using ethtool will return
> "Operation not supported". This is due to the driver is in a dead loop
> waiting for eee to be advertised in the for eee to be activated but the
> driver will only configure the EEE advertisement after the eee is
> activated.
> 
> Ethtool should only return "Operation not supported" if there is no EEE
> capbility in the MAC controller.
> 
> Fixes: 8a7493e58ad6 ("net: stmmac: Fix a race in EEE enable callback")
> 
> Signed-off-by: Voon Weifeng 

Please do not insert empty lines between Fixes: and other tags.  All tags
are equal and belong together in a group.

I fixed that up, applied the patch, and queued it up for -stable.

Thank you.


Re: [PATCH net-next 0/2] net: dsa: bcm_sf2: Additional DT changes

2020-09-23 Thread David Miller
From: Florian Fainelli 
Date: Tue, 22 Sep 2020 13:03:54 -0700

> This patch series includes some additional changes to the bcm_sf2 in
> order to support the Device Tree firmwares provided on such platforms.

Series applied, thanks Florian.


Re: [net-next PATCH 0/2] Add support for VLAN based flow distribution

2020-09-23 Thread David Miller
From: George Cherian 
Date: Tue, 22 Sep 2020 18:37:25 +0530

> This series add support for VLAN based flow distribution for octeontx2
> netdev driver. This adds support for configuring the same via ethtool.
> 
> Following tests have been done.
>   - Multi VLAN flow with same SD
>   - Multi VLAN flow with same SDFN
>   - Single VLAN flow with multi SD
>   - Single VLAN flow with multi SDFN
> All tests done for udp/tcp both v4 and v6

Series applied to net-next, thanks.


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

2020-09-23 Thread David Miller
From: Luo bin 
Date: Tue, 22 Sep 2020 19:26:43 +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.
> 
> Signed-off-by: Luo bin 

Bug fixes require a proper Fixes: tag.

Please resubmit with the corrected, thank you.


Re: [PATCH 1/3] net: fix a new kernel-doc warning at dev.c

2020-09-23 Thread David Miller
From: Mauro Carvalho Chehab 
Date: Tue, 22 Sep 2020 13:22:52 +0200

> kernel-doc expects the function prototype to be just after
> the kernel-doc markup, as otherwise it will get it all wrong:
> 
>   ./net/core/dev.c:10036: warning: Excess function parameter 'dev' 
> description in 'WAIT_REFS_MIN_MSECS'
> 
> Fixes: 0e4be9e57e8c ("net: use exponential backoff in netdev_wait_allrefs")
> Signed-off-by: Mauro Carvalho Chehab 

Applied to net-next.


Re: [PATCH v5 0/2] net: mdio-ipq4019: add Clause 45 support

2020-09-23 Thread David Miller
From: Robert Marko 
Date: Tue, 22 Sep 2020 12:16:30 +0200

> This patch series adds support for Clause 45 to the driver.
> 
> While at it also change some defines to upper case to match rest of the 
> driver.
> 
> Changes since v4:
> * Rebase onto net-next.git
> 
> Changes since v1:
> * Drop clock patches, these need further investigation and
> no user for non default configuration has been found

Series applied, thank you.


Re: [PATCH net] Revert "ravb: Fixed to be able to unload modules"

2020-09-23 Thread David Miller
From: Geert Uytterhoeven 
Date: Tue, 22 Sep 2020 09:29:31 +0200

> This reverts commit 1838d6c62f57836639bd3d83e7855e0ee4f6defc.
> 
> This commit moved the ravb_mdio_init() call (and thus the
> of_mdiobus_register() call) from the ravb_probe() to the ravb_open()
> call.  This causes a regression during system resume (s2idle/s2ram), as
> new PHY devices cannot be bound while suspended.
 ...
> 
> Signed-off-by: Geert Uytterhoeven 
> Cc: sta...@vger.kernel.org

I noticed this too late, but please don't CC: stable on networking
patches.  We have our own workflow as per the netdev FAQ.

I've applied this but the inability to remove a module is an
extremely serious bug and should be fixed properly.


Re: [PATCH net-next] net: hns3: Constify static structs

2020-09-23 Thread David Miller
From: Rikard Falkeborn 
Date: Tue, 22 Sep 2020 00:55:17 +0200

> A number of static variables were not modified. Make them const to allow
> the compiler to put them in read-only memory. In order to do so,
> constify a couple of input pointers as well as some local pointers.
> This moves about 35Kb to read-only memory as seen by the output of the
> size command.
> 
> Before:
>textdata bss dec hex filename
>  404938  111534 640  517112   7e3f8 
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge.ko
> 
> After:
>textdata bss dec hex filename
>  439499   76974 640  517113   7e3f9 
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge.ko
> 
> Signed-off-by: Rikard Falkeborn 

Applied.


Re: [PATCH net-next v3] mptcp: Wake up MPTCP worker when DATA_FIN found on a TCP FIN packet

2020-09-23 Thread David Miller
From: Matthieu Baerts 
Date: Mon, 21 Sep 2020 16:57:58 +0200

> From: Mat Martineau 
> 
> When receiving a DATA_FIN MPTCP option on a TCP FIN packet, the DATA_FIN
> information would be stored but the MPTCP worker did not get
> scheduled. In turn, the MPTCP socket state would remain in
> TCP_ESTABLISHED and no blocked operations would be awakened.
> 
> TCP FIN packets are seen by the MPTCP socket when moving skbs out of the
> subflow receive queues, so schedule the MPTCP worker when a skb with
> DATA_FIN but no data payload is moved from a subflow queue. Other cases
> (DATA_FIN on a bare TCP ACK or on a packet with data payload) are
> already handled.
> 
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/84
> Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine")
> Acked-by: Paolo Abeni 
> Signed-off-by: Mat Martineau 
> Signed-off-by: Matthieu Baerts 

Applied to 'net', thanks.


Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

2020-09-23 Thread David Miller
From: David Miller 
Date: Wed, 23 Sep 2020 17:21:25 -0700 (PDT)

> If an async code path tests 'present', gets true, and then the RTNL
> holding synchronous code path puts the device into D3hot immediately
> afterwards, the async code path will still continue and access the
> chips registers and fault.

Wait, is the sequence:

->ndo_stop()
mark device not present and put into D3hot
triggers linkwatch event
  ...
 ->ndo_get_stats64()

???

Then yeah we might have to clear IFF_UP at the beginning of taking
a netdev down.


Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

2020-09-23 Thread David Miller
From: Saeed Mahameed 
Date: Wed, 23 Sep 2020 15:42:17 -0700

> Maybe we need to clear IFF_UP before calling ops->ndo_stop(dev),
> instead of after on __dev_close_many(). Assuming no driver is checking
> IFF_UP state on its own ndo_stop(), other than this, the order
> shouldn't really matter, since clearing the flag and calling ndo_stop()
> should be considered as one atomic operation.

This is my biggest concern, that some ndo_stop, or some helper called
by ndo_stop, checks IFF_UP or similar.

There is also something else.  We have both synchronous and async code
that checks state like IFF_UP and 'present' and makes a decision based
upon that.

If an async code path tests 'present', gets true, and then the RTNL
holding synchronous code path puts the device into D3hot immediately
afterwards, the async code path will still continue and access the
chips registers and fault.

I'm saying all of this because the only way this bug makes sense
is if the ->ndo_stop() sequence that marks the device !present and
then clears IFF_UP runs with the RTNL mutex held, and the code path
that tests this state in the linkwatch bits in question do not.


Re: [PATCH] net: fec: Keep device numbering consistent with datasheet

2020-09-23 Thread David Miller
From: Stefan Riedmueller 
Date: Wed, 23 Sep 2020 16:25:28 +0200

> From: Christian Hemp 
> 
> Make use of device tree alias for device enumeration to keep the device
> order consistent with the naming in the datasheet.
> 
> Otherwise for the i.MX 6UL/ULL the ENET1 interface is enumerated as eth1
> and ENET2 as eth0.
> 
> Signed-off-by: Christian Hemp 
> Signed-off-by: Stefan Riedmueller 

Device naming and ordering for networking devices was never, ever,
guaranteed.

Use udev or similar.

> @@ -3691,6 +3692,10 @@ fec_probe(struct platform_device *pdev)
>  
>   ndev->max_mtu = PKT_MAXBUF_SIZE - ETH_HLEN - ETH_FCS_LEN;
>  
> + eth_id = of_alias_get_id(pdev->dev.of_node, "ethernet");
> + if (eth_id >= 0)
> + sprintf(ndev->name, "eth%d", eth_id);

You can't ever just write into ndev->name, what if another networking
device is already using that name?

This change is incorrect on many levels.


Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

2020-09-23 Thread David Miller
From: Heiner Kallweit 
Date: Wed, 23 Sep 2020 21:58:59 +0200

> On 23.09.2020 20:35, Saeed Mahameed wrote:
>> Why would a driver detach the device on ndo_stop() ?
>> seems like this is the bug you need to be chasing ..
>> which driver is doing this ? 
>> 
> Some drivers set the device to PCI D3hot at the end of ndo_stop()
> to save power (using e.g. Runtime PM). Marking the device as detached
> makes clear to to the net core that the device isn't accessible any
> longer.

That being the case, the problem is that IFF_UP+!present is not a
valid netdev state.

Is it simply the issue that, upon resume, IFF_UP is marked true before
the device is brought out from D3hot state and thus marked as present
again?


Re: [PATCH net-next v2] net: microchip: Make `lan743x_pm_suspend` function return right value

2020-09-23 Thread David Miller
From: Zheng Yongjun 
Date: Wed, 23 Sep 2020 11:21:40 +0800

> drivers/net/ethernet/microchip/lan743x_main.c: In function lan743x_pm_suspend:
> 
> `ret` is set but not used. In fact, `pci_prepare_to_sleep` function value 
> should
> be the right value of `lan743x_pm_suspend` function, therefore, fix it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.


Re: [PATCH net-next] net: microchip: Make `lan743x_pm_suspend` function return right value

2020-09-22 Thread David Miller
From: Zheng Yongjun 
Date: Mon, 21 Sep 2020 20:08:18 +0800

> @@ -3053,7 +3053,7 @@ static int lan743x_pm_suspend(struct device *dev)
>   /* Host sets PME_En, put D3hot */
>   ret = pci_prepare_to_sleep(pdev);
>  
> - return 0;
> + return ret;
>  }

Instead please do:

return pci_preprare_to_sleep(pdev);

And if 'ret' is then completely unused as a result, remove it.


Re: [PATCH net-next 2/5] bonding: rename slave to link where possible

2020-09-22 Thread David Miller
From: Michal Kubecek 
Date: Wed, 23 Sep 2020 01:23:17 +0200

> Even if the module parameters are deprecated and extremely inconvenient
> as a mean of bonding configuration, I would say changing their names
> would still count as "breaking the userspace".

I totally agree.

Anything user facing has to be kept around for the deprecation period,
and that includes module parameters.


Re: [PATCH] kbuild: explicitly specify the build id style

2020-09-22 Thread David Miller
From: Bill Wendling 
Date: Tue, 22 Sep 2020 16:21:40 -0700

> ld's --build-id defaults to "sha1" style, while lld defaults to "fast".
> The build IDs are very different between the two, which may confuse
> programs that reference them.
> 
> Signed-off-by: Bill Wendling 

Acked-by: David S. Miller 


Re: [PATCH net-next] net: Update MAINTAINERS for MediaTek switch driver

2020-09-21 Thread David Miller
From: 
Date: Tue, 22 Sep 2020 07:09:23 +0800

> From: Sean Wang 
> 
> Update maintainers for MediaTek switch driver with Landen Chao who is
> familiar with MediaTek MT753x switch devices and will help maintenance
> from the vendor side.
> 
> Cc: Steven Liu 
> Signed-off-by: Sean Wang 
> Signed-off-by: Landen Chao 

Applied to 'net' as it's important to have the mainline MAINTAINERS
information as uptodate as possible.

Thanks.


Re: [PATCH net-next] net: phy: bcm7xxx: Add an entry for BCM72113

2020-09-21 Thread David Miller
From: Florian Fainelli 
Date: Mon, 21 Sep 2020 15:10:53 -0700

> BCM72113 features a 28nm integrated EPHY, add an entry to the driver for
> it.
> 
> Signed-off-by: Florian Fainelli 

Applied, thanks Florian.


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

2020-09-21 Thread David Miller
From: Zheng Yongjun 
Date: Mon, 21 Sep 2020 20:18:41 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/natsemi/ns83820.c: In function 
> ns83820_get_link_ksettings:
> drivers/net/ethernet/natsemi/ns83820.c:1210:11: warning: variable ‘tanar’ set 
> but not used [-Wunused-but-set-variable]
> 
> `tanar` is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.


Re: [PATCH] ipv6: route: convert comma to semicolon

2020-09-21 Thread David Miller
From: Xu Wang 
Date: Mon, 21 Sep 2020 06:38:56 +

> Replace a comma between expression statements by a semicolon.
> 
> Signed-off-by: Xu Wang 

Applied, thanks.


Re: [PATCH] net: unix: remove redundant assignment to variable 'err'

2020-09-21 Thread David Miller
From: Jing Xiangfeng 
Date: Mon, 21 Sep 2020 11:29:52 +0800

> After commit 37ab4fa7844a ("net: unix: allow bind to fail on mutex lock"),
> the assignment to err is redundant. So remove it.
> 
> Signed-off-by: Jing Xiangfeng 
 ...
> @@ -878,7 +878,6 @@ static int unix_autobind(struct socket *sock)
>   if (err)
>   return err;
>  
> - err = 0;
>   if (u->addr)
>   goto out;

Yes, err is always zero here in this code path.

Applied, thanks.


Re: [PATCH v2 net-next] net: phy: realtek: enable ALDPS to save power for RTL8211F

2020-09-21 Thread David Miller
From: Jisheng Zhang 
Date: Mon, 21 Sep 2020 09:13:54 +0800

> Enable ALDPS(Advanced Link Down Power Saving) to save power when
> link down.
> 
> Signed-off-by: Jisheng Zhang 
> ---
> Since v1:
>  - add what does ALDPS mean.
>  - replace magic number 0x18 with RTL8211F_PHYCR1 macro.

Applied, thanks.


Re: [PATCH v4 0/2] net: mdio-ipq4019: add Clause 45 support

2020-09-21 Thread David Miller
From: Robert Marko 
Date: Sun, 20 Sep 2020 16:16:51 +0200

> This patch series adds support for Clause 45 to the driver.
> 
> While at it also change some defines to upper case to match rest of the 
> driver.
> 
> Changes since v1:
> * Drop clock patches, these need further investigation and
> no user for non default configuration has been found

Please respin, in the net-next tree the MDIO drivers have been moved
into their own directory.


Re: [PATCH -next] chelsio: simplify the return expression of t3_ael2020_phy_prep()

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:05 +0800

> Simplify the return expression.
> 
> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH -next] connector: simplify the return expression of cn_add_callback()

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:06 +0800

> Simplify the return expression.
> 
> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH -next] enetc: simplify the return expression of enetc_vf_set_mac_addr()

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:26 +0800

> Simplify the return expression.
> 
> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH -next] ice: simplify the return expression of ice_finalize_update()

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:34 +0800

> Simplify the return expression.
> 
> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH -next] mlxsw: spectrum_router: simplify the return expression of __mlxsw_sp_router_init()

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:41 +0800

> Simplify the return expression.
> 
> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH -next] net: hns3: simplify the return expression of hclgevf_client_start()

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:43 +0800

> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH -next] net: qlcnic: simplify the return expression of qlcnic_83xx_shutdown

2020-09-21 Thread David Miller
From: Qinglang Miao 
Date: Mon, 21 Sep 2020 21:10:46 +0800

> Simplify the return expression.
> 
> Signed-off-by: Qinglang Miao 

Applied.


Re: [PATCH 03/14] dpaa2-eth: drop double zeroing

2020-09-20 Thread David Miller
From: Julia Lawall 
Date: Sun, 20 Sep 2020 13:26:15 +0200

> sg_init_table zeroes its first argument, so the allocation of that argument
> doesn't have to.
> 
> the semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> expression x,n,flags;
> @@
> 
> x = 
> - kcalloc
> + kmalloc_array
>   (n,sizeof(struct scatterlist),flags)
> ...
> sg_init_table(x,n)
> // 
> 
> Signed-off-by: Julia Lawall 

Applied.


Re: [PATCH 07/14] RDS: drop double zeroing

2020-09-20 Thread David Miller
From: Julia Lawall 
Date: Sun, 20 Sep 2020 13:26:19 +0200

> sg_init_table zeroes its first argument, so the allocation of that argument
> doesn't have to.
> 
> the semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> expression x,n,flags;
> @@
> 
> x = 
> - kcalloc
> + kmalloc_array
>   (n,sizeof(*x),flags)
> ...
> sg_init_table(x,n)
> // 
> 
> Signed-off-by: Julia Lawall 

Applied.


Re: [PATCH] net: phy: realtek: Replace 2.5Gbps name from RTL8125 to RTL8226

2020-09-20 Thread David Miller
From: 劉偉權 
Date: Mon, 21 Sep 2020 01:55:23 +

> Hi Andrew,
> Thanks...understood...

This is a top-post.  Andrew said to not top-post, and you said
you understand this.

If you understand it, please stop top-posting.

Thank you.



Re: [PATCH net-next] net: remove unnecessary NULL checking in napi_consume_skb()

2020-09-20 Thread David Miller
From: Yunsheng Lin 
Date: Sat, 19 Sep 2020 10:24:47 +0800

> When budget is non-zero, skb_unref() has already handled the
> NULL checking.
> 
> When budget is zero, the dev_consume_skb_any() has handled NULL
> checking in __dev_kfree_skb_irq(), or dev_kfree_skb() which also
> ultimately call skb_unref().
> 
> So remove the unnecessary checking in napi_consume_skb().
> 
> Signed-off-by: Yunsheng Lin 

Applied.


Re: [PATCH net-next] net: mventa: remove unused variable 'dummy' in mvneta_mib_counters_clear()

2020-09-20 Thread David Miller
From: Zhang Changzhong 
Date: Sat, 19 Sep 2020 10:26:51 +0800

> Fixes the following W=1 kernel build warning(s):
> 
> drivers/net/ethernet/marvell/mvneta.c:754:6: warning:
>  variable 'dummy' set but not used [-Wunused-but-set-variable]
>   754 |  u32 dummy;
>   |  ^
> 
> This variable is not used in function mvneta_mib_counters_clear(), so
> remove it to avoid build warning.
> 
> Signed-off-by: Zhang Changzhong 

Applied.


Re: [PATCH] rhashtable: fix indentation of a continue statement

2020-09-20 Thread David Miller
From: Colin King 
Date: Fri, 18 Sep 2020 22:51:26 +0100

> From: Colin Ian King 
> 
> A continue statement is indented incorrectly, add in the missing
> tab.
> 
> Signed-off-by: Colin Ian King 

Applied.


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

2020-09-19 Thread David Miller
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
> Broadcomm PHYs to properly advertise the correct mode for Fiber 100Mbps.
> 
> Corresponding user land ethtool patches are available but rely on these 
> patches
> to be applied first.

Series applied, thank you.


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

2020-09-19 Thread David Miller
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 de Bruijn 
> Signed-off-by: Xie He 

Applied.


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

2020-09-19 Thread David Miller
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: neterion: Remove set but not used variable

2020-09-19 Thread David Miller
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,
>   _reg->vpath_general_int_mask);
>  
> - val64 = VXGE_HW_TIM_CLR_INT_EN_VP(1 << (16 - vpath->vp_id));
> + VXGE_HW_TIM_CLR_INT_EN_VP(1 << (16 - vpath->vp_id));

This makes no sense, this macro is calculating an integer value.

This looks like a mechanical change made without considering what
the code is actually doing or should be doing.


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

2020-09-19 Thread David Miller
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]
> 
> drivers/net/ethernet/micrel/ksz884x.c: In function netdev_get_ethtool_stats:
> drivers/net/ethernet/micrel/ksz884x.c:6512:6: warning: variable ‘rc’ set but 
> not used [-Wunused-but-set-variable]
> 
> these variable is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.


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

2020-09-19 Thread David Miller
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 not used [-Wunused-but-set-variable]
> 
> drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 
> lio_pci_writeq:
> drivers/net/ethernet/cavium/liquidio/octeon_device.c:1358:6: warning: 
> variable ‘val32’ set but not used [-Wunused-but-set-variable]
> 
> these variable is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.


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

2020-09-19 Thread David Miller
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 [-Wunused-but-set-variable]
> 
> `ret_val` is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.


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

2020-09-19 Thread David Miller
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 [-Wunused-but-set-variable]
> 
> `retval` is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

This change is already in the net-next GIT tree.


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

2020-09-19 Thread David Miller
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: natsemi: Remove set but not used variable

2020-09-19 Thread David Miller
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);
>   tbicr = readl(dev->base + TBICR);
> + readl(dev->base + TANAR);
>  

Please do not change the order of the readl() operations, it might
matter.


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

2020-09-19 Thread David Miller
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 [-Wunused-but-set-variable]
> 
> `ret` is set but not used, so check it's value.

Subject is still wrong, please fix this and take your time doing
so.

Thanks.


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

2020-09-19 Thread David Miller
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);
>  
> - return 0;
> + return ret;
>  }

In fact, you are making it get used properly.

Please fix your commit message.


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

2020-09-18 Thread David Miller
From: Xiaoyong Yan 
Date: Fri, 18 Sep 2020 01:42:52 -0700

> + delay = delay_from_credits(q->credits, q->idleslope);
> + cbs_timer_schedule(q, now+ delay);
> + q->last = now;

This indentation cannot be correct.

Please fix this.


Re: [PATCH net-next v3 0/7] net: ipa: wake up system on RX available

2020-09-18 Thread David Miller
From: Alex Elder 
Date: Thu, 17 Sep 2020 12:39:19 -0500

> This series arranges for the IPA driver to wake up a suspended
> system if the IPA hardware has a packet to deliver to the AP.
> 
> Version 2 replaced the first patch from version 1 with three
> patches, in response to David Miller's feedback.  And based on
> Bjorn Andersson's feedback on version 2, this version reworks
> the tracking of IPA clock references.  As a result, we no
> longer need a flag to determine whether a "don't' suspend" clock
> reference is held (though an bit in a bitmask is still used for
> a different purpose).
 ...

Series applied, thanks.


Re: [PATCH] net: ipv6: fix kconfig dependency warning for IPV6_SEG6_HMAC

2020-09-18 Thread David Miller
From: Necip Fazil Yildiran 
Date: Thu, 17 Sep 2020 19:46:43 +0300

> When IPV6_SEG6_HMAC is enabled and CRYPTO is disabled, it results in the
> following Kbuild warning:
> 
> WARNING: unmet direct dependencies detected for CRYPTO_HMAC
>   Depends on [n]: CRYPTO [=n]
>   Selected by [y]:
>   - IPV6_SEG6_HMAC [=y] && NET [=y] && INET [=y] && IPV6 [=y]
> 
> WARNING: unmet direct dependencies detected for CRYPTO_SHA1
>   Depends on [n]: CRYPTO [=n]
>   Selected by [y]:
>   - IPV6_SEG6_HMAC [=y] && NET [=y] && INET [=y] && IPV6 [=y]
> 
> WARNING: unmet direct dependencies detected for CRYPTO_SHA256
>   Depends on [n]: CRYPTO [=n]
>   Selected by [y]:
>   - IPV6_SEG6_HMAC [=y] && NET [=y] && INET [=y] && IPV6 [=y]
> 
> The reason is that IPV6_SEG6_HMAC selects CRYPTO_HMAC, CRYPTO_SHA1, and
> CRYPTO_SHA256 without depending on or selecting CRYPTO while those configs
> are subordinate to CRYPTO.
> 
> Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
> 
> Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
> Signed-off-by: Necip Fazil Yildiran 

Applied and queued up for -stable, thank you.


Re: [PATCH net-next v2] net: phy: bcm7xxx: request and manage GPHY clock

2020-09-18 Thread David Miller
From: Florian Fainelli 
Date: Wed, 16 Sep 2020 19:04:13 -0700

> The internal Gigabit PHY on Broadcom STB chips has a digital clock which
> drives its MDIO interface among other things, the driver now requests
> and manage that clock during .probe() and .remove() accordingly.
> 
> Because the PHY driver can be probed with the clocks turned off we need
> to apply the dummy BMSR workaround during the driver probe function to
> ensure subsequent MDIO read or write towards the PHY will succeed.
> 
> Signed-off-by: Florian Fainelli 
> ---
> Changes in v2:
> 
> - localize the changes exclusively within the PHY driver and do not
>   involve the MDIO driver at all. Using the ethernet-phyid.
>   compatible string we can get straight to the desired driver without
>   requiring clocks to be assumed on.

Applied and queued up for -stable, thanks.


Re: [PATCH v6 0/3] Add 802.1AD protocol support for dsa switch and ocelot driver

2020-09-18 Thread David Miller
From: hongbo.w...@nxp.com
Date: Wed, 16 Sep 2020 17:48:42 +0800

> 1. Overview 
> a) 0001* is for support to set dsa slave into 802.1AD(QinQ) mode.
> b) 0002* is for vlan_proto support for br_switchdev_port_vlan_add and 
> br_switchdev_port_vlan_del.
> c) 0003* is for setting QinQ related registers in ocelot switch driver, after 
> applying this patch, the switch(VSC99599)'s port can enable or disable QinQ 
> mode.

You're going to have to update every single SWITCHDEV_PORT_ADD_OBJ handler
and subsequent helpers to check the validate the protocol value.

You also are going to have to make sure that every instantiated
switchdev_obj_port_vlan object initializes the vlan protocol field
properly.

Basically, now that this structure has a new member, everything that
operates on that object must be updated to handle the new protocol
value.

And I do mean everything.

You can't just add the protocol handling to the locations you care
about for bridging and DSA.

You also have to more fully address the feedback given by Vladimir
in patch #3.  Are the expectations on the user side a Linux based
expectation, or one specific about how this ASIC is expected to
behave by default.  It is very unclear what you are talking about
when you say customer and ISP etc.

Thanks.


Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

2020-09-18 Thread David Miller
From: Saeed Mahameed 
Date: Fri, 18 Sep 2020 10:58:49 -0700

> On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
>> @@ -158,7 +158,7 @@ static void linkwatch_do_dev(struct net_device
>> *dev)
>>  clear_bit(__LINK_STATE_LINKWATCH_PENDING, >state);
>>  
>>  rfc2863_policy(dev);
>> -if (dev->flags & IFF_UP && netif_device_present(dev)) {
>> +if (dev->flags & IFF_UP) {
> 
> So with your issue the devices is both IFF_UP and !present ? how so ?
> I think you should look into that.
> 
> I am ok with removing the "dev present" check from here just because we
> shouldn't  be expecting IFF_UP && !present .. such thing must be a bug
> somewhere else.

Indeed, this is why I just asked in another email why a link change event
is firing for a device which hasn't fully resumed and marked itself as
"present" yet.

More and more I think this is a driver or PHY layer bug.


Re: [PATCH net-next] net: tipc: Supply missing udp_media.h include file

2020-09-18 Thread David Miller
From: Wang Hai 
Date: Fri, 18 Sep 2020 21:18:19 +0800

> If the header file containing a function's prototype isn't included by
> the sourcefile containing the associated function, the build system
> complains of missing prototypes.
> 
> Fixes the following W=1 kernel build warning(s):
> 
> net/tipc/udp_media.c:446:5: warning: no previous prototype for 
> ‘tipc_udp_nl_dump_remoteip’ [-Wmissing-prototypes]
> net/tipc/udp_media.c:532:5: warning: no previous prototype for 
> ‘tipc_udp_nl_add_bearer_data’ [-Wmissing-prototypes]
> net/tipc/udp_media.c:614:5: warning: no previous prototype for 
> ‘tipc_udp_nl_bearer_add’ [-Wmissing-prototypes]
> 
> Signed-off-by: Wang Hai 

Applied.


Re: [PATCH net-next] tipc: Remove unused macro CF_SERVER

2020-09-18 Thread David Miller
From: YueHaibing 
Date: Fri, 18 Sep 2020 21:16:15 +0800

> It is no used any more, so can remove it.
> 
> Signed-off-by: YueHaibing 

Applied.


Re: [PATCH net-next] net: hns3: Supply missing hclge_dcb.h include file

2020-09-18 Thread David Miller
From: Wang Hai 
Date: Fri, 18 Sep 2020 21:06:53 +0800

> If the header file containing a function's prototype isn't included by
> the sourcefile containing the associated function, the build system
> complains of missing prototypes.
> 
> Fixes the following W=1 kernel build warning(s):
> 
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c:453:6: warning: no 
> previous prototype for ‘hclge_dcb_ops_set’ [-Wmissing-prototypes]
> 
> Signed-off-by: Wang Hai 

Applied.


Re: [PATCH net-next] net/appletalk: Supply missing net/Space.h include file

2020-09-18 Thread David Miller
From: Wang Hai 
Date: Fri, 18 Sep 2020 20:55:51 +0800

> If the header file containing a function's prototype isn't included by
> the sourcefile containing the associated function, the build system
> complains of missing prototypes.
> 
> Fixes the following W=1 kernel build warning(s):
> 
> drivers/net/appletalk/cops.c:213:28: warning: no previous prototype for 
> ‘cops_probe’ [-Wmissing-prototypes]
> drivers/net/appletalk/ltpc.c:1014:28: warning: no previous prototype for 
> ‘ltpc_probe’ [-Wmissing-prototypes]
> 
> Signed-off-by: Wang Hai 

Applied.


Re: [PATCH net-next] liquidio: Fix -Wmissing-prototypes warnings for liquidio

2020-09-18 Thread David Miller
From: Wang Hai 
Date: Fri, 18 Sep 2020 21:02:10 +0800

> If the header file containing a function's prototype isn't included by
> the sourcefile containing the associated function, the build system
> complains of missing prototypes.
> 
> Fixes the following W=1 kernel build warning(s):
> 
> drivers/net/ethernet/cavium/liquidio/cn68xx_device.c:124:5: warning: no 
> previous prototype for ‘lio_setup_cn68xx_octeon_device’ [-Wmissing-prototypes]
> drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:159:1: warning: no 
> previous prototype for ‘octeon_pci_read_core_mem’ [-Wmissing-prototypes]
> drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:168:1: warning: no 
> previous prototype for ‘octeon_pci_write_core_mem’ [-Wmissing-prototypes]
> drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:176:5: warning: no 
> previous prototype for ‘octeon_read_device_mem64’ [-Wmissing-prototypes]
> drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:185:5: warning: no 
> previous prototype for ‘octeon_read_device_mem32’ [-Wmissing-prototypes]
> drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:194:6: warning: no 
> previous prototype for ‘octeon_write_device_mem32’ [-Wmissing-prototypes]
> 
> Signed-off-by: Wang Hai 

Applied.


Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

2020-09-18 Thread David Miller
From: Nikolay Aleksandrov 
Date: Fri, 18 Sep 2020 12:35:02 +

> Thanks for the analysis, I don't see any issues with checking if the device
> isn't present. It will have to go through some testing, but no obvious
> objections/issues. Have you tried if it fixes your case?
> I have briefly gone over drivers' use of net_device_detach(), mostly it's used
> for suspends, but there are a few cases which use it on IO error or when a
> device is actually detaching (VF detach). The vlan port event is for vlan
> devices on top of the bridge when BROPT_VLAN_BRIDGE_BINDING is enabled and 
> their
> carrier is changed based on vlan participating ports' state.

There are two things to resolve:

1) Why does the bridge need to get a change event for devices which have
   not fully resumed yet?

2) What kind of link state change is happening on devices which are not
   currently fully resumed yet?

Really this whole situation is still quite mysterious to me.

If the driver (or the PHY library it is using, etc.) is emitting link
state changes before it marks itself as "present", that's the real
bug.


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

2020-09-18 Thread David Miller
From: Zheng Yongjun 
Date: Fri, 18 Sep 2020 16:49:51 +0800

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/cortina/gemini.c: In function gmac_get_ringparam:
> drivers/net/ethernet/cortina/gemini.c:2125:21: warning: variable ‘config0’ 
> set but not used [-Wunused-but-set-variable]
> 
> drivers/net/ethernet/cortina/gemini.c: In function gmac_init:
> drivers/net/ethernet/cortina/gemini.c:512:6: warning: variable ‘val’ set but 
> not used [-Wunused-but-set-variable]
> 
> these variable is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

Applied.


Re: [PATCH net-next] hinic: modify irq name

2020-09-18 Thread David Miller
From: Luo bin 
Date: Fri, 18 Sep 2020 17:23:22 +0800

> Make a distinction between different irqs by netdev name or pci name.
> 
> Signed-off-by: Luo bin 

Applied.


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

2020-09-18 Thread David Miller
From: Zheng Yongjun 
Date: Fri, 18 Sep 2020 16:39:38 +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 not used [-Wunused-but-set-variable]
> 
> drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 
> lio_pci_writeq:
> drivers/net/ethernet/cavium/liquidio/octeon_device.c:1358:6: warning: 
> variable ‘val32’ set but not used [-Wunused-but-set-variable]
> 
> these variable is never used, so remove it.
> 
> Signed-off-by: Zheng Yongjun 

The proper subsystem prefix for these changes is just "liquidio: ".

For changes to a specific driver it is not appropriate to use
"net: ethernet: " or similar.

Please fix up your Subject line and resubmit.

Thank you.


Re: [PATCH] net: openswitch: reuse the helper variable to improve the code readablity

2020-09-18 Thread David Miller
From: Zeng Tao 
Date: Fri, 18 Sep 2020 15:14:30 +0800

> In the function ovs_ct_limit_exit, there is already a helper vaibale
> which could be reused to improve the readability, so i fix it in this
> patch.
> 
> Signed-off-by: Zeng Tao 

Applied, thanks.


Re: [PATCH v2] ptp: mark symbols static where possible

2020-09-18 Thread David Miller
From: Herrington 
Date: Fri, 18 Sep 2020 14:10:13 +0800

> +void pch_ch_control_write(struct pci_dev *pdev, u32 val);
>  void pch_ch_control_write(struct pci_dev *pdev, u32 val)

Prototypes belong in a header file not in the C file where they
are defined.

If these functions are accessed in other foo.c files, they are
getting the prototype from some header file.

Otherwise they aren't, and the functions should be marked
static.


Re: [PATCH net] hinic: fix sending pkts from core while self testing

2020-09-18 Thread David Miller
From: Luo bin 
Date: Fri, 18 Sep 2020 12:09:38 +0800

> Call netif_tx_disable firstly before starting doing self-test to
> avoid sending packet from networking core and self-test packet
> simultaneously which may cause self-test failure or hw abnormal.
> 
> Fixes: 4aa218a4fe77 ("hinic: add self test support")
> Signed-off-by: Luo bin 

Applied.


Re: [PATCH v4] net: use exponential backoff in netdev_wait_allrefs

2020-09-18 Thread David Miller
From: frugg...@arista.com (Francesco Ruggeri)
Date: Fri, 18 Sep 2020 13:19:01 -0700

> The combination of aca_free_rcu, introduced in commit 2384d02520ff
> ("net/ipv6: Add anycast addresses to a global hashtable"), and
> fib6_info_destroy_rcu, introduced in commit 9b0a8da8c4c6 ("net/ipv6:
> respect rcu grace period before freeing fib6_info"), can result in
> an extra rcu grace period being needed when deleting an interface,
> with the result that netdev_wait_allrefs ends up hitting the msleep(250),
> which is considerably longer than the required grace period.
> This can result in long delays when deleting a large number of interfaces,
> and it can be observed with this script:
  ...
> Time with this patch on a 5.4 kernel:
> 
> real  0m7.704s
> user  0m0.385s
> sys   0m1.230s
> 
> Time without this patch:
> 
> real0m31.522s
> user0m0.438s
> sys 0m1.156s
> 
> v2: use exponential backoff instead of trying to wake up
> netdev_wait_allrefs.
> v3: preserve reverse christmas tree ordering of local variables
> v4: try an extra rcu_barrier before the backoff, plus some
> cosmetic changes.
> 
> Signed-off-by: Francesco Ruggeri 

Applied to net-next, thanks.


Re: [PATCH -next v2] net: hsr: Convert to DEFINE_SHOW_ATTRIBUTE

2020-09-17 Thread David Miller
From: Qinglang Miao 
Date: Thu, 17 Sep 2020 20:45:07 +0800

> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Qinglang Miao 
> ---
> v2: based on linux-next(20200917), and can be applied to
> mainline cleanly now.

Applied.


Re: [PATCH -next v2] dpaa2-eth: Convert to DEFINE_SHOW_ATTRIBUTE

2020-09-17 Thread David Miller
From: Qinglang Miao 
Date: Thu, 17 Sep 2020 20:45:08 +0800

> Signed-off-by: Qinglang Miao 
> ---
> v2: based on linux-next(20200917), and can be applied to
> mainline cleanly now.

Applied.


Re: [PATCH net v2] hinic: fix potential resource leak

2020-09-17 Thread David Miller
From: Wei Li 
Date: Thu, 17 Sep 2020 20:29:50 +0800

> In rx_request_irq(), it will just return what irq_set_affinity_hint()
> returns. If it is failed, the napi and irq requested are not freed
> properly. So add exits for failures to handle these.
> 
> Signed-off-by: Wei Li 
> ---
> v1 -> v2:
>  - Free irq as well when irq_set_affinity_hint() fails.

Applied, thank you.


Re: [PATCH v2 net-next] netdev: Remove unused functions

2020-09-17 Thread David Miller
From: YueHaibing 
Date: Thu, 17 Sep 2020 10:19:10 +0800

> There is no callers in tree, so can remove it.
> 
> Signed-off-by: YueHaibing 
> Reviewed-by: Saeed Mahameed 
> ---
> v2: fix title typo 'funtions' --> 'functions'

Applied, thank you.


Re: [PATCH net] ethtool: add and use message type for tunnel info reply

2020-09-17 Thread David Miller
From: Michal Kubecek 
Date: Thu, 17 Sep 2020 01:04:10 +0200 (CEST)

> Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd
> field in genetlink header) for replies to tunnel info netlink request, i.e.
> the same value as the request have. This is a problem because we are using
> two separate enums for userspace to kernel and kernel to userspace message
> types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with
> ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for
> kernel to userspace messages.
> 
> As the tunnel info request reached mainline in 5.9 merge window, we should
> still be able to fix the reply message type without breaking backward
> compatibility.
> 
> Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface")
> Signed-off-by: Michal Kubecek 

Applied, thank you.


Re: [PATCH net] drivers/net/wan/hdlc: Set skb->protocol before transmitting

2020-09-17 Thread David Miller
From: Xie He 
Date: Wed, 16 Sep 2020 14:25:07 -0700

> This patch sets skb->protocol before transmitting frames on the HDLC
> device, so that a user listening on the HDLC device with an AF_PACKET
> socket will see outgoing frames' sll_protocol field correctly set and
> consistent with that of incoming frames.
> 
> 1. Control frames in hdlc_cisco and hdlc_ppp
> 
> When these drivers send control frames, skb->protocol is not set.
> 
> This value should be set to htons(ETH_P_HDLC), because when receiving
> control frames, their skb->protocol is set to htons(ETH_P_HDLC).
> 
> When receiving, hdlc_type_trans in hdlc.h is called, which then calls
> cisco_type_trans or ppp_type_trans. The skb->protocol of control frames
> is set to htons(ETH_P_HDLC) so that the control frames can be received
> by hdlc_rcv in hdlc.c, which calls cisco_rx or ppp_rx to process the
> control frames.
> 
> 2. hdlc_fr
> 
> When this driver sends control frames, skb->protocol is set to internal
> values used in this driver.
> 
> When this driver sends data frames (from upper stacked PVC devices),
> skb->protocol is the same as that of the user data packet being sent on
> the upper PVC device (for normal PVC devices), or is htons(ETH_P_802_3)
> (for Ethernet-emulating PVC devices).
> 
> However, skb->protocol for both control frames and data frames should be
> set to htons(ETH_P_HDLC), because when receiving, all frames received on
> the HDLC device will have their skb->protocol set to htons(ETH_P_HDLC).
> 
> When receiving, hdlc_type_trans in hdlc.h is called, and because this
> driver doesn't provide a type_trans function in struct hdlc_proto,
> all frames will have their skb->protocol set to htons(ETH_P_HDLC).
> The frames are then received by hdlc_rcv in hdlc.c, which calls fr_rx
> to process the frames (control frames are consumed and data frames
> are re-received on upper PVC devices).
> 
> Cc: Krzysztof Halasa 
> Signed-off-by: Xie He 

Applied, thank you.


Re: [PATCH net] drivers/net/wan/lapbether: Make skb->protocol consistent with the header

2020-09-17 Thread David Miller
From: Xie He 
Date: Wed, 16 Sep 2020 09:49:18 -0700

> This driver is a virtual driver stacked on top of Ethernet interfaces.
> 
> When this driver transmits data on the Ethernet device, the skb->protocol
> setting is inconsistent with the Ethernet header prepended to the skb.
> 
> This causes a user listening on the Ethernet interface with an AF_PACKET
> socket, to see different sll_protocol values for incoming and outgoing
> frames, because incoming frames would have this value set by parsing the
> Ethernet header.
> 
> This patch changes the skb->protocol value for outgoing Ethernet frames,
> making it consistent with the Ethernet header prepended. This makes a
> user listening on the Ethernet device with an AF_PACKET socket, to see
> the same sll_protocol value for incoming and outgoing frames.
> 
> Cc: Martin Schiller 
> Signed-off-by: Xie He 

Applied, thank you.


Re: [PATCH net-next v9 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX3255 (AC3x)

2020-09-17 Thread David Miller
From: Vadym Kochan 
Date: Wed, 16 Sep 2020 19:30:56 +0300

> Marvell Prestera 98DX3255 integrates up to 24 ports of 1GbE with 8
> ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> wireless SMB deployment.
> 
> Prestera Switchdev is a firmware based driver that operates via PCI bus.  The
> current implementation supports only boards designed for the Marvell Switchdev
> solution and requires special firmware.
> 
> This driver implementation includes only L1, basic L2 support, and RX/TX.
 ...

Series applied, thank you.


Re: [PATCH net-next] net/sched: Remove unused function qdisc_queue_drop_head()

2020-09-17 Thread David Miller
From: YueHaibing 
Date: Wed, 16 Sep 2020 22:16:29 +0800

> It is not used since commit a09ceb0e0814 ("sched: remove qdisc->drop")
> 
> Signed-off-by: YueHaibing 

Applied.


Re: [PATCH net-next] genetlink: Remove unused function genl_err_attr()

2020-09-17 Thread David Miller
From: YueHaibing 
Date: Wed, 16 Sep 2020 22:17:28 +0800

> It is never used, so can remove it.
> 
> Signed-off-by: YueHaibing 

Applied.


Re: [PATCH net-next] selftests: mptcp: interpret \n as a new line

2020-09-17 Thread David Miller
From: Matthieu Baerts 
Date: Wed, 16 Sep 2020 15:13:51 +0200

> In case of errors, this message was printed:
> 
>   (...)
>   # read: Resource temporarily unavailable
>   #  client exit code 0, server 3
>   # \nnetns ns1-0-BJlt5D socket stat for 10003:
>   (...)
> 
> Obviously, the idea was to add a new line before the socket stat and not
> print "\nnetns".
> 
> Fixes: b08fbf241064 ("selftests: add test-cases for MPTCP MP_JOIN")
> Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
> Signed-off-by: Matthieu Baerts 

Applied.


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

2020-09-17 Thread David Miller
From: Xie He 
Date: Wed, 16 Sep 2020 05:23:08 -0700

> 1. Change all "dev->hard_header" to "dev->header_ops"
> 
> 2. On receiving incoming frames when header_ops == NULL:
> 
> The comment only says what is wrong, but doesn't say what is right.
> This patch changes the comment to make it clear what is right.
> 
> 3. On transmitting and receiving outgoing frames when header_ops == NULL:
> 
> The comment explains that the LL header will be later added by the driver.
> 
> However, I think it's better to simply say that the LL header is invisible
> to us. This phrasing is better from a software engineering perspective,
> because this makes it clear that what happens in the driver should be
> hidden from us and we should not care about what happens internally in the
> driver.
> 
> 4. On resuming the LL header (for RAW frames) when header_ops == NULL:
> 
> The comment says we are "unlikely" to restore the LL header.
> 
> However, we should say that we are "unable" to restore it.
> It's not possible (rather than not likely) to restore it, because:
> 
> 1) There is no way for us to restore because the LL header internally
> processed by the driver should be invisible to us.
> 
> 2) In function packet_rcv and tpacket_rcv, the code only tries to restore
> the LL header when header_ops != NULL.
> 
> Cc: Willem de Bruijn 
> Signed-off-by: Xie He 

Applied, thank you.


Re: [PATCH v3] hv_netvsc: Add validation for untrusted Hyper-V values

2020-09-17 Thread David Miller
From: "Andrea Parri (Microsoft)" 
Date: Wed, 16 Sep 2020 11:47:27 +0200

> From: Andres Beltran 
> 
> For additional robustness in the face of Hyper-V errors or malicious
> behavior, validate all values that originate from packets that Hyper-V
> has sent to the guest in the host-to-guest ring buffer. Ensure that
> invalid values cannot cause indexing off the end of an array, or
> subvert an existing validation via integer overflow. Ensure that
> outgoing packets do not have any leftover guest memory that has not
> been zeroed out.
> 
> Signed-off-by: Andres Beltran 
> Co-developed-by: Andrea Parri (Microsoft) 
> Signed-off-by: Andrea Parri (Microsoft) 

Applied, thank you.


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

2020-09-17 Thread David Miller
From: Huazhong Tan 
Date: Wed, 16 Sep 2020 17:33:44 +0800

> There are some optimizations related to IO path.
> 
> Change since V1:
> - fixes a unsuitable handling in hns3_lb_clear_tx_ring() of #6 which
>   pointed out by Saeed Mahameed.
> 
> previous version:
> V1: 
> https://patchwork.ozlabs.org/project/netdev/cover/1600085217-26245-1-git-send-email-tanhuazh...@huawei.com/

Series applied, thank you.


Re: [PATCH v2] net: use exponential backoff in netdev_wait_allrefs

2020-09-17 Thread David Miller
From: frugg...@arista.com (Francesco Ruggeri)
Date: Thu, 17 Sep 2020 15:19:22 -0700

>  static void netdev_wait_allrefs(struct net_device *dev)
>  {
>   unsigned long rebroadcast_time, warning_time;
>   int refcnt;
> + unsigned int wait = MIN_MSLEEP;

Please preserve the reverse christmas tree ordering of local
variables here, thank you.


Re: [PATCH -next] ide: Fix symbol undeclared warnings

2020-09-17 Thread David Miller
From: Michael Ellerman 
Date: Thu, 17 Sep 2020 22:01:00 +1000

> Wang Wensheng  writes:
>> Build the object file with `C=2` and get the following warnings:
>> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
>> make C=2 drivers/ide/pmac.o ARCH=powerpc64
>> CROSS_COMPILE=powerpc64-linux-gnu-
>>
>> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not
>> declared. Should it be static?
>>
>> Signed-off-by: Wang Wensheng 
>> ---
>>  drivers/ide/pmac.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> TIL davem maintains IDE?
> 
> But I suspect he isn't that interested in this powerpc only driver, so
> I'll grab this.

I did have it in my queue, but if you want to take it that's fine too :)


Re: [PATCH -next] cxgb4vf: convert to use DEFINE_SEQ_ATTRIBUTE macro

2020-09-16 Thread David Miller
From: Liu Shixin 
Date: Wed, 16 Sep 2020 10:50:18 +0800

> Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Liu Shixin 

Looks good, applied to net-next, thanks.


Re: [PATCH net] net: dsa: microchip: ksz8795: really set the correct number of ports

2020-09-16 Thread David Miller
From: Matthias Schiffer 
Date: Wed, 16 Sep 2020 12:08:39 +0200

> The KSZ9477 and KSZ8795 use the port_cnt field differently: For the
> KSZ9477, it includes the CPU port(s), while for the KSZ8795, it doesn't.
> 
> It would be a good cleanup to make the handling of both drivers match,
> but as a first step, fix the recently broken assignment of num_ports in
> the KSZ8795 driver (which completely broke probing, as the CPU port
> index was always failing the num_ports check).
> 
> Fixes: af199a1a9cb0 ("net: dsa: microchip: set the correct number of
> ports")

Please do not a tag into multiple lines.  Especially do not do this
with Fixes tags as people will do string matching on it.

> Signed-off-by: Matthias Schiffer 

Applied and queued up for -stable.

Thanks.


Re: [PATCH net-next] net: stmmac: Add support to Ethtool get/set ring parameters

2020-09-16 Thread David Miller
From: Wong Vee Khee 
Date: Wed, 16 Sep 2020 15:40:20 +0800

> +int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size)
> +{
> + struct stmmac_priv *priv = netdev_priv(dev);
> + int ret = 0;
> +
> + if (netif_running(dev))
> + stmmac_release(dev);
 ...
> + if (netif_running(dev))
> + ret = stmmac_open(dev);
> +

I've applied this patch but this approach is so fragile, but everyone
does it initially because it is so easy.

The problem here is that for so many reasons the stmmac_open() can
fail, and instead of just the ringparam() operation failing, the
interface becomes down and unusable.

Can you please eventually implement this properly?  Allocate the new
ring resources, and only commit the new configuration if it is
guaranteed to succeed.  Otherwise, backout the ringparam change
and keep the old configuration.

This way the device stays up regardless of whether the resources
(memory, DMA mappings, etc.) can be allocated fully.

Right now, if you do a ringparam under hard memory pressure, this will
take the inteface down as stmmac_open() fails.


Re: [PATCH] chelsio/chtls: Re-add dependencies on CHELSIO_T4 to fix modular CHELSIO_T4

2020-09-15 Thread David Miller
From: Geert Uytterhoeven 
Date: Tue, 15 Sep 2020 11:35:51 +0200

> As CHELSIO_INLINE_CRYPTO is bool, and CHELSIO_T4 is tristate, the
> dependency of CHELSIO_INLINE_CRYPTO on CHELSIO_T4 is not sufficient to
> protect CRYPTO_DEV_CHELSIO_TLS and CHELSIO_IPSEC_INLINE.  The latter two
> are also tristate, hence if CHELSIO_T4=n, they cannot be builtin, as
> that would lead to link failures like:
> 
> drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.c:259: 
> undefined reference to `cxgb4_port_viid'
> 
> and
> 
> drivers/net/ethernet/chelsio/inline_crypto/ch_ipsec/chcr_ipsec.c:752: 
> undefined reference to `cxgb4_reclaim_completed_tx'
> 
> Fix this by re-adding dependencies on CHELSIO_T4 to tristate symbols.
> The dependency of CHELSIO_INLINE_CRYPTO on CHELSIO_T4 is kept to avoid
> asking the user.
> 
> Fixes: 6bd860ac1c2a0ec2 ("chelsio/chtls: CHELSIO_INLINE_CRYPTO should depend 
> on CHELSIO_T4")
> Reported-by: kernel test robot 
> Signed-off-by: Geert Uytterhoeven 

Applied, thank you.


Re: [PATCH net-next v2 0/3] First bunch of Tulip cleanups

2020-09-15 Thread David Miller
From: Moritz Fischer 
Date: Mon, 14 Sep 2020 21:24:49 -0700

> This series is the first bunch of minor cleanups for the de2104x driver
> to make it look and behave more like a modern driver.
> 
> These changes replace some of the non-devres versions with devres
> versions of functions to simplify the error paths.
> 
> Next up after this will be the ioremap part.

I really don't consider a "conversion" over to devres for older drivers
a suitable cleanup.

There are no resource handling bugs you are fixing, the driver uses
the APIs it uses correctly, and the coding style is reasonable.

Therefore, I'm sorry I'm not applying these changes.


Re: [PATCH net-next 0/3] net: stmmac: Add ethtool support for get|set channels

2020-09-15 Thread David Miller
From: Wong Vee Khee 
Date: Tue, 15 Sep 2020 09:28:37 +0800

> This patch set is to add support for user to get or set Tx/Rx channel
> via ethtool. There are two patches that fixes bug introduced on upstream
> in order to have the feature work.
> 
> Tested on Intel Tigerlake Platform.

Series applied, thank you.


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

2020-09-15 Thread David Miller
From: Oded Gabbay 
Date: Wed, 16 Sep 2020 00:20:12 +0300

> I completely understand but you didn't answer my question. How come
> there are drivers which create netdev objects, and specifically sgi-xp
> in misc (but I also saw it in usb drivers) that live outside
> drivers/net ? Why doesn't your request apply to them as well ?

Don't use examples of drivers doing the wrong thing as an excuse for
you to repeat the mistake.

Ok?

That kind of argument doesn't work here.


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

2020-09-15 Thread David Miller
From: Andrew Lunn 
Date: Tue, 15 Sep 2020 23:37:35 +0200

>> I understand your point of view but If my H/W doesn't support the
>> basic requirements of the RDMA infrastructure and interfaces, then
>> really there is nothing I can do about it. I can't use them.
> 
> It is up to the RDMA people to say that. They might see how the RDMA
> core can be made to work for your hardware.

+1


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

2020-09-15 Thread David Miller
From: Oded Gabbay 
Date: Wed, 16 Sep 2020 00:43:00 +0300

> I honestly don't know and I admit we didn't look at the dates of when
> these drivers were introduced.

Please do research when you make claims in the future, thank you.


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

2020-09-15 Thread David Miller
From: Oded Gabbay 
Date: Tue, 15 Sep 2020 20:10:08 +0300

> This is the second version of the patch-set to upstream the GAUDI NIC code
> into the habanalabs driver.
> 
> The only modification from v2 is in the ethtool patch (patch 12). Details
> are in that patch's commit message.
> 
> Link to v2 cover letter:
> https://lkml.org/lkml/2020/9/12/201

I agree with Jakub, this driver definitely can't go-in as it is currently
structured and designed.  And because of the RDMA'ness of it, the RDMA
folks have to be CC:'d and have a chance to review this.


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

2020-09-15 Thread David Miller
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 


Re: [PATCH v2 3/4] sparc64: remove mm_cpumask clearing to fix kthread_use_mm race

2020-09-15 Thread David Miller
From: Nicholas Piggin 
Date: Tue, 15 Sep 2020 13:24:07 +1000

> Excerpts from David Miller's message of September 15, 2020 5:59 am:
>> From: Nicholas Piggin 
>> Date: Mon, 14 Sep 2020 14:52:18 +1000
>> 
>>  ...
>>> The basic fix for sparc64 is to remove its mm_cpumask clearing code. The
>>> optimisation could be effectively restored by sending IPIs to mm_cpumask
>>> members and having them remove themselves from mm_cpumask. This is more
>>> tricky so I leave it as an exercise for someone with a sparc64 SMP.
>>> powerpc has a (currently similarly broken) example.
>>> 
>>> Signed-off-by: Nicholas Piggin 
>> 
>> Sad to see this optimization go away, but what can I do:
>> 
>> Acked-by: David S. Miller 
>> 
> 
> Thanks Dave, any objection if we merge this via the powerpc tree
> to keep the commits together?

No objection.


Re: [PATCH] sbus: char: Remove meaningless jump label out_free

2020-09-14 Thread David Miller
From: Jing Xiangfeng 
Date: Fri, 11 Sep 2020 15:13:41 +0800

> After commit 57a4a3d7f756 ("display7seg: Introduce the use of the managed
> version of kzalloc"), The out_free jump label has nothing to do but goto
> out. So remove it.
> 
> Signed-off-by: Jing Xiangfeng 

Applied, thank you.


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