* Re: [PATCH] net/phy: fix DP83865 10 Mbps HDX loopback disable function
From: Andrew Lunn @ 2019-09-18 14:19 UTC (permalink / raw)
To: Peter Mamonov; +Cc: Florian Fainelli, netdev, linux-kernel
In-Reply-To: <20190918140340.21032-1-pmamonov@gmail.com>
On Wed, Sep 18, 2019 at 05:03:40PM +0300, Peter Mamonov wrote:
> According to the DP83865 datasheet "The 10 Mbps HDX loopback can be
> disabled in the expanded memory register 0x1C0.1." The driver erroneously
> used bit 0 instead of bit 1.
>
> Signed-off-by: Peter Mamonov <pmamonov@gmail.com>
> ---
> drivers/net/phy/national.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/national.c b/drivers/net/phy/national.c
> index 2addf1d3f619..4892e785dbf3 100644
> --- a/drivers/net/phy/national.c
> +++ b/drivers/net/phy/national.c
> @@ -110,11 +110,14 @@ static void ns_giga_speed_fallback(struct phy_device *phydev, int mode)
>
> static void ns_10_base_t_hdx_loopack(struct phy_device *phydev, int disable)
> {
> + u16 lb_dis = 1 << 1;
Hi Peter
Please use the BIT() macro.
> +
> if (disable)
> - ns_exp_write(phydev, 0x1c0, ns_exp_read(phydev, 0x1c0) | 1);
> + ns_exp_write(phydev, 0x1c0,
> + ns_exp_read(phydev, 0x1c0) | lb_dis);
> else
> ns_exp_write(phydev, 0x1c0,
> - ns_exp_read(phydev, 0x1c0) & 0xfffe);
> + ns_exp_read(phydev, 0x1c0) & ~lb_dis);
>
> pr_debug("10BASE-T HDX loopback %s\n",
> (ns_exp_read(phydev, 0x1c0) & 0x0001) ? "off" : "on");
Isn't this also wrong?
Andrew
^ permalink raw reply
* RE: [PATCH] ethernet: Use devm_platform_ioremap_resource() in three functions
From: Radhey Shyam Pandey @ 2019-09-18 14:16 UTC (permalink / raw)
To: Markus Elfring, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David S. Miller,
Hans Ulli Kroll, Hauke Mehrtens, Linus Walleij, Michal Simek
Cc: LKML, kernel-janitors@vger.kernel.org, Bartosz Golaszewski,
Himanshu Jha
In-Reply-To: <af65355e-c2f8-9142-4d0b-6903f23a98b2@web.de>
> -----Original Message-----
> From: Markus Elfring <Markus.Elfring@web.de>
> Sent: Wednesday, September 18, 2019 7:01 PM
> To: netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org; David S.
> Miller <davem@davemloft.net>; Hans Ulli Kroll <ulli.kroll@googlemail.com>;
> Hauke Mehrtens <hauke@hauke-m.de>; Linus Walleij
> <linus.walleij@linaro.org>; Michal Simek <michals@xilinx.com>; Radhey
> Shyam Pandey <radheys@xilinx.com>
> Cc: LKML <linux-kernel@vger.kernel.org>; kernel-janitors@vger.kernel.org;
> Bartosz Golaszewski <bgolaszewski@baylibre.com>; Himanshu Jha
> <himanshujha199640@gmail.com>
> Subject: [PATCH] ethernet: Use devm_platform_ioremap_resource() in three
> functions
Prefer using a separate patch for each driver. Also skip mentioning
"three functions" in commit description.
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 15:15:06 +0200
>
> Simplify these function implementations by using a known wrapper function.
Minor nit- Better to mention about these funcs in commit description.
Something like- uses devm_platform_ioremap_resource() instead of using
platform_get_resource() and devm_ioremap_resource() together to simplify.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/net/ethernet/cortina/gemini.c | 6 +-----
> drivers/net/ethernet/lantiq_xrx200.c | 11 +----------
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 +--------
> 3 files changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ethernet/cortina/gemini.c
> b/drivers/net/ethernet/cortina/gemini.c
> index e736ce2c58ca..f009415ee4d8 100644
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
> @@ -2549,17 +2549,13 @@ static int gemini_ethernet_probe(struct
> platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct gemini_ethernet *geth;
> unsigned int retry = 5;
> - struct resource *res;
> u32 val;
>
> /* Global registers */
> geth = devm_kzalloc(dev, sizeof(*geth), GFP_KERNEL);
> if (!geth)
> return -ENOMEM;
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENODEV;
> - geth->base = devm_ioremap_resource(dev, res);
> + geth->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(geth->base))
> return PTR_ERR(geth->base);
> geth->dev = dev;
> diff --git a/drivers/net/ethernet/lantiq_xrx200.c
> b/drivers/net/ethernet/lantiq_xrx200.c
> index 900affbdcc0e..0a7ea45b9e59 100644
> --- a/drivers/net/ethernet/lantiq_xrx200.c
> +++ b/drivers/net/ethernet/lantiq_xrx200.c
> @@ -424,7 +424,6 @@ static int xrx200_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - struct resource *res;
> struct xrx200_priv *priv;
> struct net_device *net_dev;
> const u8 *mac;
> @@ -443,15 +442,7 @@ static int xrx200_probe(struct platform_device *pdev)
> SET_NETDEV_DEV(net_dev, dev);
> net_dev->min_mtu = ETH_ZLEN;
> net_dev->max_mtu = XRX200_DMA_DATA_LEN;
> -
> - /* load the memory ranges */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get resources\n");
> - return -ENOENT;
> - }
> -
> - priv->pmac_reg = devm_ioremap_resource(dev, res);
> + priv->pmac_reg = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->pmac_reg)) {
> dev_err(dev, "failed to request and remap io ranges\n");
> return PTR_ERR(priv->pmac_reg);
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 4fc627fb4d11..92783aaaa0a2 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1787,14 +1787,7 @@ static int axienet_probe(struct platform_device
> *pdev)
> of_node_put(np);
> lp->eth_irq = platform_get_irq(pdev, 0);
> } else {
> - /* Check for these resources directly on the Ethernet node. */
> - struct resource *res = platform_get_resource(pdev,
> -
> IORESOURCE_MEM, 1);
> - if (!res) {
> - dev_err(&pdev->dev, "unable to get DMA memory
> resource\n");
> - goto free_netdev;
> - }
> - lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
> + lp->dma_regs = devm_platform_ioremap_resource(pdev, 1);
> lp->rx_irq = platform_get_irq(pdev, 1);
> lp->tx_irq = platform_get_irq(pdev, 0);
> lp->eth_irq = platform_get_irq(pdev, 2);
> --
> 2.23.0
^ permalink raw reply
* [PATCH] net/phy: fix DP83865 10 Mbps HDX loopback disable function
From: Peter Mamonov @ 2019-09-18 14:03 UTC (permalink / raw)
To: andrew; +Cc: Peter Mamonov, Florian Fainelli, netdev, linux-kernel
According to the DP83865 datasheet "The 10 Mbps HDX loopback can be
disabled in the expanded memory register 0x1C0.1." The driver erroneously
used bit 0 instead of bit 1.
Signed-off-by: Peter Mamonov <pmamonov@gmail.com>
---
drivers/net/phy/national.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/national.c b/drivers/net/phy/national.c
index 2addf1d3f619..4892e785dbf3 100644
--- a/drivers/net/phy/national.c
+++ b/drivers/net/phy/national.c
@@ -110,11 +110,14 @@ static void ns_giga_speed_fallback(struct phy_device *phydev, int mode)
static void ns_10_base_t_hdx_loopack(struct phy_device *phydev, int disable)
{
+ u16 lb_dis = 1 << 1;
+
if (disable)
- ns_exp_write(phydev, 0x1c0, ns_exp_read(phydev, 0x1c0) | 1);
+ ns_exp_write(phydev, 0x1c0,
+ ns_exp_read(phydev, 0x1c0) | lb_dis);
else
ns_exp_write(phydev, 0x1c0,
- ns_exp_read(phydev, 0x1c0) & 0xfffe);
+ ns_exp_read(phydev, 0x1c0) & ~lb_dis);
pr_debug("10BASE-T HDX loopback %s\n",
(ns_exp_read(phydev, 0x1c0) & 0x0001) ? "off" : "on");
--
2.23.0
^ permalink raw reply related
* dsa traffic priorization
From: Sascha Hauer @ 2019-09-18 14:02 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, kernel
Hi All,
We have a customer using a Marvell 88e6240 switch with Ethercat on one port and
regular network traffic on another port. The customer wants to configure two things
on the switch: First Ethercat traffic shall be priorized over other network traffic
(effectively prioritizing traffic based on port). Second the ethernet controller
in the CPU is not able to handle full bandwidth traffic, so the traffic to the CPU
port shall be rate limited.
For reference the patch below configures the switch to their needs. Now the question
is how this can be implemented in a way suitable for mainline. It looks like the per
port priority mapping for VLAN tagged packets could be done via ip link add link ...
ingress-qos-map QOS-MAP. How the default priority would be set is unclear to me.
The other part of the problem seems to be that the CPU port has no network device
representation in Linux, so there's no interface to configure the egress limits via tc.
This has been discussed before, but it seems there hasn't been any consensous regarding how
we want to proceed?
Sascha
-----------------------------8<-----------------------------------
drivers/net/dsa/mv88e6xxx/chip.c | 54 +++++++++++++++++++-
drivers/net/dsa/mv88e6xxx/port.c | 87 ++++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/port.h | 19 +++++++
3 files changed, 159 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index d0a97eb73a37..2a15cf259d04 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2090,7 +2090,9 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
{
struct dsa_switch *ds = chip->ds;
int err;
+ u16 addr;
u16 reg;
+ u16 val;
chip->ports[port].chip = chip;
chip->ports[port].port = port;
@@ -2246,7 +2248,57 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
/* Default VLAN ID and priority: don't set a default VLAN
* ID, and set the default packet priority to zero.
*/
- return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_DEFAULT_VLAN, 0);
+ err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_DEFAULT_VLAN, 0);
+ if (err)
+ return err;
+
+#define SWITCH_CPU_PORT 5
+#define SWITCH_ETHERCAT_PORT 3
+
+ /* set the egress rate */
+ switch (port) {
+ case SWITCH_CPU_PORT:
+ err = mv88e6xxx_port_set_egress_rate(chip, port,
+ MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_FRAME, 30000);
+ break;
+ default:
+ err = mv88e6xxx_port_set_egress_rate(chip, port,
+ MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_FRAME, 0);
+ break;
+ }
+
+ if (err)
+ return err;
+
+ /* set the output queue usage */
+ switch (port) {
+ case SWITCH_CPU_PORT:
+ err = mv88e6xxx_port_set_output_queue_schedule(chip, port,
+ MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_Q3_STRICT);
+ break;
+ default:
+ err = mv88e6xxx_port_set_output_queue_schedule(chip, port,
+ MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_NONE_STRICT);
+ break;
+ }
+
+ if (err)
+ return err;
+
+ /* set the default QPri */
+ switch (port) {
+ case SWITCH_ETHERCAT_PORT:
+ err = mv88e6xxx_port_set_default_qpri(chip, port, 3);
+ break;
+ default:
+ err = mv88e6xxx_port_set_default_qpri(chip, port, 2);
+ break;
+ }
+
+ if (err)
+ return err;
+
+ return 0;
}
static int mv88e6xxx_port_enable(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 04309ef0a1cc..e03f24308f15 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -1147,6 +1147,22 @@ int mv88e6165_port_set_jumbo_size(struct mv88e6xxx_chip *chip, int port,
return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_CTL2, reg);
}
+int mv88e6xxx_port_set_default_qpri(struct mv88e6xxx_chip *chip, int port, int qpri)
+{
+ u16 reg;
+ int err;
+
+ err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_CTL2, ®);
+ if (err)
+ return err;
+
+ reg &= ~MV88E6XXX_PORT_CTL2_DEF_QPRI_MASK;
+ reg |= (qpri << 1) & MV88E6XXX_PORT_CTL2_DEF_QPRI_MASK;
+ reg |= MV88E6XXX_PORT_CTL2_USE_DEF_QPRI;
+
+ return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_CTL2, reg);
+}
+
/* Offset 0x09: Port Rate Control */
int mv88e6095_port_egress_rate_limiting(struct mv88e6xxx_chip *chip, int port)
@@ -1161,6 +1177,77 @@ int mv88e6097_port_egress_rate_limiting(struct mv88e6xxx_chip *chip, int port)
0x0001);
}
+int mv88e6xxx_port_set_output_queue_schedule(struct mv88e6xxx_chip *chip, int port,
+ u16 schedule)
+{
+ u16 reg;
+ int err;
+
+ err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_EGRESS_RATE_CTL2, ®);
+ if (err)
+ return err;
+
+ reg &= ~MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_MASK;
+ reg |= schedule;
+
+ return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_EGRESS_RATE_CTL2, reg);
+}
+
+static int _mv88e6xxx_egress_rate_calc_frames(u32 rate, u16 *egress_rate_val)
+{
+ const volatile u32 scale_factor = (1000 * 1000 * 1000);
+ volatile u32 u;
+
+ if (rate > 1488000)
+ return EINVAL;
+
+ if (rate < 7600)
+ return EINVAL;
+
+ u = 32 * rate;
+ u = scale_factor / u; /* scale_factor used to convert 32s into 32ns */
+
+ *egress_rate_val = (u16)u;
+
+ return 0;
+}
+
+int mv88e6xxx_port_set_egress_rate(struct mv88e6xxx_chip *chip, int port, u16 type,
+ u32 rate)
+{
+ u16 reg;
+ int err;
+ u16 egress_rate_val;
+
+ err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_EGRESS_RATE_CTL2, ®);
+ if (err)
+ return err;
+
+ reg &= ~MV88E6XXX_PORT_EGRESS_RATE_CTL2_RATE_MASK;
+
+ if (rate) {
+ reg &= ~MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_MASK;
+ reg |= type;
+
+ switch (type) {
+ case MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_FRAME:
+ err = _mv88e6xxx_egress_rate_calc_frames(rate, &egress_rate_val);
+ if (err)
+ return err;
+ reg |= egress_rate_val & 0x0FFF;
+ break;
+ case MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_L1:
+ case MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_L2:
+ case MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_L3:
+ return EINVAL; /* ToDo */
+ default:
+ return EINVAL;
+ }
+ }
+
+ return mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_EGRESS_RATE_CTL2, reg);
+}
+
/* Offset 0x0C: Port ATU Control */
int mv88e6xxx_port_disable_learn_limit(struct mv88e6xxx_chip *chip, int port)
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index 8d5a6cd6fb19..cdd057c52ab8 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -197,6 +197,8 @@
#define MV88E6XXX_PORT_CTL2_DEFAULT_FORWARD 0x0040
#define MV88E6XXX_PORT_CTL2_EGRESS_MONITOR 0x0020
#define MV88E6XXX_PORT_CTL2_INGRESS_MONITOR 0x0010
+#define MV88E6XXX_PORT_CTL2_USE_DEF_QPRI 0x0008
+#define MV88E6XXX_PORT_CTL2_DEF_QPRI_MASK 0x0006
#define MV88E6095_PORT_CTL2_CPU_PORT_MASK 0x000f
/* Offset 0x09: Egress Rate Control */
@@ -204,6 +206,17 @@
/* Offset 0x0A: Egress Rate Control 2 */
#define MV88E6XXX_PORT_EGRESS_RATE_CTL2 0x0a
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_MASK 0xC000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_FRAME 0x0000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_L1 0x4000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_L2 0x8000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_COUNT_MODE_L3 0xC000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_MASK 0x3000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_NONE_STRICT 0x0000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_Q3_STRICT 0x1000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_Q3_Q2_STRICT 0x2000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_SCHEDULE_ALL_STRICT 0x3000
+#define MV88E6XXX_PORT_EGRESS_RATE_CTL2_RATE_MASK 0x0FFF
/* Offset 0x0B: Port Association Vector */
#define MV88E6XXX_PORT_ASSOC_VECTOR 0x0b
@@ -326,8 +339,14 @@ int mv88e6xxx_port_set_message_port(struct mv88e6xxx_chip *chip, int port,
bool message_port);
int mv88e6165_port_set_jumbo_size(struct mv88e6xxx_chip *chip, int port,
size_t size);
+int mv88e6xxx_port_set_default_qpri(struct mv88e6xxx_chip *chip, int port,
+ int qpri);
int mv88e6095_port_egress_rate_limiting(struct mv88e6xxx_chip *chip, int port);
int mv88e6097_port_egress_rate_limiting(struct mv88e6xxx_chip *chip, int port);
+int mv88e6xxx_port_set_output_queue_schedule(struct mv88e6xxx_chip *chip, int port,
+ u16 schedule);
+int mv88e6xxx_port_set_egress_rate(struct mv88e6xxx_chip *chip, int port,
+ u16 type, u32 rate);
int mv88e6097_port_pause_limit(struct mv88e6xxx_chip *chip, int port, u8 in,
u8 out);
int mv88e6390_port_pause_limit(struct mv88e6xxx_chip *chip, int port, u8 in,
--
2.23.0
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* RE: [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
From: zhangsha (A) @ 2019-09-18 13:35 UTC (permalink / raw)
To: jay.vosburgh@canonical.com, vfalico@gmail.com, andy@greyhouse.net,
davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, yuehaibing, hunongda,
Chenzhendong (alex)
In-Reply-To: <20190918130620.8556-1-zhangsha.zhang@huawei.com>
> -----Original Message-----
> From: zhangsha (A)
> Sent: 2019年9月18日 21:06
> To: jay.vosburgh@canonical.com; vfalico@gmail.com; andy@greyhouse.net;
> davem@davemloft.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> yuehaibing <yuehaibing@huawei.com>; hunongda <hunongda@huawei.com>;
> Chenzhendong (alex) <alex.chen@huawei.com>; zhangsha (A)
> <zhangsha.zhang@huawei.com>
> Subject: [PATCH v3] bonding: force enable lacp port after link state recovery for
> 802.3ad
>
> From: Sha Zhang <zhangsha.zhang@huawei.com>
>
> After the commit 334031219a84 ("bonding/802.3ad: fix slave link initialization
> transition states") merged, the slave's link status will be changed to
> BOND_LINK_FAIL from BOND_LINK_DOWN in the following scenario:
> - Driver reports loss of carrier and
> bonding driver receives NETDEV_DOWN notifier
> - slave's duplex and speed is zerod and
> its port->is_enabled is cleard to 'false';
> - Driver reports link recovery and
> bonding driver receives NETDEV_UP notifier;
> - If speed/duplex getting failed here, the link status
> will be changed to BOND_LINK_FAIL;
> - The MII monotor later recover the slave's speed/duplex
> and set link status to BOND_LINK_UP, but remains
> the 'port->is_enabled' to 'false'.
>
> In this scenario, the lacp port will not be enabled even its speed and duplex are
> valid. The bond will not send LACPDU's, and its state is 'AD_STATE_DEFAULTED'
> forever. The simplest fix I think is to call bond_3ad_handle_link_change() in
> bond_miimon_commit, this function can enable lacp after port slave speed
> check.
> As enabled, the lacp port can run its state machine normally after link recovery.
>
> Signed-off-by: Sha Zhang <zhangsha.zhang@huawei.com>
> ---
> drivers/net/bonding/bond_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c index 931d9d9..76324a5 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding
> *bond)
> */
> if (BOND_MODE(bond) == BOND_MODE_8023AD &&
> slave->link == BOND_LINK_UP)
> -
> bond_3ad_adapter_speed_duplex_changed(slave);
> + bond_3ad_handle_link_change(slave,
> + BOND_LINK_UP);
> continue;
>
> case BOND_LINK_UP:
Hi, David,
I have replied your email for a while, I guess you may miss my email, so I resend it.
The following link address is the last email, please review the new one again, thank you.
https://patchwork.ozlabs.org/patch/1151915/
Last time, you doubted this is a driver specific problem,
I prefer to believe it's not because I find the commit 4d2c0cda,
its log says " Some NIC drivers don't have correct speed/duplex
settings at the time they send NETDEV_UP notification ...".
Anyway, I think the lacp status should be fixed correctly,
since link-monitoring (miimon) set SPEED/DUPLEX right here.
> --
> 1.8.3.1
^ permalink raw reply
* Re: Bug report (with fix) for DEC Tulip driver (de2104x.c)
From: Thomas Bogendoerfer @ 2019-09-18 13:27 UTC (permalink / raw)
To: Helge Deller
Cc: John David Anglin, Arlie Davis, Andrew Lunn, netdev, linux-parisc
In-Reply-To: <f71e9773-5cfb-f20b-956f-d98b11a5d4a7@gmx.de>
On Wed, Sep 18, 2019 at 07:56:16AM +0200, Helge Deller wrote:
> On 18.09.19 00:51, John David Anglin wrote:
> > On 2019-09-17 5:36 p.m., Arlie Davis wrote:
> >> Likewise, I'm at a loss for testing with real hardware. It's hard to
> >> find such things, now.
> > How does de2104x compare to ds2142/43? I have a c3750 with ds2142/43 tulip. Helge
> > or some others might have a machine with a de2104x.
>
> The machines we could test are
> * a C240 with a DS21140 tulip chip (Sven has one),
> * a C3000 or similiar with DS21142 and/or DS21143 (me).
>
> If the patch does not show any regressions, I'd suggest to
> apply it upstream.
2114x chips use a different driver, so it won't help here.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* [PATCH] ethernet: Use devm_platform_ioremap_resource() in three functions
From: Markus Elfring @ 2019-09-18 13:30 UTC (permalink / raw)
To: netdev, linux-arm-kernel, David S. Miller, Hans Ulli Kroll,
Hauke Mehrtens, Linus Walleij, Michal Simek, Radhey Shyam Pandey
Cc: LKML, kernel-janitors, Bartosz Golaszewski, Himanshu Jha
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 18 Sep 2019 15:15:06 +0200
Simplify these function implementations by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/cortina/gemini.c | 6 +-----
drivers/net/ethernet/lantiq_xrx200.c | 11 +----------
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 +--------
3 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index e736ce2c58ca..f009415ee4d8 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -2549,17 +2549,13 @@ static int gemini_ethernet_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct gemini_ethernet *geth;
unsigned int retry = 5;
- struct resource *res;
u32 val;
/* Global registers */
geth = devm_kzalloc(dev, sizeof(*geth), GFP_KERNEL);
if (!geth)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
- geth->base = devm_ioremap_resource(dev, res);
+ geth->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(geth->base))
return PTR_ERR(geth->base);
geth->dev = dev;
diff --git a/drivers/net/ethernet/lantiq_xrx200.c b/drivers/net/ethernet/lantiq_xrx200.c
index 900affbdcc0e..0a7ea45b9e59 100644
--- a/drivers/net/ethernet/lantiq_xrx200.c
+++ b/drivers/net/ethernet/lantiq_xrx200.c
@@ -424,7 +424,6 @@ static int xrx200_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- struct resource *res;
struct xrx200_priv *priv;
struct net_device *net_dev;
const u8 *mac;
@@ -443,15 +442,7 @@ static int xrx200_probe(struct platform_device *pdev)
SET_NETDEV_DEV(net_dev, dev);
net_dev->min_mtu = ETH_ZLEN;
net_dev->max_mtu = XRX200_DMA_DATA_LEN;
-
- /* load the memory ranges */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "failed to get resources\n");
- return -ENOENT;
- }
-
- priv->pmac_reg = devm_ioremap_resource(dev, res);
+ priv->pmac_reg = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->pmac_reg)) {
dev_err(dev, "failed to request and remap io ranges\n");
return PTR_ERR(priv->pmac_reg);
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4fc627fb4d11..92783aaaa0a2 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1787,14 +1787,7 @@ static int axienet_probe(struct platform_device *pdev)
of_node_put(np);
lp->eth_irq = platform_get_irq(pdev, 0);
} else {
- /* Check for these resources directly on the Ethernet node. */
- struct resource *res = platform_get_resource(pdev,
- IORESOURCE_MEM, 1);
- if (!res) {
- dev_err(&pdev->dev, "unable to get DMA memory resource\n");
- goto free_netdev;
- }
- lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
+ lp->dma_regs = devm_platform_ioremap_resource(pdev, 1);
lp->rx_irq = platform_get_irq(pdev, 1);
lp->tx_irq = platform_get_irq(pdev, 0);
lp->eth_irq = platform_get_irq(pdev, 2);
--
2.23.0
^ permalink raw reply related
* Re: [PATCH net] iwlwifi: add dependency of THERMAL with IWLMVM
From: Luciano Coelho @ 2019-09-18 13:17 UTC (permalink / raw)
To: Kalle Valo, Mao Wenan
Cc: johannes.berg, emmanuel.grumbach, linuxwifi, davem,
linux-wireless, netdev, linux-kernel, kernel-janitors
In-Reply-To: <875zlpbvks.fsf@kamboji.qca.qualcomm.com>
On Wed, 2019-09-18 at 16:08 +0300, Kalle Valo wrote:
> Mao Wenan <maowenan@huawei.com> writes:
>
> > If CONFIG_IWLMVM=y, CONFIG_THERMAL=n, below error can be found:
> > drivers/net/wireless/intel/iwlwifi/mvm/fw.o: In function `iwl_mvm_up':
> > fw.c:(.text+0x2c26): undefined reference to `iwl_mvm_send_temp_report_ths_cmd'
> > make: *** [vmlinux] Error 1
> >
> > After commit 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal
> > monitoring regardless of CONFIG_THERMAL"), iwl_mvm_up()
> > calls iwl_mvm_send_temp_report_ths_cmd(), but this function
> > is under CONFIG_THERMAL, which is depended on CONFIG_THERMAL.
> >
> > Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
> > Signed-off-by: Mao Wenan <maowenan@huawei.com>
>
> Luca, should I apply this directly to wireless-drivers?
No, this patch defeats the point of the patch it fixes.
We have a proper fix already internally, which I haven't sent out yet,
that moves a couple of #ifdef's around to solve the issue. I'll send
the patch in a sec.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] drivers:staging:qlge: Removed unnecessary variable
From: Aliasgar Surti @ 2019-09-18 13:16 UTC (permalink / raw)
To: manishc, GR-Linux-NIC-Dev, gregkh, netdev, devel; +Cc: Aliasgar Surti
From: Aliasgar Surti <aliasgar.surti500@gmail.com>
coccicheck reported warning for unnecessary variable used.
This patch fixes the same by removing the variable and
returning value directly.
Signed-off-by: Aliasgar Surti <aliasgar.surti500@gmail.com>
---
drivers/staging/qlge/qlge_dbg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/qlge/qlge_dbg.c b/drivers/staging/qlge/qlge_dbg.c
index 31389ab..5599525 100644
--- a/drivers/staging/qlge/qlge_dbg.c
+++ b/drivers/staging/qlge/qlge_dbg.c
@@ -389,7 +389,6 @@ static int ql_get_xgmac_regs(struct ql_adapter *qdev, u32 *buf,
static int ql_get_ets_regs(struct ql_adapter *qdev, u32 *buf)
{
- int status = 0;
int i;
for (i = 0; i < 8; i++, buf++) {
@@ -402,7 +401,7 @@ static int ql_get_ets_regs(struct ql_adapter *qdev, u32 *buf)
*buf = ql_read32(qdev, CNA_ETS);
}
- return status;
+ return 0;
}
static void ql_get_intr_states(struct ql_adapter *qdev, u32 *buf)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] iwlwifi: add dependency of THERMAL with IWLMVM
From: Kalle Valo @ 2019-09-18 13:08 UTC (permalink / raw)
To: Mao Wenan
Cc: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
davem, linux-wireless, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190918122815.155657-1-maowenan@huawei.com>
Mao Wenan <maowenan@huawei.com> writes:
> If CONFIG_IWLMVM=y, CONFIG_THERMAL=n, below error can be found:
> drivers/net/wireless/intel/iwlwifi/mvm/fw.o: In function `iwl_mvm_up':
> fw.c:(.text+0x2c26): undefined reference to `iwl_mvm_send_temp_report_ths_cmd'
> make: *** [vmlinux] Error 1
>
> After commit 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal
> monitoring regardless of CONFIG_THERMAL"), iwl_mvm_up()
> calls iwl_mvm_send_temp_report_ths_cmd(), but this function
> is under CONFIG_THERMAL, which is depended on CONFIG_THERMAL.
>
> Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Luca, should I apply this directly to wireless-drivers?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
From: zhangsha.zhang @ 2019-09-18 13:06 UTC (permalink / raw)
To: jay.vosburgh, vfalico, andy, davem, netdev, linux-kernel,
yuehaibing, hunongda, alex.chen, zhangsha.zhang
From: Sha Zhang <zhangsha.zhang@huawei.com>
After the commit 334031219a84 ("bonding/802.3ad: fix slave link
initialization transition states") merged,
the slave's link status will be changed to BOND_LINK_FAIL
from BOND_LINK_DOWN in the following scenario:
- Driver reports loss of carrier and
bonding driver receives NETDEV_DOWN notifier
- slave's duplex and speed is zerod and
its port->is_enabled is cleard to 'false';
- Driver reports link recovery and
bonding driver receives NETDEV_UP notifier;
- If speed/duplex getting failed here, the link status
will be changed to BOND_LINK_FAIL;
- The MII monotor later recover the slave's speed/duplex
and set link status to BOND_LINK_UP, but remains
the 'port->is_enabled' to 'false'.
In this scenario, the lacp port will not be enabled even its speed
and duplex are valid. The bond will not send LACPDU's, and its
state is 'AD_STATE_DEFAULTED' forever. The simplest fix I think
is to call bond_3ad_handle_link_change() in bond_miimon_commit,
this function can enable lacp after port slave speed check.
As enabled, the lacp port can run its state machine normally
after link recovery.
Signed-off-by: Sha Zhang <zhangsha.zhang@huawei.com>
---
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 931d9d9..76324a5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding *bond)
*/
if (BOND_MODE(bond) == BOND_MODE_8023AD &&
slave->link == BOND_LINK_UP)
- bond_3ad_adapter_speed_duplex_changed(slave);
+ bond_3ad_handle_link_change(slave,
+ BOND_LINK_UP);
continue;
case BOND_LINK_UP:
--
1.8.3.1
^ permalink raw reply related
* [PATCH] bonding/802.3ad: fix slave initialization states race
From: Aleksei Zakharov @ 2019-09-18 13:05 UTC (permalink / raw)
To: netdev
Once a while, one of 802.3ad slaves fails to initialize and hangs in
BOND_LINK_FAIL state. Commit 334031219a84 ("bonding/802.3ad: fix slave
link initialization transition states") checks slave->last_link_up. But
link can still hang in weird state.
After physical link comes up it sends first two LACPDU messages and
doesn't work properly after that. It doesn't send or receive LACPDU.
Once it happens, the only message in dmesg is:
bond1: link status up again after 0 ms for interface eth2
This behavior can be reproduced (not every time):
1. Set slave link down
2. Wait for 1-3 seconds
3. Set slave link up
The fix is to check slave->link before setting it to BOND_LINK_FAIL or
BOND_LINK_DOWN state. If got invalid Speed/Dupex values and link is in
BOND_LINK_UP state, mark it as BOND_LINK_FAIL; otherwise mark it as
BOND_LINK_DOWN.
Fixes: 334031219a84 ("bonding/802.3ad: fix slave link initialization
transition states")
Signed-off-by: Aleksei Zakharov <zakharov.a.g@yandex.ru>
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 931d9d935686..a28776d8f33f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3135,7 +3135,7 @@ static int bond_slave_netdev_event(unsigned long event,
*/
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD) {
- if (slave->last_link_up)
+ if (slave->link == BOND_LINK_UP)
slave->link = BOND_LINK_FAIL;
else
slave->link = BOND_LINK_DOWN;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v7 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Simon Horman @ 2019-09-18 12:34 UTC (permalink / raw)
To: Lars Poeschel
Cc: Allison Randal, Greg Kroah-Hartman, Jilayne Lovejoy, Kate Stewart,
Thomas Gleixner, open list:NFC SUBSYSTEM, open list, Johan Hovold
In-Reply-To: <20190910093129.1844-1-poeschel@lemonage.de>
On Tue, Sep 10, 2019 at 11:31:21AM +0200, Lars Poeschel wrote:
> It is favourable to have one unified compatible string for devices that
> have multiple interfaces. So this adds simply "pn532" as the devicetree
> binding compatible string and makes a note that the old ones are
> deprecated.
Do you also need to update
Documentation/devicetree/bindings/net/nfc/pn533-i2c.txt
to both document the new compat string and deprecate the old ones?
> Cc: Johan Hovold <johan@kernel.org>
> Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
> ---
> Changes in v6:
> - Rebased the patch series on v5.3-rc5
>
> Changes in v3:
> - This patch is new in v3
>
> drivers/nfc/pn533/i2c.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> index 1832cd921ea7..1abd40398a5a 100644
> --- a/drivers/nfc/pn533/i2c.c
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -245,6 +245,11 @@ static int pn533_i2c_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id of_pn533_i2c_match[] = {
> + { .compatible = "nxp,pn532", },
> + /*
> + * NOTE: The use of the compatibles with the trailing "...-i2c" is
> + * deprecated and will be removed.
> + */
> { .compatible = "nxp,pn533-i2c", },
> { .compatible = "nxp,pn532-i2c", },
> {},
> --
> 2.23.0
>
^ permalink raw reply
* Re: divide error in cdc_ncm_update_rxtx_max
From: syzbot @ 2019-09-18 12:26 UTC (permalink / raw)
To: bjorn, linux-usb, netdev, oliver, syzkaller-bugs
In-Reply-To: <20190918120147.4520-1-bjorn@mork.no>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+ce366e2b8296e25d84f5@syzkaller.appspotmail.com
Tested on:
commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
dashboard link: https://syzkaller.appspot.com/bug?extid=ce366e2b8296e25d84f5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=114971b5600000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* [PATCH net,stable] usbnet: ignore endpoints with invalid wMaxPacketSize
From: Bjørn Mork @ 2019-09-18 12:17 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Oliver Neukum, Bjørn Mork
Endpoints with zero wMaxPacketSize are not usable for transferring
data. Ignore such endpoints when looking for valid in, out and
status pipes, to make the drivers more robust against invalid and
meaningless descriptors.
The wMaxPacketSize of these endpoints are used for memory allocations
and as divisors in many usbnet minidrivers. Avoiding zero is therefore
critical.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/usbnet.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 58952a79b05f..dbea2136d901 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -100,6 +100,11 @@ int usbnet_get_endpoints(struct usbnet *dev, struct usb_interface *intf)
int intr = 0;
e = alt->endpoint + ep;
+
+ /* ignore endpoints which cannot transfer data */
+ if (!usb_endpoint_maxp(&e->desc))
+ continue;
+
switch (e->desc.bmAttributes) {
case USB_ENDPOINT_XFER_INT:
if (!usb_endpoint_dir_in(&e->desc))
--
2.20.1
^ permalink raw reply related
* [PATCH net] iwlwifi: add dependency of THERMAL with IWLMVM
From: Mao Wenan @ 2019-09-18 12:28 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, kernel-janitors, Mao Wenan
If CONFIG_IWLMVM=y, CONFIG_THERMAL=n, below error can be found:
drivers/net/wireless/intel/iwlwifi/mvm/fw.o: In function `iwl_mvm_up':
fw.c:(.text+0x2c26): undefined reference to `iwl_mvm_send_temp_report_ths_cmd'
make: *** [vmlinux] Error 1
After commit 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal
monitoring regardless of CONFIG_THERMAL"), iwl_mvm_up()
calls iwl_mvm_send_temp_report_ths_cmd(), but this function
is under CONFIG_THERMAL, which is depended on CONFIG_THERMAL.
Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig
index 7dbc0d3..801aa0f 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -65,6 +65,7 @@ config IWLMVM
tristate "Intel Wireless WiFi MVM Firmware support"
select WANT_DEV_COREDUMP
depends on MAC80211
+ depends on THERMAL
help
This is the driver that supports the MVM firmware. The list
of the devices that use this firmware is available here:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] dt-bindings: net: remove un-implemented property
From: Rob Herring @ 2019-09-18 12:07 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel@vger.kernel.org, David Miller
In-Reply-To: <20190918111447.3084-1-alexandru.ardelean@analog.com>
On Wed, Sep 18, 2019 at 3:15 AM Alexandru Ardelean
<alexandru.ardelean@analog.com> wrote:
>
> The `adi,disable-energy-detect` property was implemented in an initial
> version of the `adin` driver series, but after a review it was discarded in
> favor of implementing the ETHTOOL_PHY_EDPD phy-tunable option.
>
> With the ETHTOOL_PHY_EDPD control, it's possible to disable/enable
> Energy-Detect-Power-Down for the `adin` PHY, so this device-tree is not
> needed.
>
> Fixes: 767078132ff9 ("dt-bindings: net: add bindings for ADIN PHY driver")
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> Documentation/devicetree/bindings/net/adi,adin.yaml | 7 -------
> 1 file changed, 7 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* hippi: dead code issue on skb->data DMA limitations check
From: Colin Ian King @ 2019-09-18 12:07 UTC (permalink / raw)
To: Jes Sorensen, David S. Miller, open list:HIPPI, netdev; +Cc: linux-kernel
Hi there,
Static analysis with Coverity has detected an issue in rr_init1() in
drivers/net/hippi/rrunner.c as follows:
CID 13516 (#1 of 1): Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: ((unsigned long)skb->data & 4095) >
18446744073709486295UL /* ~0xff28 */ is always false regardless of the
values of its operands. This occurs as the logical operand of if.
653 /*
654 * Sanity test to see if we conflict with the DMA
655 * limitations of the Roadrunner.
656 */
657 if ((((unsigned long)skb->data) & 0xfff) > ~65320)
CID 14371: Logically dead code (DEADCODE)
658 printk("skb alloc error\n");
659
Given that this check is currently dead code and it's been in the driver
for ages, should we just throw this check away or fix it? I'm not
entirely sure what the original intent was, so I'm not clear on a fix.
Colin
^ permalink raw reply
* [PATCH net,stable] cdc_ncm: fix divide-by-zero caused by invalid wMaxPacketSize
From: Bjørn Mork @ 2019-09-18 12:01 UTC (permalink / raw)
To: netdev
Cc: linux-usb, Oliver Neukum, Bjørn Mork,
syzbot+ce366e2b8296e25d84f5
Endpoints with zero wMaxPacketSize are not usable for transferring
data. Ignore such endpoints when looking for valid in, out and
status pipes, to make the driver more robust against invalid and
meaningless descriptors.
The wMaxPacketSize of the out pipe is used as divisor. So this change
fixes a divide-by-zero bug.
Reported-by: syzbot+ce366e2b8296e25d84f5@syzkaller.appspotmail.com
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
#syz test: https://github.com/google/kasan.git f0df5c1b
drivers/net/usb/cdc_ncm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 50c05d0f44cb..00cab3f43a4c 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -681,8 +681,12 @@ cdc_ncm_find_endpoints(struct usbnet *dev, struct usb_interface *intf)
u8 ep;
for (ep = 0; ep < intf->cur_altsetting->desc.bNumEndpoints; ep++) {
-
e = intf->cur_altsetting->endpoint + ep;
+
+ /* ignore endpoints which cannot transfer data */
+ if (!usb_endpoint_maxp(&e->desc))
+ continue;
+
switch (e->desc.bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) {
case USB_ENDPOINT_XFER_INT:
if (usb_endpoint_dir_in(&e->desc)) {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 13/14] samples: bpf: makefile: add sysroot support
From: Ivan Khoronzhuk @ 2019-09-18 11:09 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzYa7mwFLZWdS0EMf4m=s88a94z6p30mxN8Q9=erpE5=Xg@mail.gmail.com>
On Tue, Sep 17, 2019 at 10:23:57PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 4:00 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> Basically it only enables that was added by previous couple fixes.
>> Sysroot contains correct libs installed and its headers ofc. Useful
>
>Please, let's not use unnecessary abbreviations/slang. "Of course" is
>not too long and is a proper English, let's stick to it.
>
>> when working with NFC or virtual machine.
>>
>> Usage:
>>
>> clean (on demand)
>> make ARCH=arm -C samples/bpf clean
>> make ARCH=arm -C tools clean
>> make ARCH=arm clean
>>
>> configure and install headers:
>>
>> make ARCH=arm defconfig
>> make ARCH=arm headers_install
>>
>> build samples/bpf:
>> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- samples/bpf/ \
>> SYSROOT="path/to/sysroot"
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 133123d4c7d7..57ddf055d6c3 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -194,6 +194,11 @@ TPROGS_CFLAGS += -I$(srctree)/tools/lib/
>> TPROGS_CFLAGS += -I$(srctree)/tools/include
>> TPROGS_CFLAGS += -I$(srctree)/tools/perf
>>
>> +ifdef SYSROOT
>> +TPROGS_CFLAGS += --sysroot=${SYSROOT}
>> +TPROGS_LDFLAGS := -L${SYSROOT}/usr/lib
>
>Please stay consistent: $() instead of ${}?
Yes, thanks.
>
>> +endif
>> +
>> EXTRA_CXXFLAGS := $(TPROGS_CFLAGS)
>>
>> # options not valid for C++
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v3 bpf-next 11/14] libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf targets
From: Ivan Khoronzhuk @ 2019-09-18 11:05 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzZXNN_dhs=jUjtfCqtuV1bk9H=q5b07kVDQQsysjhF4cQ@mail.gmail.com>
On Tue, Sep 17, 2019 at 10:19:22PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 4:00 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them
>> correctly to build command, for instance when --sysroot is used or
>> external libraries are used, like -lelf, wich can be absent in
>> toolchain. This can be used for samples/bpf cross-compiling allowing
>> to get elf lib from sysroot.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> tools/lib/bpf/Makefile | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
>> index c6f94cffe06e..bccfa556ef4e 100644
>> --- a/tools/lib/bpf/Makefile
>> +++ b/tools/lib/bpf/Makefile
>> @@ -94,6 +94,10 @@ else
>> CFLAGS := -g -Wall
>> endif
>>
>> +ifdef EXTRA_CXXFLAGS
>> + CXXFLAGS := $(EXTRA_CXXFLAGS)
>> +endif
>> +
>> ifeq ($(feature-libelf-mmap), 1)
>> override CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
>> endif
>> @@ -176,8 +180,9 @@ $(BPF_IN): force elfdep bpfdep
>> $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
>>
>> $(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
>> - $(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
>> - -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
>> + $(QUIET_LINK)$(CC) $(LDFLAGS) \
>> + --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
>> + -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
>> @ln -sf $(@F) $(OUTPUT)libbpf.so
>> @ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION)
>>
>> @@ -185,7 +190,7 @@ $(OUTPUT)libbpf.a: $(BPF_IN)
>> $(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
>>
>> $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a
>> - $(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@
>> + $(QUIET_LINK)$(CXX) $(CXXFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@
>
>Instead of doing ifdef EXTRA_CXXFLAGS bit above, you can just include
>both $(CXXFLAGS) and $(EXTRA_CXXFLAGS), which will do the right thing
>(and is actually recommended my make documentation way to do this).
It's good practice to follow existent style, I've done similar way as for
CFLAGS + EXTRACFLAGS here, didn't want to verify it can impact on
smth else. And my goal is not to correct everything but embed my
functionality, series tool large w/o it.
>
>But actually, there is no need to use C++ compiler here,
>test_libbpf.cpp can just be plain C. Do you mind renaming it to .c and
>using C compiler instead?
Seems like, will try in next v.
>
>>
>> $(OUTPUT)libbpf.pc:
>> $(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v3 bpf-next 09/14] samples: bpf: makefile: use own flags but not host when cross compile
From: Ivan Khoronzhuk @ 2019-09-18 10:35 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzbuPnxAs0A=w60q0jTCy5pb2R-h0uEuT2tmvjsaj4DH4A@mail.gmail.com>
On Tue, Sep 17, 2019 at 04:42:07PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> While compile natively, the hosts cflags and ldflags are equal to ones
>> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should
>> have own, used for target arch. While verification, for arm, arm64 and
>> x86_64 the following flags were used alsways:
>>
>> -Wall
>> -O2
>> -fomit-frame-pointer
>> -Wmissing-prototypes
>> -Wstrict-prototypes
>>
>> So, add them as they were verified and used before adding
>> Makefile.target, but anyway limit it only for cross compile options as
>> for host can be some configurations when another options can be used,
>> So, for host arch samples left all as is, it allows to avoid potential
>> option mistmatches for existent environments.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 1579cc16a1c2..b5c87a8b8b51 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR)
>> TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR)
>> endif
>>
>> +ifdef CROSS_COMPILE
>> +TPROGS_CFLAGS += -Wall
>> +TPROGS_CFLAGS += -O2
>
>Specifying one arg per line seems like overkill, put them in one line?
Will combine.
>
>> +TPROGS_CFLAGS += -fomit-frame-pointer
>
>Why this one?
I've explained in commit msg. The logic is to have as much as close options
to have smiliar binaries. As those options are used before for hosts and kinda
cross builds - better follow same way.
>
>> +TPROGS_CFLAGS += -Wmissing-prototypes
>> +TPROGS_CFLAGS += -Wstrict-prototypes
>
>Are these in some way special that we want them in cross-compile mode only?
>
>All of those flags seem useful regardless of cross-compilation or not,
>shouldn't they be common? I'm a bit lost about the intent here...
They are common but split is needed to expose it at least. Also host for
different arches can have some own opts already used that shouldn't be present
for cross, better not mix it for safety.
>
>> +else
>> TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS)
>> TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS)
>> +endif
>> +
>> TPROGS_CFLAGS += -I$(objtree)/usr/include
>> TPROGS_CFLAGS += -I$(srctree)/tools/lib/bpf/
>> TPROGS_CFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Paolo Bonzini @ 2019-09-18 10:23 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China), netdev@vger.kernel.org,
yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, maz@kernel.org,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China),
nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <HE1PR0801MB1676F57B317AE85E3B934B32F48E0@HE1PR0801MB1676.eurprd08.prod.outlook.com>
On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
> Hi Paolo,
>
>> On 18/09/19 10:07, Jianyong Wu wrote:
>>> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
>>> + getnstimeofday(ts);
>>
>> This is not Y2038-safe. Please use ktime_get_real_ts64 instead, and split the
>> 64-bit seconds value between val[0] and val[1].
>>
> As far as I know, y2038-safe will only affect signed 32-bit integer,
> how does it affect 64-bit integer?
> And why split 64-bit number into two blocks is necessary?
val is an u32, not an u64. (And val[0], where you store the seconds, is
best treated as signed, since val[0] == -1 is returned for
SMCCC_RET_NOT_SUPPORTED).
>> However, it seems to me that the new function is not needed and you can
>> just use ktime_get_snapshot. You'll get the time in systime_snapshot->real
>> and the cycles value in systime_snapshot->cycles.
>
> See patch 5/6, I need both counter cycle and clocksource, ktime_get_snapshot seems only offer cycles.
No, patch 5/6 only needs the current clock (ptp_sc.cycles is never
accessed). So you could just use READ_ONCE(tk->tkr_mono.clock).
However, even then I don't think it is correct to use ptp_sc.cs blindly
in patch 5. I think there is a misunderstanding on the meaning of
system_counterval.cs as passed to get_device_system_crosststamp.
system_counterval.cs is not the active clocksource; it's the clocksource
on which system_counterval.cycles is based.
Hypothetically, the clocksource could be one for which ptp_sc.cycles is
_not_ a cycle value. If you set system_counterval.cs to the system
clocksource, get_device_system_crosststamp will return a bogus value.
So system_counterval.cs should be set to something like
&clocksource_counter (from drivers/clocksource/arm_arch_timer.c).
Perhaps the right place to define kvm_arch_ptp_get_clock_fn is in that file?
>>> + get_current_counterval(&sc);
>>> + val[0] = ts->tv_sec;
>>> + val[1] = ts->tv_nsec;
>>> + val[2] = sc.cycles;
>>> + val[3] = 0;
>>> + break;
>>
>> This should return a guest-cycles value. If the cycles values always the same
>> between the host and the guest on ARM, then okay. If not, you have to
>> apply whatever offset exists.
>>
> In my opinion, when use ptp_kvm as clock sources to sync time
> between host and guest, user should promise the guest and host has no
> clock offset.
What would be the adverse effect of having a fixed offset between guest
and host? If there were one, you'd have to check that and fail the
hypercall if there is an offset. But again, I think it's enough to
subtract vcpu_vtimer(vcpu)->cntvoff or something like that.
You also have to check here that the clocksource is based on the ARM
architectural timer. Again, maybe you could place the implementation in
drivers/clocksource/arm_arch_timer.c, and make it return -ENODEV if the
active clocksource is not clocksource_counter. Then KVM can look for
errors and return SMCCC_RET_NOT_SUPPORTED in that case.
Thanks,
Paolo
> So we can be sure that the cycle between guest and
> host should be keep consistent. But I need check it.
> I think host cycle should be returned to guest as we should promise
> we get clock and counter in the same time.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 08/14] samples: bpf: makefile: base target programs rules on Makefile.target
From: Ivan Khoronzhuk @ 2019-09-18 10:23 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzYFoJJk+WM51YT7NwCxQpy117DAMmgiJ1YbqaW9UUWpEg@mail.gmail.com>
On Tue, Sep 17, 2019 at 04:28:01PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:58 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>
>Please don't prepend "samples: bpf: makefile:" to patches,
>"samples/bpf: " is a typical we've used for BPF samples changes.
Ok.
>
>
>> The main reason for that - HOSTCC and CC have different aims.
>> HOSTCC is used to build programs running on host, that can
>> cross-comple target programs with CC. It was tested for arm and arm64
>> cross compilation, based on linaro toolchain, but should work for
>> others.
>>
>> So, in order to split cross compilation (CC) with host build (HOSTCC),
>> lets base samples on Makefile.target. It allows to cross-compile
>> samples/bpf programs with CC while auxialry tools running on host
>> built with HOSTCC.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 135 ++++++++++++++++++++++---------------------
>> 1 file changed, 69 insertions(+), 66 deletions(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 9d923546e087..1579cc16a1c2 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -4,55 +4,53 @@ BPF_SAMPLES_PATH ?= $(abspath $(srctree)/$(src))
>> TOOLS_PATH := $(BPF_SAMPLES_PATH)/../../tools
>>
>> # List of programs to build
>> -hostprogs-y := test_lru_dist
[...]
>> -KBUILD_HOSTCFLAGS := $(ARM_ARCH_SELECTOR)
>> +TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR)
>> endif
>>
>> +TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS)
>
>Please group TPROGS_LDLIBS definition together with the one below,
>there doesn't seem to be a reason to split them this way.
No. It's used in Makefile.target and should be here, following hostprog logic.
>
>But also, it's kind of weird to use host libraries as cross-compiled
>libraries as well. Is that intentional?
No cross-compile split yet. This patch replace only KBUILD on TPROGS.
It's done in following patches.
>
>> +TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS)
>
>Same here, is it right to use HOSTCFLAGS and HOST_EXTRACFLAGS as a
>base for cross-compiled cflags?
same
[...]
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: net/dst_cache.c: preemption bug in net/dst_cache.c
From: Bharath Vedartham @ 2019-09-18 10:19 UTC (permalink / raw)
To: Xin Long
Cc: davem, Greg Kroah-Hartman, allison, tglx, network dev, LKML,
Jon Maloy
In-Reply-To: <CADvbK_c5+1-qDohRtFap25ih6XoAD3JirUz-impy7jvNZYpdvg@mail.gmail.com>
On Mon, Sep 09, 2019 at 05:48:25PM +0800, Xin Long wrote:
> On Fri, Aug 23, 2019 at 3:58 PM Bharath Vedartham <linux.bhar@gmail.com> wrote:
> >
> > Hi all,
> >
> > I just want to bring attention to the syzbot bug [1]
> >
> > Even though syzbot claims the bug to be in net/tipc, I feel it is in
> > net/dst_cache.c. Please correct me if I am wrong.
> >
> > This bug is being triggered a lot of times by syzbot since the day it
> > was reported. Also given that this is core networking code, I felt it
> > was important to bring this to attention.
> >
> > It looks like preemption needs to be disabled before using this_cpu_ptr
> > or maybe we would be better of using a get_cpu_var and put_cpu_var combo
> > here.
> b->media->send_msg (tipc_udp_send_msg)
> -> tipc_udp_xmit() -> dst_cache_get()
>
> send_msg() is always called under the protection of rcu_read_lock(), which
> already disabled preemption. If not, there must be some unbalanced calls of
> disable/enable preemption elsewhere.
>
> Agree that this could be a serious issue, do you have any reproducer for this?
>
> Thanks.
Hi Xin,
Sorry for the delayed response. I do not have a reproducer for this. You
can submit a patch to syzbot which can run the patch on the same system
on which it found the bug.
Thank you
Bharath
> >
> > [1] https://syzkaller.appspot.com/bug?id=dc6352b92862eb79373fe03fdf9af5928753e057
> >
> > Thank you
> > Bharath
^ 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