* 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
* [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
* [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 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 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 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
* 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
* 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 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] 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 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: 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 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-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: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: 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: 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
* [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
* [PATCH iproute2-rc 1/2] rdma: Control CQ adaptive moderation (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
In-Reply-To: <20190729074226.4335-1-leon@kernel.org>
From: Yamin Friedman <yaminf@mellanox.com>
In order to set adaptive-moderation for an ib device the command is:
rdma dev set [DEV] adaptive-moderation [on|off]
rdma dev show -d
0: mlx5_0: node_type ca fw 16.25.0319 node_guid 248a:0703:00a5:29d0
sys_image_guid 248a:0703:00a5:29d0 adaptive-moderation on
caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, AUTO_PATH_MIG, CHANGE_PHY_PORT,
PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, XRC,
MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B,
RAW_IP_CSUM, CROSS_CHANNEL, MANAGED_FLOW_STEERING, SIGNATURE_HANDOVER,
ON_DEMAND_PAGING, SG_GAPS_REG, RAW_SCATTER_FCS, PCI_WRITE_END_PADDING>
rdma resource show cq
dev mlx5_0 cqn 0 cqe 1023 users 4 poll-ctx UNBOUND_WORKQUEUE
adaptive-moderation off comm [ib_core]
Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/dev.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++-
rdma/rdma.h | 1 +
rdma/res-cq.c | 15 ++++++++++++++
rdma/utils.c | 6 ++++++
4 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/rdma/dev.c b/rdma/dev.c
index d28bf6b3..c597cba5 100644
--- a/rdma/dev.c
+++ b/rdma/dev.c
@@ -12,6 +12,7 @@ static int dev_help(struct rd *rd)
pr_out("Usage: %s dev show [DEV]\n", rd->filename);
pr_out(" %s dev set [DEV] name DEVNAME\n", rd->filename);
pr_out(" %s dev set [DEV] netns NSNAME\n", rd->filename);
+ pr_out(" %s dev set [DEV] adaptive-moderation [on|off]\n", rd->filename);
return 0;
}
@@ -167,6 +168,21 @@ static void dev_print_sys_image_guid(struct rd *rd, struct nlattr **tb)
pr_out("sys_image_guid %s ", str);
}
+static void dev_print_dim_setting(struct rd *rd, struct nlattr **tb)
+{
+ uint8_t dim_setting;
+
+ if (!tb[RDMA_NLDEV_ATTR_DEV_DIM])
+ return;
+
+ dim_setting = mnl_attr_get_u8(tb[RDMA_NLDEV_ATTR_DEV_DIM]);
+ if (dim_setting > 1)
+ return;
+
+ print_on_off(rd, "adaptive-moderation", dim_setting);
+
+}
+
static const char *node_type_to_str(uint8_t node_type)
{
static const char * const node_type_str[] = { "unknown", "ca",
@@ -219,8 +235,10 @@ static int dev_parse_cb(const struct nlmsghdr *nlh, void *data)
dev_print_fw(rd, tb);
dev_print_node_guid(rd, tb);
dev_print_sys_image_guid(rd, tb);
- if (rd->show_details)
+ if (rd->show_details) {
+ dev_print_dim_setting(rd, tb);
dev_print_caps(rd, tb);
+ }
if (!rd->json_output)
pr_out("\n");
@@ -308,12 +326,47 @@ done:
return ret;
}
+static int dev_set_dim_sendmsg(struct rd *rd, uint8_t dim_setting)
+{
+ uint32_t seq;
+
+ rd_prepare_msg(rd, RDMA_NLDEV_CMD_SET, &seq,
+ (NLM_F_REQUEST | NLM_F_ACK));
+ mnl_attr_put_u32(rd->nlh, RDMA_NLDEV_ATTR_DEV_INDEX, rd->dev_idx);
+ mnl_attr_put_u8(rd->nlh, RDMA_NLDEV_ATTR_DEV_DIM, dim_setting);
+
+ return rd_sendrecv_msg(rd, seq);
+}
+
+static int dev_set_dim_off(struct rd *rd)
+{
+ return dev_set_dim_sendmsg(rd, 0);
+}
+
+static int dev_set_dim_on(struct rd *rd)
+{
+ return dev_set_dim_sendmsg(rd, 1);
+}
+
+static int dev_set_dim(struct rd *rd)
+{
+ const struct rd_cmd cmds[] = {
+ { NULL, dev_help},
+ { "on", dev_set_dim_on},
+ { "off", dev_set_dim_off},
+ { 0 }
+ };
+
+ return rd_exec_cmd(rd, cmds, "parameter");
+}
+
static int dev_one_set(struct rd *rd)
{
const struct rd_cmd cmds[] = {
{ NULL, dev_help},
{ "name", dev_set_name},
{ "netns", dev_set_netns},
+ { "adaptive-moderation", dev_set_dim},
{ 0 }
};
diff --git a/rdma/rdma.h b/rdma/rdma.h
index 23157743..dfd1b70b 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -136,6 +136,7 @@ int rd_attr_check(const struct nlattr *attr, int *typep);
void print_driver_table(struct rd *rd, struct nlattr *tb);
void newline(struct rd *rd);
void newline_indent(struct rd *rd);
+void print_on_off(struct rd *rd, const char *key_str, bool on);
#define MAX_LINE_LENGTH 80
#endif /* _RDMA_TOOL_H_ */
diff --git a/rdma/res-cq.c b/rdma/res-cq.c
index 5afb97c5..d2591fbe 100644
--- a/rdma/res-cq.c
+++ b/rdma/res-cq.c
@@ -30,6 +30,20 @@ static void print_poll_ctx(struct rd *rd, uint8_t poll_ctx, struct nlattr *attr)
pr_out("poll-ctx %s ", poll_ctx_to_str(poll_ctx));
}
+static void print_cq_dim_setting(struct rd *rd, struct nlattr *attr)
+{
+ uint8_t dim_setting;
+
+ if (!attr)
+ return;
+
+ dim_setting = mnl_attr_get_u8(attr);
+ if (dim_setting > 1)
+ return;
+
+ print_on_off(rd, "adaptive-moderation", dim_setting);
+}
+
static int res_cq_line(struct rd *rd, const char *name, int idx,
struct nlattr **nla_line)
{
@@ -97,6 +111,7 @@ static int res_cq_line(struct rd *rd, const char *name, int idx,
res_print_uint(rd, "users", users,
nla_line[RDMA_NLDEV_ATTR_RES_USECNT]);
print_poll_ctx(rd, poll_ctx, nla_line[RDMA_NLDEV_ATTR_RES_POLL_CTX]);
+ print_cq_dim_setting(rd, nla_line[RDMA_NLDEV_ATTR_DEV_DIM]);
res_print_uint(rd, "ctxn", ctxn, nla_line[RDMA_NLDEV_ATTR_RES_CTXN]);
res_print_uint(rd, "pid", pid, nla_line[RDMA_NLDEV_ATTR_RES_PID]);
print_comm(rd, comm, nla_line);
diff --git a/rdma/utils.c b/rdma/utils.c
index 95b669f3..37659011 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -449,6 +449,7 @@ static const enum mnl_attr_data_type nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
[RDMA_NLDEV_ATTR_STAT_MODE] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_STAT_RES] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_STAT_AUTO_MODE_MASK] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DEV_DIM] = MNL_TYPE_U8,
};
int rd_attr_check(const struct nlattr *attr, int *typep)
@@ -789,6 +790,11 @@ static int print_driver_string(struct rd *rd, const char *key_str,
}
}
+void print_on_off(struct rd *rd, const char *key_str, bool on)
+{
+ print_driver_string(rd, key_str, (on) ? "on":"off");
+}
+
static int print_driver_s32(struct rd *rd, const char *key_str, int32_t val,
enum rdma_nldev_print_type print_type)
{
--
2.20.1
^ permalink raw reply related
* [PATCH iproute2-rc 2/2] rdma: Document adaptive-moderation
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
In-Reply-To: <20190729074226.4335-1-leon@kernel.org>
From: Yamin Friedman <yaminf@mellanox.com>
Add document of setting the adaptive-moderation for the ib device.
Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
man/man8/rdma-dev.8 | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/man/man8/rdma-dev.8 b/man/man8/rdma-dev.8
index e77e7cd0..368cdc7c 100644
--- a/man/man8/rdma-dev.8
+++ b/man/man8/rdma-dev.8
@@ -34,11 +34,17 @@ rdma-dev \- RDMA device configuration
.BR netns
.BR NSNAME
+.ti -8
+.B rdma dev set
+.RI "[ " DEV " ]"
+.BR adaptive-moderation
+.BR [on/off]
+
.ti -8
.B rdma dev help
.SH "DESCRIPTION"
-.SS rdma dev set - rename RDMA device or set network namespace
+.SS rdma dev set - rename RDMA device or set network namespace or set RDMA device adaptive-moderation
.SS rdma dev show - display RDMA device attributes
@@ -70,6 +76,14 @@ Changes the network namespace of RDMA device to foo where foo is
previously created using iproute2 ip command.
.RE
.PP
+rdma dev set mlx5_3 adaptive-moderation [on/off]
+.RS 4
+Sets the state of adaptive interrupt moderation for the RDMA device.
+.RE
+.RS 4
+This is a global setting for the RDMA device but the value is printed for each CQ individually because the state is constant from CQ allocation.
+.RE
+.PP
.SH SEE ALSO
.BR ip (8),
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 1/1] qed[net-next] Add new ethtool supported port types based on media.
From: Rahul Verma @ 2019-07-29 7:49 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
Supported ports in ethtool <eth1> are displayed based on media type.
For media type fibre and twinaxial, port type is "FIBRE". Media type
Base-T is "TP" and media KR is "Backplane".
Signed-off-by: Rahul Verma <rahulv@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 3 ++-
include/linux/qed/qed_if.h | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..e5ac8bd 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1688,6 +1688,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
switch (media_type) {
case MEDIA_DA_TWINAX:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
/* For DAC media multiple speed capabilities are supported*/
@@ -1707,6 +1708,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
*if_capability |= QED_LM_100000baseCR4_Full_BIT;
break;
case MEDIA_BASE_T:
+ *if_capability |= QED_LM_TP_BIT;
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_EXT_PHY) {
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
@@ -1718,6 +1720,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
}
}
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_MODULE) {
+ *if_capability |= QED_LM_FIBRE_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_1000BASET)
*if_capability |= QED_LM_1000baseT_Full_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_10G_BASET)
@@ -1728,6 +1731,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
case MEDIA_SFPP_10G_FIBER:
case MEDIA_XFP_FIBER:
case MEDIA_MODULE_FIBER:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
if ((tcvr_type == ETH_TRANSCEIVER_TYPE_1G_LX) ||
@@ -1770,6 +1774,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
break;
case MEDIA_KR:
+ *if_capability |= QED_LM_Backplane_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
if (capability &
@@ -1821,7 +1826,6 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->link_up = true;
/* TODO - at the moment assume supported and advertised speed equal */
- if_link->supported_caps = QED_LM_FIBRE_BIT;
if (link_caps.default_speed_autoneg)
if_link->supported_caps |= QED_LM_Autoneg_BIT;
if (params.pause.autoneg ||
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index e85f9fe..abcee47 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -424,12 +424,13 @@ struct qede_link_mode_mapping {
};
static const struct qede_link_mode_mapping qed_lm_map[] = {
+ {QED_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT},
{QED_LM_Autoneg_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT},
{QED_LM_Asym_Pause_BIT, ETHTOOL_LINK_MODE_Asym_Pause_BIT},
{QED_LM_Pause_BIT, ETHTOOL_LINK_MODE_Pause_BIT},
{QED_LM_1000baseT_Full_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
{QED_LM_10000baseT_Full_BIT, ETHTOOL_LINK_MODE_10000baseT_Full_BIT},
- {QED_LM_2500baseX_Full_BIT, ETHTOOL_LINK_MODE_2500baseX_Full_BIT},
+ {QED_LM_TP_BIT, ETHTOOL_LINK_MODE_TP_BIT},
{QED_LM_Backplane_BIT, ETHTOOL_LINK_MODE_Backplane_BIT},
{QED_LM_1000baseKX_Full_BIT, ETHTOOL_LINK_MODE_1000baseKX_Full_BIT},
{QED_LM_10000baseKX4_Full_BIT, ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT},
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index eef02e6..2302136 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -689,7 +689,7 @@ enum qed_link_mode_bits {
QED_LM_40000baseLR4_Full_BIT = BIT(9),
QED_LM_50000baseKR2_Full_BIT = BIT(10),
QED_LM_100000baseKR4_Full_BIT = BIT(11),
- QED_LM_2500baseX_Full_BIT = BIT(12),
+ QED_LM_TP_BIT = BIT(12),
QED_LM_Backplane_BIT = BIT(13),
QED_LM_1000baseKX_Full_BIT = BIT(14),
QED_LM_10000baseKX4_Full_BIT = BIT(15),
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 7:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729074125.GB2211@nanopsycho>
On 2019/7/29 15:41, Jiri Pirko wrote:
> 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.
Thanks for the explanation.
I will add it and submit a v2 patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* [PATCH v2] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 8:00 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
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.
Fixes: 79bdc4c862af ("codel: generalize the implementation")
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
v2:
* Add a fix tag.
Thank Jiri Pirko for helpful advice.
---
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 related
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Steffen Klassert @ 2019-07-29 8:03 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <464bb93d-75b2-c21b-ee32-25a10ff61622@gmail.com>
On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
> NULL.
We don't have a xfrm_policy() function, and as said already the
line numbers does not help much as long as you don't say which
tree/branch this is and which commit is the head commit.
> 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.
I guess you refer to xfrm_bundle_ok(). The dst pointer
is reoaded after the loop, so the dereferenced pointer
is not the one that had NULL at dst->xfrm.
>
> 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.
I'd suggest you to manually review the reports of your
tool and to fix the tool accordingly.
^ permalink raw reply
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Jia-Ju Bai @ 2019-07-29 8:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <20190729080341.GJ2879@gauss3.secunet.de>
On 2019/7/29 16:03, Steffen Klassert wrote:
> On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
>> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
>> NULL.
> We don't have a xfrm_policy() function, and as said already the
> line numbers does not help much as long as you don't say which
> tree/branch this is and which commit is the head commit.
>
>> 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.
> I guess you refer to xfrm_bundle_ok(). The dst pointer
> is reoaded after the loop, so the dereferenced pointer
> is not the one that had NULL at dst->xfrm.
>
>> 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.
> I'd suggest you to manually review the reports of your
> tool and to fix the tool accordingly.
Oh, sorry for my mistakes.
I have found that dst is updated:
dst = &xdst->u.dst;
I will fix my tool, thanks.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
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