* [PATCH iproute2-rc 0/2] Control CQ adaptive moderation (RDMA DIM)
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This is supplementary part of RDMA DIM feature [1] accepted
for the kernel v5.3. In this patch set Yamin extends rdmatool
to get/set as a default this adaptive-moderation setting on
IB device level and provides an information about DIM on/off
status per-CQ.
Thanks
[1] https://lore.kernel.org/linux-rdma/20190708105905.27468-1-leon@kernel.org/
Yamin Friedman (2):
rdma: Control CQ adaptive moderation (DIM)
rdma: Document adaptive-moderation
man/man8/rdma-dev.8 | 16 ++++++++++++-
rdma/dev.c | 55 ++++++++++++++++++++++++++++++++++++++++++++-
rdma/rdma.h | 1 +
rdma/res-cq.c | 15 +++++++++++++
rdma/utils.c | 6 +++++
5 files changed, 91 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 7:41 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <4752bf67-7a0c-7bc9-3d54-f18361085ba2@gmail.com>
Mon, Jul 29, 2019 at 09:32:00AM CEST, baijiaju1990@gmail.com wrote:
>
>
>On 2019/7/29 14:56, Jiri Pirko wrote:
>> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>> > In dequeue_func(), there is an if statement on line 74 to check whether
>> > skb is NULL:
>> > if (skb)
>> >
>> > When skb is NULL, it is used on line 77:
>> > prefetch(&skb->end);
>> >
>> > Thus, a possible null-pointer dereference may occur.
>> >
>> > To fix this bug, skb->end is used when skb is not NULL.
>> >
>> > This bug is found by a static analysis tool STCheck written by us.
>> >
>> > Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>> Fixes tag, please?
>
>Sorry, I do not know what "fixes tag" means...
>I just find a possible bug and fix it in this patch.
git log |grep Fixes:
If A fix goes to -net tree, it most probably fixes some bug introduced
by some commit in the past. So this tag is to put a reference.
>
>
>Best wishes,
>Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 7:32 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729065653.GA2211@nanopsycho>
On 2019/7/29 14:56, Jiri Pirko wrote:
> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>> In dequeue_func(), there is an if statement on line 74 to check whether
>> skb is NULL:
>> if (skb)
>>
>> When skb is NULL, it is used on line 77:
>> prefetch(&skb->end);
>>
>> Thus, a possible null-pointer dereference may occur.
>>
>> To fix this bug, skb->end is used when skb is not NULL.
>>
>> This bug is found by a static analysis tool STCheck written by us.
>>
>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> Fixes tag, please?
Sorry, I do not know what "fixes tag" means...
I just find a possible bug and fix it in this patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: wenxu @ 2019-07-29 7:18 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <20190728214237.2c0687db@cakuba.netronome.com>
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
I think the nft is different with tc.
In tc case we can create vxlan device add a ingress qdisc with a block success
Then the ASIC driver loaded, then register the vxlan indr-dev and get the block
adn replay it to hardware
But in the nft case, The base chain flags with offload. Create an offload netdev
base chain on vxlan device will fail if there is no indr-device to offload.
^ permalink raw reply
* RE: [PATCH net-next v3 0/2] qed*: Support for NVM config attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-29 7:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Michal Kalderon, Ariel Elior
In-Reply-To: <20190727.191328.1351271863559760336.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Sunday, July 28, 2019 7:43 AM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>;
> Ariel Elior <aelior@marvell.com>
> Subject: Re: [PATCH net-next v3 0/2] qed*: Support for NVM config
> attributes.
>
> From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Date: Sat, 27 Jul 2019 18:55:47 -0700
>
> > The patch series adds support for managing the NVM config attributes.
> > Patch (1) adds functionality to update config attributes via MFW.
> > Patch (2) adds driver interface for updating the config attributes.
> >
> > Changes from previous versions:
> > -------------------------------
> > v3: Removed unused variable.
> > v2: Removed unused API.
> >
> > Please consider applying this series to "net-next".
>
> I don't see where an existing ethtool method hooks into and calls this new
> NVM code.
Dave,
The new API/functionality is invoked as part of ethtool flash (ethtool -f) implementation.
Example code path:
ethtool_ops-->flash_device--> qede_flash_device() --> qed_nvm_flash() --> qed_nvm_flash_cfg_write() --> qed_mcp_nvm_set_cfg()
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: wenxu @ 2019-07-29 7:05 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <20190728214237.2c0687db@cakuba.netronome.com>
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
So you mean the case is there are two card A and B both can offload vxlan.
First vxlan device offload with A. And then the B driver loaded, So the rules
should replay to B device?
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 6:56 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729022157.18090-1-baijiaju1990@gmail.com>
Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>In dequeue_func(), there is an if statement on line 74 to check whether
>skb is NULL:
> if (skb)
>
>When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
>Thus, a possible null-pointer dereference may occur.
>
>To fix this bug, skb->end is used when skb is not NULL.
>
>This bug is found by a static analysis tool STCheck written by us.
>
>Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Fixes tag, please?
>---
> net/sched/sch_codel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
>index 25ef172c23df..30169b3adbbb 100644
>--- a/net/sched/sch_codel.c
>+++ b/net/sched/sch_codel.c
>@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
> struct Qdisc *sch = ctx;
> struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
>
>- if (skb)
>+ if (skb) {
> sch->qstats.backlog -= qdisc_pkt_len(skb);
>-
>- prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ }
> return skb;
> }
>
>--
>2.17.0
>
^ permalink raw reply
* Re: [PATCH net-next] rt2800usb: Add new rt2800usb device PLANEX GW-USMicroN
From: Stanislaw Gruszka @ 2019-07-29 6:46 UTC (permalink / raw)
To: Masanari Iida
Cc: helmut.schaa, kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190728140742.3280-1-standby24x7@gmail.com>
On Sun, Jul 28, 2019 at 11:07:42PM +0900, Masanari Iida wrote:
> This patch add a device ID for PLANEX GW-USMicroN.
> Without this patch, I had to echo the device IDs in order to
> recognize the device.
>
> # lsusb |grep PLANEX
> Bus 002 Device 005: ID 2019:ed14 PLANEX GW-USMicroN
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
From: Ido Schimmel @ 2019-07-29 6:09 UTC (permalink / raw)
To: Allan W. Nielsen
Cc: Andrew Lunn, Horatiu Vultur, Nikolay Aleksandrov, roopa, davem,
bridge, netdev, linux-kernel
In-Reply-To: <20190728191558.zuopgfqza2iz5d5b@lx-anielsen.microsemi.net>
On Sun, Jul 28, 2019 at 09:15:59PM +0200, Allan W. Nielsen wrote:
> If we assume that the SwitchDev driver implemented such that all multicast
> traffic goes to the CPU, then we should really have a way to install a HW
> offload path in the silicon, such that these packets does not go to the CPU (as
> they are known not to be use full, and a frame every 3 us is a significant load
> on small DMA connections and CPU resources).
>
> If we assume that the SwitchDev driver implemented such that only "needed"
> multicast packets goes to the CPU, then we need a way to get these packets in
> case we want to implement the DLR protocol.
I'm not familiar with the HW you're working with, so the below might not
be relevant.
In case you don't want to send all multicast traffic to the CPU (I'll
refer to it later), you can install an ingress tc filter that traps to
the CPU the packets you do want to receive. Something like:
# tc qdisc add dev swp1 clsact
# tc filter add dev swp1 pref 1 ingress flower skip_sw dst_mac \
01:21:6C:00:00:01 action trap
If your HW supports sharing the same filter among multiple ports, then
you can install your filter in a tc shared block and bind multiple ports
to it.
Another option is to always send a *copy* of multicast packets to the
CPU, but make sure the HW uses a policer that prevents the CPU from
being overwhelmed. To avoid packets being forwarded twice (by HW and
SW), you will need to mark such packets in your driver with
'skb->offload_fwd_mark = 1'.
Now, in case user wants to allow the CPU to receive certain packets at a
higher rate, a tc filter can be used. It will be identical to the filter
I mentioned earlier, but with a 'police' action chained before 'trap'.
I don't think this is currently supported by any driver, but I believe
it's the right way to go: By default the CPU receives all the traffic it
should receive and user can fine-tune it using ACLs.
^ permalink raw reply
* Re: [PATCH V4 net-next 00/10] net: hns3: some code optimizations & bugfixes & features
From: Saeed Mahameed @ 2019-07-29 5:48 UTC (permalink / raw)
To: tanhuazhong@huawei.com, davem@davemloft.net
Cc: yisen.zhuang@huawei.com, salil.mehta@huawei.com,
linuxarm@huawei.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1564368811-65492-1-git-send-email-tanhuazhong@huawei.com>
On Mon, 2019-07-29 at 10:53 +0800, Huazhong Tan wrote:
> This patch-set includes code optimizations, bugfixes and features for
> the HNS3 ethernet controller driver.
>
> [patch 1/10] checks reset status before setting channel.
>
> [patch 2/10] adds a NULL pointer checking.
>
> [patch 3/10] removes reset level upgrading when current reset fails.
>
> [patch 4/10] fixes a GFP flags errors when holding spin_lock.
>
> [patch 5/10] modifies firmware version format.
>
> [patch 6/10] adds some print information which is off by default.
>
> [patch 7/10 - 8/10] adds two code optimizations about interrupt
> handler
> and work task.
>
> [patch 9/10] adds support for using order 1 pages with a 4K buffer.
>
> [patch 10/10] modifies messages prints with dev_info() instead of
> pr_info().
>
> Change log:
> V3->V4: replace netif_info with netif_dbg in [patch 6/10]
> V2->V3: fixes comments from Saeed Mahameed and Joe Perches.
> V1->V2: fixes comments from Saeed Mahameed and
> removes previous [patch 4/11] and [patch 11/11]
> which needs further discussion, and adds a new
> patch [10/10] suggested by Saeed Mahameed.
>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH v3] net: dsa: qca8k: enable port flow control
From: xiaofeis @ 2019-07-29 5:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, vkoul, netdev, linux-arm-msm, bjorn.andersson,
vivien.didelot, f.fainelli, niklas.cassel, xiazha
In-Reply-To: <20190728223114.GD23125@lunn.ch>
On 2019-07-29 06:31, Andrew Lunn wrote:
> On Sun, Jul 28, 2019 at 08:57:50AM +0800, xiaofeis wrote:
>> Set phy device advertising to enable MAC flow control.
>
> Hi Xiaofei.
>
> This is half of the needed change for MAC flow control.
>
> phy_support_asym_pause(phy) is used by the MAC to tell the PHY layer
> that the MAC supports flow control. The PHY will then advertise
> this. When auto-negotiation is completed, the PHY layer will call
> qca8k_adjust_link() with the results. It could be that the peer does
> not support flow control, or only supports symmetric flow control. So
> in that function, you need to program the MAC with the results of the
> auto-neg. This is currently missing. You need to look at phydev->pause
> and phydev->asym_pause to decide how to configure the MAC.
>
> Andrew
Hi Andrew
You are correct. With the change, the auto-negotiation result still
depends on the peer.
But our qca8k HW can auto sync the pause status to MAC from phy with the
auto-negotiated result.
So no need to set in qca8k_adjust_link, since there is one setting in
qca8k_port_set_status: mask |= QCA8K_PORT_STATUS_LINK_AUTO;
This change's purpose is to keep enable advertise on our side.
Thanks
Xiaofeis
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: Jakub Kicinski @ 2019-07-29 4:42 UTC (permalink / raw)
To: wenxu; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <5eed91c1-20ed-c08c-4700-979392bc5f33@ucloud.cn>
On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
> > I don't know the nft code, but it seems unlikely it wouldn't have the
> > same problem/need..
>
> nft don't have the same problem. The offload rule can only attached
> to offload base chain.
>
> Th offload base chain is created after the device driver loaded (the
> device exist).
For indirect blocks the block is on the tunnel device and the offload
target is another device. E.g. you offload rules from a VXLAN device
onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
device is created.
So I feel like either the chain somehow directly references the offload
target (in which case the indirect infrastructure with hash lookup etc
is not needed for nft), or indirect infra is needed, and we need to take
care of replays.
^ permalink raw reply
* [PATCH 1/4] dt-bindings: net: Add aspeed,ast2600-mdio binding
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729043926.32679-1-andrew@aj.id.au>
The AST2600 splits out the MDIO bus controller from the MAC into its own
IP block and rearranges the register layout. Add a new binding to
describe the new hardware.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
.../bindings/net/aspeed,ast2600-mdio.yaml | 61 +++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
new file mode 100644
index 000000000000..fa86f6438473
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/aspeed,ast2600-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 MDIO Controller
+
+maintainers:
+ - Andrew Jeffery <andrew@aj.id.au>
+
+description: |+
+ The ASPEED AST2600 MDIO controller is the third iteration of ASPEED's MDIO
+ bus register interface, this time also separating out the controller from the
+ MAC.
+
+properties:
+ compatible:
+ const: aspeed,ast2600-mdio
+ reg:
+ maxItems: 1
+ description: The register range of the MDIO controller instance
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^ethernet-phy@[a-f0-9]$":
+ properties:
+ reg:
+ description:
+ The MDIO bus index of the PHY
+ compatible:
+ enum:
+ - ethernet-phy-ieee802.3-c22
+ - ethernet-phy-ieee802.3-c45
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ mdio0: mdio@1e650000 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x1e650000 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4] net: ftgmac100: Select ASPEED MDIO driver for the AST2600
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729043926.32679-1-andrew@aj.id.au>
Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO
controller is now separate from the MAC.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/net/ethernet/faraday/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/faraday/Kconfig b/drivers/net/ethernet/faraday/Kconfig
index a9b105803fb7..73e4f2648e49 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -32,6 +32,7 @@ config FTGMAC100
depends on ARM || NDS32 || COMPILE_TEST
depends on !64BIT || BROKEN
select PHYLIB
+ select MDIO_ASPEED if MACH_ASPEED_G6
---help---
This driver supports the FTGMAC100 Gigabit Ethernet controller
from Faraday. It is used on Faraday A369, Andes AG102 and some
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] net: ftgmac100: Add support for DT phy-handle property
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729043926.32679-1-andrew@aj.id.au>
phy-handle is necessary for the AST2600 which separates the MDIO
controllers from the MAC.
I've tried to minimise the intrusion of supporting the AST2600 to the
FTGMAC100 by leaving in place the existing MDIO support for the embedded
MDIO interface. The AST2400 and AST2500 continue to be supported this
way, as it avoids breaking/reworking existing devicetrees.
The AST2600 support by contrast requires the presence of the phy-handle
property in the MAC devicetree node to specify the appropriate PHY to
associate with the MAC. In the event that someone wants to specify the
MDIO bus topology under the MAC node on an AST2400 or AST2500, the
current auto-probe approach is done conditional on the absence of an
"mdio" child node of the MAC.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/net/ethernet/faraday/ftgmac100.c | 37 +++++++++++++++++++++---
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 030fed65393e..563384b788ab 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/of.h>
+#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <linux/property.h>
@@ -1619,8 +1620,13 @@ static int ftgmac100_setup_mdio(struct net_device *netdev)
if (!priv->mii_bus)
return -EIO;
- if (priv->is_aspeed) {
- /* This driver supports the old MDIO interface */
+ if (of_device_is_compatible(np, "aspeed,ast2400-mac") ||
+ of_device_is_compatible(np, "aspeed,ast2500-mac")) {
+ /* The AST2600 has a separate MDIO controller */
+
+ /* For the AST2400 and AST2500 this driver only supports the
+ * old MDIO interface
+ */
reg = ioread32(priv->base + FTGMAC100_OFFSET_REVR);
reg &= ~FTGMAC100_REVR_NEW_MDIO_INTERFACE;
iowrite32(reg, priv->base + FTGMAC100_OFFSET_REVR);
@@ -1797,7 +1803,8 @@ static int ftgmac100_probe(struct platform_device *pdev)
np = pdev->dev.of_node;
if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac") ||
- of_device_is_compatible(np, "aspeed,ast2500-mac"))) {
+ of_device_is_compatible(np, "aspeed,ast2500-mac") ||
+ of_device_is_compatible(np, "aspeed,ast2600-mac"))) {
priv->rxdes0_edorr_mask = BIT(30);
priv->txdes0_edotr_mask = BIT(30);
priv->is_aspeed = true;
@@ -1817,7 +1824,29 @@ static int ftgmac100_probe(struct platform_device *pdev)
priv->ndev = ncsi_register_dev(netdev, ftgmac100_ncsi_handler);
if (!priv->ndev)
goto err_ncsi_dev;
- } else {
+ } else if (np && of_get_property(np, "phy-handle", NULL)) {
+ struct phy_device *phy;
+
+ phy = of_phy_get_and_connect(priv->netdev, np,
+ &ftgmac100_adjust_link);
+ if (!phy) {
+ dev_err(&pdev->dev, "Failed to connect to phy\n");
+ goto err_setup_mdio;
+ }
+
+ /* Indicate that we support PAUSE frames (see comment in
+ * Documentation/networking/phy.txt)
+ */
+ phy_support_asym_pause(phy);
+
+ /* Display what we found */
+ phy_attached_info(phy);
+ } else if (np && !of_get_child_by_name(np, "mdio")) {
+ /* Support legacy ASPEED devicetree descriptions that decribe a
+ * MAC with an embedded MDIO controller but have no "mdio"
+ * child node. Automatically scan the MDIO bus for available
+ * PHYs.
+ */
priv->use_ncsi = false;
err = ftgmac100_setup_mdio(netdev);
if (err)
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] net: phy: Add mdio-aspeed
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
In-Reply-To: <20190729043926.32679-1-andrew@aj.id.au>
The AST2600 design separates the MDIO controllers from the MAC, which is
where they were placed in the AST2400 and AST2500. Further, the register
interface is reworked again, so now we have three possible different
interface implementations, however this driver only supports the
interface provided by the AST2600. The AST2400 and AST2500 will continue
to be supported by the MDIO support embedded in the FTGMAC100 driver.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/net/phy/Kconfig | 13 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-aspeed.c | 159 ++++++++++++++++++++++++++++++++++
3 files changed, 173 insertions(+)
create mode 100644 drivers/net/phy/mdio-aspeed.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 20f14c5fbb7e..206d8650ee7f 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -21,6 +21,19 @@ config MDIO_BUS
if MDIO_BUS
+config MDIO_ASPEED
+ tristate "ASPEED MDIO bus controller"
+ depends on ARCH_ASPEED || COMPILE_TEST
+ depends on OF_MDIO && HAS_IOMEM
+ help
+ This module provides a driver for the independent MDIO bus
+ controllers found in the ASPEED AST2600 SoC. This is a driver for the
+ third revision of the ASPEED MDIO register interface - the first two
+ revisions are the "old" and "new" interfaces found in the AST2400 and
+ AST2500, embedded in the MAC. For legacy reasons, FTGMAC100 driver
+ continues to drive the embedded MDIO controller for the AST2400 and
+ AST2500 SoCs, so say N if AST2600 support is not required.
+
config MDIO_BCM_IPROC
tristate "Broadcom iProc MDIO bus controller"
depends on ARCH_BCM_IPROC || COMPILE_TEST
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 839acb292c38..ba07c27e4208 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -22,6 +22,7 @@ libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
obj-$(CONFIG_PHYLINK) += phylink.o
obj-$(CONFIG_PHYLIB) += libphy.o
+obj-$(CONFIG_MDIO_ASPEED) += mdio-aspeed.o
obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
diff --git a/drivers/net/phy/mdio-aspeed.c b/drivers/net/phy/mdio-aspeed.c
new file mode 100644
index 000000000000..71496a9ff54a
--- /dev/null
+++ b/drivers/net/phy/mdio-aspeed.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 IBM Corp. */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/mdio.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_mdio.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+
+#define DRV_NAME "mdio-aspeed"
+
+#define ASPEED_MDIO_CTRL 0x0
+#define ASPEED_MDIO_CTRL_FIRE BIT(31)
+#define ASPEED_MDIO_CTRL_ST BIT(28)
+#define ASPEED_MDIO_CTRL_ST_C45 0
+#define ASPEED_MDIO_CTRL_ST_C22 1
+#define ASPEED_MDIO_CTRL_OP GENMASK(27, 26)
+#define MDIO_C22_OP_WRITE 0b01
+#define MDIO_C22_OP_READ 0b10
+#define ASPEED_MDIO_CTRL_PHYAD GENMASK(25, 21)
+#define ASPEED_MDIO_CTRL_REGAD GENMASK(20, 16)
+#define ASPEED_MDIO_CTRL_MIIWDATA GENMASK(15, 0)
+
+#define ASPEED_MDIO_DATA 0x4
+#define ASPEED_MDIO_DATA_MDC_THRES GENMASK(31, 24)
+#define ASPEED_MDIO_DATA_MDIO_EDGE BIT(23)
+#define ASPEED_MDIO_DATA_MDIO_LATCH GENMASK(22, 20)
+#define ASPEED_MDIO_DATA_IDLE BIT(16)
+#define ASPEED_MDIO_DATA_MIIRDATA GENMASK(15, 0)
+
+#define ASPEED_MDIO_RETRIES 10
+
+struct aspeed_mdio {
+ void __iomem *base;
+};
+
+static int aspeed_mdio_read(struct mii_bus *bus, int addr, int regnum)
+{
+ struct aspeed_mdio *ctx = bus->priv;
+ u32 ctrl;
+ int i;
+
+ dev_dbg(&bus->dev, "%s: addr: %d, regnum: %d\n", __func__, addr,
+ regnum);
+
+ /* Just clause 22 for the moment */
+ ctrl = ASPEED_MDIO_CTRL_FIRE
+ | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_READ)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, regnum);
+
+ iowrite32(ctrl, ctx->base + ASPEED_MDIO_CTRL);
+
+ for (i = 0; i < ASPEED_MDIO_RETRIES; i++) {
+ u32 data;
+
+ data = ioread32(ctx->base + ASPEED_MDIO_DATA);
+ if (data & ASPEED_MDIO_DATA_IDLE)
+ return FIELD_GET(ASPEED_MDIO_DATA_MIIRDATA, data);
+
+ udelay(100);
+ }
+
+ dev_err(&bus->dev, "MDIO read failed\n");
+ return -EIO;
+}
+
+static int aspeed_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
+{
+ struct aspeed_mdio *ctx = bus->priv;
+ u32 ctrl;
+ int i;
+
+ dev_dbg(&bus->dev, "%s: addr: %d, regnum: %d, val: 0x%x\n",
+ __func__, addr, regnum, val);
+
+ /* Just clause 22 for the moment */
+ ctrl = ASPEED_MDIO_CTRL_FIRE
+ | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_WRITE)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, regnum)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_MIIWDATA, val);
+
+ iowrite32(ctrl, ctx->base + ASPEED_MDIO_CTRL);
+
+ for (i = 0; i < ASPEED_MDIO_RETRIES; i++) {
+ ctrl = ioread32(ctx->base + ASPEED_MDIO_CTRL);
+ if (!(ctrl & ASPEED_MDIO_CTRL_FIRE))
+ return 0;
+
+ udelay(100);
+ }
+
+ dev_err(&bus->dev, "MDIO write failed\n");
+ return -EIO;
+}
+
+static int aspeed_mdio_probe(struct platform_device *pdev)
+{
+ struct aspeed_mdio *ctx;
+ struct mii_bus *bus;
+ int rc;
+
+ bus = devm_mdiobus_alloc_size(&pdev->dev, sizeof(*ctx));
+ if (!bus)
+ return -ENOMEM;
+
+ ctx = bus->priv;
+ ctx->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(ctx->base))
+ return PTR_ERR(ctx->base);
+
+ bus->name = DRV_NAME;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s%d", pdev->name, pdev->id);
+ bus->parent = &pdev->dev;
+ bus->read = aspeed_mdio_read;
+ bus->write = aspeed_mdio_write;
+
+ rc = of_mdiobus_register(bus, pdev->dev.of_node);
+ if (rc) {
+ dev_err(&pdev->dev, "Cannot register MDIO bus!\n");
+ return rc;
+ }
+
+ platform_set_drvdata(pdev, bus);
+
+ return 0;
+}
+
+static int aspeed_mdio_remove(struct platform_device *pdev)
+{
+ mdiobus_unregister(platform_get_drvdata(pdev));
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_mdio_of_match[] = {
+ { .compatible = "aspeed,ast2600-mdio", },
+ { },
+};
+
+static struct platform_driver aspeed_mdio_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .of_match_table = aspeed_mdio_of_match,
+ },
+ .probe = aspeed_mdio_probe,
+ .remove = aspeed_mdio_remove,
+};
+
+module_platform_driver(aspeed_mdio_driver);
+
+MODULE_AUTHOR("Andrew Jeffery <andrew@aj.id.au>");
+MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related
* [PATCH 0/4] net: phy: Add AST2600 MDIO support
From: Andrew Jeffery @ 2019-07-29 4:39 UTC (permalink / raw)
To: netdev
Cc: Andrew Jeffery, davem, robh+dt, mark.rutland, joel, andrew,
f.fainelli, hkallweit1, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
Hello,
This series adds support for the MDIO controllers found in the AST2600. In the
AST2500 and earlier the MDIO controller was embedded in the MAC; this has now
been separated out and the register interface rearranged (again).
Please review!
Andrew
Andrew Jeffery (4):
dt-bindings: net: Add aspeed,ast2600-mdio binding
net: phy: Add mdio-aspeed
net: ftgmac100: Add support for DT phy-handle property
net: ftgmac100: Select ASPEED MDIO driver for the AST2600
.../bindings/net/aspeed,ast2600-mdio.yaml | 61 +++++++
drivers/net/ethernet/faraday/Kconfig | 1 +
drivers/net/ethernet/faraday/ftgmac100.c | 37 +++-
drivers/net/phy/Kconfig | 13 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-aspeed.c | 159 ++++++++++++++++++
6 files changed, 268 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
create mode 100644 drivers/net/phy/mdio-aspeed.c
--
2.20.1
^ permalink raw reply
* Re: [RFC] net: phy: read link status twice when phy_check_link_status()
From: liuyonglong @ 2019-07-29 3:59 UTC (permalink / raw)
To: Heiner Kallweit, andrew, davem
Cc: netdev, linux-kernel, linuxarm, salil.mehta, yisen.zhuang,
shiju.jose
In-Reply-To: <92f42ee8-3659-87a7-ac96-d312a98046ba@gmail.com>
On 2019/7/27 2:14, Heiner Kallweit wrote:
> On 26.07.2019 11:53, Yonglong Liu wrote:
>> According to the datasheet of Marvell phy and Realtek phy, the
>> copper link status should read twice, or it may get a fake link
>> up status, and cause up->down->up at the first time when link up.
>> This happens more oftem at Realtek phy.
>>
> This is not correct, there is no fake link up status.
> Read the comment in genphy_update_link, only link-down events
> are latched. Means if the first read returns link up, then there
> is no need for a second read. And in polling mode we don't do a
> second read because we want to detect also short link drops.
>
> It would be helpful if you could describe your actual problem
> and whether you use polling or interrupt mode.
>
[ 44.498633] hns3 0000:bd:00.1 eth5: net open
[ 44.504273] hns3 0000:bd:00.1: reg=0x1, data=0x79ad -> called from phy_start_aneg
[ 44.532348] hns3 0000:bd:00.1: reg=0x1, data=0x798d -> called from phy_state_machine,update link.
According to the datasheet:
reg 1.5=0 now, means copper auto-negotiation not complete
reg 1.2=1 now, means link is up
We can see that, when we read the link up, the auto-negotiation
is not complete yet, so the speed is invalid.
I don't know why this happen, maybe this state is keep from bios?
Or we may do something else in the phy initialize to fix it?
And also confuse that why read twice can fix it?
[ 44.554063] hns3 0000:bd:00.1: invalid speed (-1)
[ 44.560412] hns3 0000:bd:00.1 eth5: failed to adjust link.
[ 45.194870] hns3 0000:bd:00.1 eth5: link up
[ 45.574095] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x7989
[ 46.150051] hns3 0000:bd:00.1 eth5: link down
[ 46.598074] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x7989
[ 47.622075] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x79a9
[ 48.646077] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x79ad
[ 48.934050] hns3 0000:bd:00.1 eth5: link up
[ 49.702140] hns3 0000:bd:00.1: phyid=3, reg=0x1, data=0x79ad
>> I add a fake status read, and can solve this problem.
>>
>> I also see that in genphy_update_link(), had delete the fake
>> read in polling mode, so I don't know whether my solution is
>> correct.
>>
>> Or provide a phydev->drv->read_status functions for the phy I
>> used is more acceptable?
>>
>> Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
>> ---
>> drivers/net/phy/phy.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index ef7aa73..0c03edc 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -1,4 +1,7 @@
>> // SPDX-License-Identifier: GPL-2.0+
>> + err = phy_read_status(phydev);
>> + if (err)
>> + return err;
>
> This seems to be completely wrong at that place.
>
Sorry, this can be ignore.
>> /* Framework for configuring and reading PHY devices
>> * Based on code in sungem_phy.c and gianfar_phy.c
>> *
>> @@ -525,6 +528,11 @@ static int phy_check_link_status(struct phy_device *phydev)
>>
>> WARN_ON(!mutex_is_locked(&phydev->lock));
>>
>> + /* Do a fake read */
>> + err = phy_read(phydev, MII_BMSR);
>> + if (err < 0)
>> + return err;
>> +
>> err = phy_read_status(phydev);
>> if (err)
>> return err;
>>
>
>
> .
>
^ permalink raw reply
* [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Jia-Ju Bai @ 2019-07-29 3:43 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: netdev, linux-kernel
In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm
is NULL.
Then, dst->xfrm is used on line 3840:
xfrm_state_mtu(dst->xfrm, mtu);
if (x->km.state != XFRM_STATE_VALID...)
aead = x->data;
Thus, possible null-pointer dereferences may occur.
These bugs are found by a static analysis tool STCheck written by us.
I do not know how to correctly fix these bugs, so I only report them.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nf_table_offload: Fix zero prio of flow_cls_common_offload
From: wenxu @ 2019-07-29 3:43 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, pablo; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <20190725034540.GJ6204@localhost.localdomain>
Hi pablo
Any suggestion for this case. Tthe 0 prio vlaue for driver is an invalid priority. So What should we do for this
case? Currently there is no prio for each nft rules.
BR
wenxu
On 7/25/2019 11:45 AM, Marcelo Ricardo Leitner wrote:
> On Thu, Jul 25, 2019 at 11:03:52AM +0800, wenxu wrote:
>> On 7/25/2019 7:51 AM, Marcelo Ricardo Leitner wrote:
>>> On Thu, Jul 11, 2019 at 04:03:30PM +0800, wenxu@ucloud.cn wrote:
>>>> From: wenxu <wenxu@ucloud.cn>
>>>>
>>>> The flow_cls_common_offload prio should be not zero
>>>>
>>>> It leads the invalid table prio in hw.
>>>>
>>>> # nft add table netdev firewall
>>>> # nft add chain netdev firewall acl { type filter hook ingress device mlx_pf0vf0 priority - 300 \; }
>>>> # nft add rule netdev firewall acl ip daddr 1.1.1.7 drop
>>>> Error: Could not process rule: Invalid argument
>>>>
>>>> kernel log
>>>> mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22 (table prio: 65535, level: 0, size: 4194304)
>>>>
>>>> Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
>>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>>>> ---
>>>> net/netfilter/nf_tables_offload.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
>>>> index 2c33028..01d8133 100644
>>>> --- a/net/netfilter/nf_tables_offload.c
>>>> +++ b/net/netfilter/nf_tables_offload.c
>>>> @@ -7,6 +7,8 @@
>>>> #include <net/netfilter/nf_tables_offload.h>
>>>> #include <net/pkt_cls.h>
>>>>
>>>> +#define FLOW_OFFLOAD_DEFAUT_PRIO 1U
>>>> +
>>>> static struct nft_flow_rule *nft_flow_rule_alloc(int num_actions)
>>>> {
>>>> struct nft_flow_rule *flow;
>>>> @@ -107,6 +109,7 @@ static void nft_flow_offload_common_init(struct flow_cls_common_offload *common,
>>>> struct netlink_ext_ack *extack)
>>>> {
>>>> common->protocol = proto;
>>>> + common->prio = TC_H_MAKE(FLOW_OFFLOAD_DEFAUT_PRIO << 16, 0);
>>> Note that tc semantics for this is to auto-generate a priority in such
>>> cases, instead of using a default.
>>>
>>> @tc_new_tfilter():
>>> if (prio == 0) {
>>> /* If no priority is provided by the user,
>>> * we allocate one.
>>> */
>>> if (n->nlmsg_flags & NLM_F_CREATE) {
>>> prio = TC_H_MAKE(0x80000000U, 0U);
>>> prio_allocate = true;
>>> ...
>>> if (prio_allocate)
>>> prio = tcf_auto_prio(tcf_chain_tp_prev(chain,
>>> &chain_info));
>> Yes,The tc auto-generate a priority. But if there is no pre
>> tcf_proto, the priority is also set as a default.
> After the first filter, there will be a tcf_proto. Please see the test below.
>
>> In nftables each rule no priortiy for each other. So It is enough to
>> set a default value which is similar as the tc.
> Yep, maybe it works for nftables. I'm just highlighting this because
> it is reusing tc infrastructure and will expose a different behavior
> to the user. But if nftables already has this defined, that probably
> takes precedence by now and all that is left to do is to make sure any
> documentation on it is updated. Pablo?
>
>> static inline u32 tcf_auto_prio(struct tcf_proto *tp)
>> {
>> u32 first = TC_H_MAKE(0xC0000000U, 0U);
> ^^^^ base default prio, 0xC0000 = 49152
>
>> if (tp)
>> first = tp->prio - 1;
>>
>> return TC_H_MAJ(first);
>> }
> # tc qdisc add dev veth1 ingress
> # tc filter add dev veth1 ingress proto ip flower src_mac ec:13:db:00:00:00 action drop
> 1st filter --^^
> # tc filter add dev veth1 ingress proto ip flower src_mac ec:13:db:00:00:01 action drop
> 2nd filter --^^
> # tc filter add dev veth1 ingress proto ip flower src_mac ec:13:db:00:00:02 action drop
>
> With no 'prio X' parameter, it uses 0 as default, and when dumped:
>
> # tc filter show dev veth1 ingress
> filter protocol ip pref 49150 flower
> filter protocol ip pref 49150 flower handle 0x1
> src_mac ec:13:db:00:00:02
> eth_type ipv4
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 40003 ref 1 bind 1
>
> filter protocol ip pref 49151 flower
> filter protocol ip pref 49151 flower handle 0x1
> ^vv^^---- 2nd filter
> src_mac ec:13:db:00:00:01
> eth_type ipv4
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 40002 ref 1 bind 1
>
> filter protocol ip pref 49152 flower
> filter protocol ip pref 49152 flower handle 0x1
> ^vv^^---- 1st filter
> src_mac ec:13:db:00:00:00
> eth_type ipv4
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 40001 ref 1 bind 1
>
>
>
^ permalink raw reply
* [PATCH] ath6kl: Fix a possible null-pointer dereference in ath6kl_htc_mbox_create()
From: Jia-Ju Bai @ 2019-07-29 3:03 UTC (permalink / raw)
To: kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In ath6kl_htc_mbox_create(), when kzalloc() on line 2855 fails,
target->dev is assigned to NULL, and ath6kl_htc_mbox_cleanup(target) is
called on line 2885.
In ath6kl_htc_mbox_cleanup(), target->dev is used on line 2895:
ath6kl_hif_cleanup_scatter(target->dev->ar);
Thus, a null-pointer dereference may occur.
To fix this bug, kfree(target) is called and NULL is returned when
kzalloc() on line 2855 fails.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 65c31da43c47..998947ef63b6 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -2855,8 +2855,8 @@ static void *ath6kl_htc_mbox_create(struct ath6kl *ar)
target->dev = kzalloc(sizeof(*target->dev), GFP_KERNEL);
if (!target->dev) {
ath6kl_err("unable to allocate memory\n");
- status = -ENOMEM;
- goto err_htc_cleanup;
+ kfree(target);
+ return NULL;
}
spin_lock_init(&target->htc_lock);
--
2.17.0
^ permalink raw reply related
* [PATCH V4 net-next 01/10] net: hns3: add reset checking before set channels
From: Huazhong Tan @ 2019-07-29 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm, saeedm,
Jian Shen, Huazhong Tan
In-Reply-To: <1564368811-65492-1-git-send-email-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
hns3_set_channels() should check the resetting status firstly,
since the device will reinitialize when resetting. If the
reset has not completed, the hns3_set_channels() may access
invalid memory.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 69f7ef8..08af782 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -4378,6 +4378,9 @@ int hns3_set_channels(struct net_device *netdev,
u16 org_tqp_num;
int ret;
+ if (hns3_nic_resetting(netdev))
+ return -EBUSY;
+
if (ch->rx_count || ch->tx_count)
return -EINVAL;
--
2.7.4
^ permalink raw reply related
* [PATCH V4 net-next 02/10] net: hns3: add a check for get_reset_level
From: Huazhong Tan @ 2019-07-29 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm, saeedm,
Guangbin Huang, Huazhong Tan
In-Reply-To: <1564368811-65492-1-git-send-email-tanhuazhong@huawei.com>
From: Guangbin Huang <huangguangbin@huawei.com>
For some cases, ops->get_reset_level may not be implemented, so we
should check whether it is NULL before calling get_reset_level.
Signed-off-by: Guangbin Huang <huangguangbin@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 08af782..4d58c53 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1963,7 +1963,7 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev *pdev)
ops = ae_dev->ops;
/* request the reset */
- if (ops->reset_event) {
+ if (ops->reset_event && ops->get_reset_level) {
if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
&ae_dev->hw_err_reset_req);
--
2.7.4
^ permalink raw reply related
* [PATCH V4 net-next 05/10] net: hns3: modify firmware version display format
From: Huazhong Tan @ 2019-07-29 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm, saeedm,
Yufeng Mo, Peng Li, Huazhong Tan
In-Reply-To: <1564368811-65492-1-git-send-email-tanhuazhong@huawei.com>
From: Yufeng Mo <moyufeng@huawei.com>
This patch modifies firmware version display format in
hclge(vf)_cmd_init() and hns3_get_drvinfo(). Also, adds
some optimizations for firmware version display format.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 9 +++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +++++++++++++--
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +++++++++-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 10 +++++++++-
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 48c7b70..a4624db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -179,6 +179,15 @@ struct hnae3_vector_info {
#define HNAE3_RING_GL_RX 0
#define HNAE3_RING_GL_TX 1
+#define HNAE3_FW_VERSION_BYTE3_SHIFT 24
+#define HNAE3_FW_VERSION_BYTE3_MASK GENMASK(31, 24)
+#define HNAE3_FW_VERSION_BYTE2_SHIFT 16
+#define HNAE3_FW_VERSION_BYTE2_MASK GENMASK(23, 16)
+#define HNAE3_FW_VERSION_BYTE1_SHIFT 8
+#define HNAE3_FW_VERSION_BYTE1_MASK GENMASK(15, 8)
+#define HNAE3_FW_VERSION_BYTE0_SHIFT 0
+#define HNAE3_FW_VERSION_BYTE0_MASK GENMASK(7, 0)
+
struct hnae3_ring_chain_node {
struct hnae3_ring_chain_node *next;
u32 tqp_index;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 5bff98a..e71c92b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -527,6 +527,7 @@ static void hns3_get_drvinfo(struct net_device *netdev,
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
+ u32 fw_version;
if (!h->ae_algo->ops->get_fw_version) {
netdev_err(netdev, "could not get fw version!\n");
@@ -545,8 +546,18 @@ static void hns3_get_drvinfo(struct net_device *netdev,
sizeof(drvinfo->bus_info));
drvinfo->bus_info[ETHTOOL_BUSINFO_LEN - 1] = '\0';
- snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
- priv->ae_handle->ae_algo->ops->get_fw_version(h));
+ fw_version = priv->ae_handle->ae_algo->ops->get_fw_version(h);
+
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "%lu.%lu.%lu.%lu",
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE3_MASK,
+ HNAE3_FW_VERSION_BYTE3_SHIFT),
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE2_MASK,
+ HNAE3_FW_VERSION_BYTE2_SHIFT),
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE1_MASK,
+ HNAE3_FW_VERSION_BYTE1_SHIFT),
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE0_MASK,
+ HNAE3_FW_VERSION_BYTE0_SHIFT));
}
static u32 hns3_get_link(struct net_device *netdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 22f6acd..d9858f2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -419,7 +419,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
}
hdev->fw_version = version;
- dev_info(&hdev->pdev->dev, "The firmware version is %08x\n", version);
+ dev_info(&hdev->pdev->dev, "The firmware version is %lu.%lu.%lu.%lu\n",
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+ HNAE3_FW_VERSION_BYTE3_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+ HNAE3_FW_VERSION_BYTE2_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+ HNAE3_FW_VERSION_BYTE1_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+ HNAE3_FW_VERSION_BYTE0_SHIFT));
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 652b796..8f21eb3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -405,7 +405,15 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
}
hdev->fw_version = version;
- dev_info(&hdev->pdev->dev, "The firmware version is %08x\n", version);
+ dev_info(&hdev->pdev->dev, "The firmware version is %lu.%lu.%lu.%lu\n",
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+ HNAE3_FW_VERSION_BYTE3_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+ HNAE3_FW_VERSION_BYTE2_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+ HNAE3_FW_VERSION_BYTE1_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+ HNAE3_FW_VERSION_BYTE0_SHIFT));
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH V4 net-next 06/10] net: hns3: add debug messages to identify eth down cause
From: Huazhong Tan @ 2019-07-29 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm, saeedm,
Yonglong Liu, Peng Li, Huazhong Tan
In-Reply-To: <1564368811-65492-1-git-send-email-tanhuazhong@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
Some times just see the eth interface have been down/up via
dmesg, but can not know why the eth down. So adds some debug
messages to identify the cause for this.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 18 ++++++++++++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 19 +++++++++++++++++++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 11 +++++++++++
3 files changed, 48 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4d58c53..0cf9301 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -459,6 +459,9 @@ static int hns3_nic_net_open(struct net_device *netdev)
h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
hns3_config_xps(priv);
+
+ netif_dbg(h, drv, netdev, "net open\n");
+
return 0;
}
@@ -519,6 +522,8 @@ static int hns3_nic_net_stop(struct net_device *netdev)
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, &priv->state))
return 0;
+ netif_dbg(h, drv, netdev, "net stop\n");
+
if (h->ae_algo->ops->set_timer_task)
h->ae_algo->ops->set_timer_task(priv->ae_handle, false);
@@ -1550,6 +1555,8 @@ static int hns3_setup_tc(struct net_device *netdev, void *type_data)
h = hns3_get_handle(netdev);
kinfo = &h->kinfo;
+ netif_dbg(h, drv, netdev, "setup tc: num_tc=%u\n", tc);
+
return (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
}
@@ -1593,6 +1600,10 @@ static int hns3_ndo_set_vf_vlan(struct net_device *netdev, int vf, u16 vlan,
struct hnae3_handle *h = hns3_get_handle(netdev);
int ret = -EIO;
+ netif_dbg(h, drv, netdev,
+ "set vf vlan: vf=%d, vlan=%u, qos=%u, vlan_proto=%u\n",
+ vf, vlan, qos, vlan_proto);
+
if (h->ae_algo->ops->set_vf_vlan_filter)
ret = h->ae_algo->ops->set_vf_vlan_filter(h, vf, vlan,
qos, vlan_proto);
@@ -1611,6 +1622,9 @@ static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
if (!h->ae_algo->ops->set_mtu)
return -EOPNOTSUPP;
+ netif_dbg(h, drv, netdev,
+ "change mtu from %u to %d\n", netdev->mtu, new_mtu);
+
ret = h->ae_algo->ops->set_mtu(h, new_mtu);
if (ret)
netdev_err(netdev, "failed to change MTU in hardware %d\n",
@@ -4395,6 +4409,10 @@ int hns3_set_channels(struct net_device *netdev,
if (kinfo->rss_size == new_tqp_num)
return 0;
+ netif_dbg(h, drv, netdev,
+ "set channels: tqp_num=%u, rxfh=%d\n",
+ new_tqp_num, rxfh_configured);
+
ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index e71c92b..fe0f82a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -311,6 +311,8 @@ static void hns3_self_test(struct net_device *ndev,
if (eth_test->flags != ETH_TEST_FL_OFFLINE)
return;
+ netif_dbg(h, drv, ndev, "self test start");
+
st_param[HNAE3_LOOP_APP][0] = HNAE3_LOOP_APP;
st_param[HNAE3_LOOP_APP][1] =
h->flags & HNAE3_SUPPORT_APP_LOOPBACK;
@@ -374,6 +376,8 @@ static void hns3_self_test(struct net_device *ndev,
if (if_running)
ndev->netdev_ops->ndo_open(ndev);
+
+ netif_dbg(h, drv, ndev, "self test end\n");
}
static int hns3_get_sset_count(struct net_device *netdev, int stringset)
@@ -604,6 +608,10 @@ static int hns3_set_pauseparam(struct net_device *netdev,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
+ netif_dbg(h, drv, netdev,
+ "set pauseparam: autoneg=%u, rx:%u, tx:%u\n",
+ param->autoneg, param->rx_pause, param->tx_pause);
+
if (h->ae_algo->ops->set_pauseparam)
return h->ae_algo->ops->set_pauseparam(h, param->autoneg,
param->rx_pause,
@@ -743,6 +751,11 @@ static int hns3_set_link_ksettings(struct net_device *netdev,
if (cmd->base.speed == SPEED_1000 && cmd->base.duplex == DUPLEX_HALF)
return -EINVAL;
+ netif_dbg(handle, drv, netdev,
+ "set link(%s): autoneg=%u, speed=%u, duplex=%u\n",
+ netdev->phydev ? "phy" : "mac",
+ cmd->base.autoneg, cmd->base.speed, cmd->base.duplex);
+
/* Only support ksettings_set for netdev with phy attached for now */
if (netdev->phydev)
return phy_ethtool_ksettings_set(netdev->phydev, cmd);
@@ -984,6 +997,9 @@ static int hns3_nway_reset(struct net_device *netdev)
return -EINVAL;
}
+ netif_dbg(handle, drv, netdev,
+ "nway reset (using %s)\n", phy ? "phy" : "mac");
+
if (phy)
return genphy_restart_aneg(phy);
@@ -1308,6 +1324,9 @@ static int hns3_set_fecparam(struct net_device *netdev,
if (!ops->set_fec)
return -EOPNOTSUPP;
fec_mode = eth_to_loc_fec(fec->fec);
+
+ netif_dbg(handle, drv, netdev, "set fecparam: mode=%u\n", fec_mode);
+
return ops->set_fec(handle, fec_mode);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index bac4ce1..814e0f0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -201,6 +201,7 @@ static int hclge_client_setup_tc(struct hclge_dev *hdev)
static int hclge_ieee_setets(struct hnae3_handle *h, struct ieee_ets *ets)
{
struct hclge_vport *vport = hclge_get_vport(h);
+ struct net_device *netdev = h->kinfo.netdev;
struct hclge_dev *hdev = vport->back;
bool map_changed = false;
u8 num_tc = 0;
@@ -215,6 +216,8 @@ static int hclge_ieee_setets(struct hnae3_handle *h, struct ieee_ets *ets)
return ret;
if (map_changed) {
+ netif_dbg(h, drv, netdev, "set ets\n");
+
ret = hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
@@ -300,6 +303,7 @@ static int hclge_ieee_getpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
{
struct hclge_vport *vport = hclge_get_vport(h);
+ struct net_device *netdev = h->kinfo.netdev;
struct hclge_dev *hdev = vport->back;
u8 i, j, pfc_map, *prio_tc;
@@ -325,6 +329,10 @@ static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
hdev->tm_info.hw_pfc_map = pfc_map;
hdev->tm_info.pfc_en = pfc->pfc_en;
+ netif_dbg(h, drv, netdev,
+ "set pfc: pfc_en=%u, pfc_map=%u, num_tc=%u\n",
+ pfc->pfc_en, pfc_map, hdev->tm_info.num_tc);
+
hclge_tm_pfc_info_update(hdev);
return hclge_pause_setup_hw(hdev, false);
@@ -345,8 +353,11 @@ static u8 hclge_getdcbx(struct hnae3_handle *h)
static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
{
struct hclge_vport *vport = hclge_get_vport(h);
+ struct net_device *netdev = h->kinfo.netdev;
struct hclge_dev *hdev = vport->back;
+ netif_dbg(h, drv, netdev, "set dcbx: mode=%u\n", mode);
+
/* No support for LLD_MANAGED modes or CEE */
if ((mode & DCB_CAP_DCBX_LLD_MANAGED) ||
(mode & DCB_CAP_DCBX_VER_CEE) ||
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox