* Re: [pull request][net 0/4] Mellanox, mlx5 fixes 2019-08-22
From: David Miller @ 2019-08-24 23:27 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190822204121.16954-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 22 Aug 2019 20:41:34 +0000
> This series introduces some fixes to mlx5 driver.
>
> 1) Form Moshe, two fixes for firmware health reporter
> 2) From Eran, two ktls fixes.
>
> Please pull and let me know if there is any problem.
>
> No -stable this time :) ..
:) Pulled, thanks!
^ permalink raw reply
* Re: [PATCH net-next] net: hns3: Fix -Wunused-const-variable warning
From: David Miller @ 2019-08-24 23:24 UTC (permalink / raw)
To: yuehaibing
Cc: yisen.zhuang, salil.mehta, lipeng321, tanhuazhong, shenjian15,
linyunsheng, liuzhongzhu, huangguangbin2, liweihang, netdev,
linux-kernel
In-Reply-To: <20190822144937.75884-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 22 Aug 2019 22:49:37 +0800
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h:542:30:
> warning: meta_data_key_info defined but not used [-Wunused-const-variable=]
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h:553:30:
> warning: tuple_key_info defined but not used [-Wunused-const-variable=]
>
> The two variable is only used in hclge_main.c,
> so just move the definition over there.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: dsa: mt7530: Add support for port 5
From: David Miller @ 2019-08-24 23:19 UTC (permalink / raw)
To: opensource
Cc: sean.wang, andrew, vivien.didelot, f.fainelli, matthias.bgg,
netdev, linux-arm-kernel, linux-mediatek, john, linux-mips,
frank-w
In-Reply-To: <20190821144547.15113-4-opensource@vdorst.com>
From: René van Dorst <opensource@vdorst.com>
Date: Wed, 21 Aug 2019 16:45:47 +0200
> + dev_info(ds->dev, "Setup P5, HWTRAP=0x%x, intf_sel=%s, phy-mode=%s\n",
> + val, p5_intf_modes(priv->p5_intf_sel), phy_modes(interface));
This is debugging, at best. Please make this a debugging message or
remove it entirely.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: Add phylink keyword to SFF/SFP/SFP+ MODULE SUPPORT
From: David Miller @ 2019-08-24 23:15 UTC (permalink / raw)
To: andrew; +Cc: rmk+kernel, netdev
In-Reply-To: <20190824223454.15932-1-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 25 Aug 2019 00:34:54 +0200
> Russell king maintains phylink, as part of the SFP module support.
> However, much of the review work is about drivers swapping from phylib
> to phylink. Such changes don't make changes to the phylink core, and
> so the F: rules in MAINTAINERS don't match. Add a K:, keywork rule,
> which hopefully get_maintainers will match against for patches to MAC
> drivers swapping to phylink.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied to 'net', as I like to keep MAINTAINERS as uptodate as widely
as possible.
Thanks.
^ permalink raw reply
* Re: Regresion with dsa_port_disable
From: Andrew Lunn @ 2019-08-24 23:16 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev
In-Reply-To: <20190824191220.GB1808@t480s.localdomain>
On Sat, Aug 24, 2019 at 07:12:20PM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> On Sun, 25 Aug 2019 00:53:06 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> > I just booted a ZII devel C and got a new warning splat.
> >
> > WARNING: CPU: 0 PID: 925 at kernel/irq/manage.c:1708 __free_irq+0xc8/0x2c4
> > Trying to free already-free IRQ 0
> > Modules linked in:
> > CPU: 0 PID: 925 Comm: kworker/0:2 Not tainted 5.3.0-rc5-01151-g7ff758fcdf65 #231
> > Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> > Workqueue: events deferred_probe_work_func
> > Backtrace:
> > [<8010d9e4>] (dump_backtrace) from [<8010dd9c>] (show_stack+0x20/0x24)
> > r7:8016edf8 r6:00000009 r5:00000000 r4:9ec67944
> > [<8010dd7c>] (show_stack) from [<8083b03c>] (dump_stack+0x24/0x28)
> > [<8083b018>] (dump_stack) from [<8011c108>] (__warn.part.3+0xcc/0xf8)
> > [<8011c03c>] (__warn.part.3) from [<8011c1ac>] (warn_slowpath_fmt+0x78/0x94)
> > r6:000006ac r5:80a8cbf0 r4:80d07088
> > [<8011c138>] (warn_slowpath_fmt) from [<8016edf8>] (__free_irq+0xc8/0x2c4)
> > r3:00000000 r2:80a8cca8
> > r7:9f486668 r6:9ee25268 r5:9f486600 r4:9ee25268
> > [<8016ed30>] (__free_irq) from [<8016f07c>] (free_irq+0x38/0x74)
> > r10:9eeb3600 r9:9e412040 r8:00000009 r7:9ee26040 r6:9ee2404c r5:9ee242c8
> > r4:9ee25268 r3:00000c00
> > [<8016f044>] (free_irq) from [<805a244c>] (mv88e6390x_serdes_irq_free+0x68/0x98)
> > r5:9ee242c8 r4:9ee24040
> > [<805a23e4>] (mv88e6390x_serdes_irq_free) from [<8059bc94>] (mv88e6xxx_port_disable+0x58/0x98)
> > r7:9ee26040 r6:00000009 r5:9ee2404c r4:9ee24040
> > [<8059bc3c>] (mv88e6xxx_port_disable) from [<80806f70>] (dsa_port_disable+0x44/0x50)
> > r7:9ee26040 r6:9ee26d74 r5:00000009 r4:9ee26040
> > [<80806f2c>] (dsa_port_disable) from [<80805df0>] (dsa_register_switch+0x964/0xab8)
> > r5:9efe194c r4:9ee26d38
> > [<8080548c>] (dsa_register_switch) from [<8059b734>] (mv88e6xxx_probe+0x730/0x778)
> > r10:80943e64 r9:9fbf77d0 r8:00000000 r7:80d07088 r6:9e410040 r5:00000000
> > r4:9e40e800
> > [<8059b004>] (mv88e6xxx_probe) from [<80582da8>] (mdio_probe+0x40/0x64)
> > r10:00000012 r9:80d5eccc r8:00000000 r7:00000000 r6:8141f358 r5:9e40e800
> > r4:80d5eccc
> > [<80582d68>] (mdio_probe) from [<80518858>] (really_probe+0x100/0x2d8)
> > r5:9e40e800 r4:8141f354
> >
> > The previous code was careful to balance mv88e6352_serdes_irq_setup()
> > with mv88e6390x_serdes_irq_free(). I _think_ your change broke this
> > balance, and we now try to free an interrupt which was never
> > allocated.
>
> What do you mean by "balance mv88e6352_serdes_irq_setup() with
> mv88e6390x_serdes_irq_free()"?
Hi Vivien
It never called mv88e6390x_serdes_irq_free() unless
mv88e6352_serdes_irq_setup() had been called first.
mv88e6390x_serdes_irq_free() makes the assumption there actually is an
interrupt to free. I suspect your changes now call
mv88e6390x_serdes_irq_free() unconditionally.
Andrew
^ permalink raw reply
* Re: Regresion with dsa_port_disable
From: Vivien Didelot @ 2019-08-24 23:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190824225306.GA15986@lunn.ch>
Hi Andrew,
On Sun, 25 Aug 2019 00:53:06 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> I just booted a ZII devel C and got a new warning splat.
>
> WARNING: CPU: 0 PID: 925 at kernel/irq/manage.c:1708 __free_irq+0xc8/0x2c4
> Trying to free already-free IRQ 0
> Modules linked in:
> CPU: 0 PID: 925 Comm: kworker/0:2 Not tainted 5.3.0-rc5-01151-g7ff758fcdf65 #231
> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> Workqueue: events deferred_probe_work_func
> Backtrace:
> [<8010d9e4>] (dump_backtrace) from [<8010dd9c>] (show_stack+0x20/0x24)
> r7:8016edf8 r6:00000009 r5:00000000 r4:9ec67944
> [<8010dd7c>] (show_stack) from [<8083b03c>] (dump_stack+0x24/0x28)
> [<8083b018>] (dump_stack) from [<8011c108>] (__warn.part.3+0xcc/0xf8)
> [<8011c03c>] (__warn.part.3) from [<8011c1ac>] (warn_slowpath_fmt+0x78/0x94)
> r6:000006ac r5:80a8cbf0 r4:80d07088
> [<8011c138>] (warn_slowpath_fmt) from [<8016edf8>] (__free_irq+0xc8/0x2c4)
> r3:00000000 r2:80a8cca8
> r7:9f486668 r6:9ee25268 r5:9f486600 r4:9ee25268
> [<8016ed30>] (__free_irq) from [<8016f07c>] (free_irq+0x38/0x74)
> r10:9eeb3600 r9:9e412040 r8:00000009 r7:9ee26040 r6:9ee2404c r5:9ee242c8
> r4:9ee25268 r3:00000c00
> [<8016f044>] (free_irq) from [<805a244c>] (mv88e6390x_serdes_irq_free+0x68/0x98)
> r5:9ee242c8 r4:9ee24040
> [<805a23e4>] (mv88e6390x_serdes_irq_free) from [<8059bc94>] (mv88e6xxx_port_disable+0x58/0x98)
> r7:9ee26040 r6:00000009 r5:9ee2404c r4:9ee24040
> [<8059bc3c>] (mv88e6xxx_port_disable) from [<80806f70>] (dsa_port_disable+0x44/0x50)
> r7:9ee26040 r6:9ee26d74 r5:00000009 r4:9ee26040
> [<80806f2c>] (dsa_port_disable) from [<80805df0>] (dsa_register_switch+0x964/0xab8)
> r5:9efe194c r4:9ee26d38
> [<8080548c>] (dsa_register_switch) from [<8059b734>] (mv88e6xxx_probe+0x730/0x778)
> r10:80943e64 r9:9fbf77d0 r8:00000000 r7:80d07088 r6:9e410040 r5:00000000
> r4:9e40e800
> [<8059b004>] (mv88e6xxx_probe) from [<80582da8>] (mdio_probe+0x40/0x64)
> r10:00000012 r9:80d5eccc r8:00000000 r7:00000000 r6:8141f358 r5:9e40e800
> r4:80d5eccc
> [<80582d68>] (mdio_probe) from [<80518858>] (really_probe+0x100/0x2d8)
> r5:9e40e800 r4:8141f354
>
> The previous code was careful to balance mv88e6352_serdes_irq_setup()
> with mv88e6390x_serdes_irq_free(). I _think_ your change broke this
> balance, and we now try to free an interrupt which was never
> allocated.
What do you mean by "balance mv88e6352_serdes_irq_setup() with
mv88e6390x_serdes_irq_free()"?
Vivien
^ permalink raw reply
* [PATCH net-next] net: phy: sfp: Add labels to hwmon sensors
From: Andrew Lunn @ 2019-08-24 23:04 UTC (permalink / raw)
To: David Miller
Cc: Russell King, Guenter Roeck, Chris Healy, netdev, Andrew Lunn
SFPs can report two different power values, the transmit power and the
receive power. Add labels to make it clear which is which. Also add
labels to the other sensors, VCC power supply, bias and module
temperature.
sensors(1) now shows:
sff2-isa-0000
Adapter: ISA adapter
VCC: +3.23 V
temperature: +33.4 C
TX_power: 276.00 uW
RX_power: 20.00 uW
bias: +0.01 A
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/sfp.c | 73 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 68 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index e36c04c26866..272d5773573e 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -429,6 +429,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_temp_input:
+ case hwmon_temp_label:
return 0444;
default:
return 0;
@@ -447,6 +448,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_in_input:
+ case hwmon_in_label:
return 0444;
default:
return 0;
@@ -465,6 +467,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_curr_input:
+ case hwmon_curr_label:
return 0444;
default:
return 0;
@@ -492,6 +495,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_power_input:
+ case hwmon_power_label:
return 0444;
default:
return 0;
@@ -987,9 +991,63 @@ static int sfp_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
}
}
+static const char *const sfp_hwmon_power_labels[] = {
+ "TX_power",
+ "RX_power",
+};
+
+static int sfp_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ switch (type) {
+ case hwmon_curr:
+ switch (attr) {
+ case hwmon_curr_label:
+ *str = "bias";
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_label:
+ *str = "temperature";
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_in:
+ switch (attr) {
+ case hwmon_in_label:
+ *str = "VCC";
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_power:
+ switch (attr) {
+ case hwmon_power_label:
+ *str = sfp_hwmon_power_labels[channel];
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return -EOPNOTSUPP;
+}
+
static const struct hwmon_ops sfp_hwmon_ops = {
.is_visible = sfp_hwmon_is_visible,
.read = sfp_hwmon_read,
+ .read_string = sfp_hwmon_read_string,
};
static u32 sfp_hwmon_chip_config[] = {
@@ -1007,7 +1065,8 @@ static u32 sfp_hwmon_temp_config[] = {
HWMON_T_MAX | HWMON_T_MIN |
HWMON_T_MAX_ALARM | HWMON_T_MIN_ALARM |
HWMON_T_CRIT | HWMON_T_LCRIT |
- HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM,
+ HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM |
+ HWMON_T_LABEL,
0,
};
@@ -1021,7 +1080,8 @@ static u32 sfp_hwmon_vcc_config[] = {
HWMON_I_MAX | HWMON_I_MIN |
HWMON_I_MAX_ALARM | HWMON_I_MIN_ALARM |
HWMON_I_CRIT | HWMON_I_LCRIT |
- HWMON_I_CRIT_ALARM | HWMON_I_LCRIT_ALARM,
+ HWMON_I_CRIT_ALARM | HWMON_I_LCRIT_ALARM |
+ HWMON_I_LABEL,
0,
};
@@ -1035,7 +1095,8 @@ static u32 sfp_hwmon_bias_config[] = {
HWMON_C_MAX | HWMON_C_MIN |
HWMON_C_MAX_ALARM | HWMON_C_MIN_ALARM |
HWMON_C_CRIT | HWMON_C_LCRIT |
- HWMON_C_CRIT_ALARM | HWMON_C_LCRIT_ALARM,
+ HWMON_C_CRIT_ALARM | HWMON_C_LCRIT_ALARM |
+ HWMON_C_LABEL,
0,
};
@@ -1050,13 +1111,15 @@ static u32 sfp_hwmon_power_config[] = {
HWMON_P_MAX | HWMON_P_MIN |
HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
HWMON_P_CRIT | HWMON_P_LCRIT |
- HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM,
+ HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
+ HWMON_P_LABEL,
/* Receive power */
HWMON_P_INPUT |
HWMON_P_MAX | HWMON_P_MIN |
HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
HWMON_P_CRIT | HWMON_P_LCRIT |
- HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM,
+ HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
+ HWMON_P_LABEL,
0,
};
--
2.23.0.rc1
^ permalink raw reply related
* Regresion with dsa_port_disable
From: Andrew Lunn @ 2019-08-24 22:53 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev
Hi Vivien
I just booted a ZII devel C and got a new warning splat.
WARNING: CPU: 0 PID: 925 at kernel/irq/manage.c:1708 __free_irq+0xc8/0x2c4
Trying to free already-free IRQ 0
Modules linked in:
CPU: 0 PID: 925 Comm: kworker/0:2 Not tainted 5.3.0-rc5-01151-g7ff758fcdf65 #231
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Workqueue: events deferred_probe_work_func
Backtrace:
[<8010d9e4>] (dump_backtrace) from [<8010dd9c>] (show_stack+0x20/0x24)
r7:8016edf8 r6:00000009 r5:00000000 r4:9ec67944
[<8010dd7c>] (show_stack) from [<8083b03c>] (dump_stack+0x24/0x28)
[<8083b018>] (dump_stack) from [<8011c108>] (__warn.part.3+0xcc/0xf8)
[<8011c03c>] (__warn.part.3) from [<8011c1ac>] (warn_slowpath_fmt+0x78/0x94)
r6:000006ac r5:80a8cbf0 r4:80d07088
[<8011c138>] (warn_slowpath_fmt) from [<8016edf8>] (__free_irq+0xc8/0x2c4)
r3:00000000 r2:80a8cca8
r7:9f486668 r6:9ee25268 r5:9f486600 r4:9ee25268
[<8016ed30>] (__free_irq) from [<8016f07c>] (free_irq+0x38/0x74)
r10:9eeb3600 r9:9e412040 r8:00000009 r7:9ee26040 r6:9ee2404c r5:9ee242c8
r4:9ee25268 r3:00000c00
[<8016f044>] (free_irq) from [<805a244c>] (mv88e6390x_serdes_irq_free+0x68/0x98)
r5:9ee242c8 r4:9ee24040
[<805a23e4>] (mv88e6390x_serdes_irq_free) from [<8059bc94>] (mv88e6xxx_port_disable+0x58/0x98)
r7:9ee26040 r6:00000009 r5:9ee2404c r4:9ee24040
[<8059bc3c>] (mv88e6xxx_port_disable) from [<80806f70>] (dsa_port_disable+0x44/0x50)
r7:9ee26040 r6:9ee26d74 r5:00000009 r4:9ee26040
[<80806f2c>] (dsa_port_disable) from [<80805df0>] (dsa_register_switch+0x964/0xab8)
r5:9efe194c r4:9ee26d38
[<8080548c>] (dsa_register_switch) from [<8059b734>] (mv88e6xxx_probe+0x730/0x778)
r10:80943e64 r9:9fbf77d0 r8:00000000 r7:80d07088 r6:9e410040 r5:00000000
r4:9e40e800
[<8059b004>] (mv88e6xxx_probe) from [<80582da8>] (mdio_probe+0x40/0x64)
r10:00000012 r9:80d5eccc r8:00000000 r7:00000000 r6:8141f358 r5:9e40e800
r4:80d5eccc
[<80582d68>] (mdio_probe) from [<80518858>] (really_probe+0x100/0x2d8)
r5:9e40e800 r4:8141f354
The previous code was careful to balance mv88e6352_serdes_irq_setup()
with mv88e6390x_serdes_irq_free(). I _think_ your change broke this
balance, and we now try to free an interrupt which was never
allocated.
Andrew
^ permalink raw reply
* [PATCH net-next] MAINTAINERS: Add phylink keyword to SFF/SFP/SFP+ MODULE SUPPORT
From: Andrew Lunn @ 2019-08-24 22:34 UTC (permalink / raw)
To: David Miller; +Cc: Russell King, netdev, Andrew Lunn
Russell king maintains phylink, as part of the SFP module support.
However, much of the review work is about drivers swapping from phylib
to phylink. Such changes don't make changes to the phylink core, and
so the F: rules in MAINTAINERS don't match. Add a K:, keywork rule,
which hopefully get_maintainers will match against for patches to MAC
drivers swapping to phylink.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 986085351d79..20913acea658 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14491,6 +14491,7 @@ F: drivers/net/phy/phylink.c
F: drivers/net/phy/sfp*
F: include/linux/phylink.h
F: include/linux/sfp.h
+K: phylink
SGI GRU DRIVER
M: Dimitri Sivanich <sivanich@sgi.com>
--
2.23.0
^ permalink raw reply related
* Re: [PATCH net-next v2 0/3] net: dsa: mt7530: Convert to PHYLINK and add support for port 5
From: Russell King - ARM Linux admin @ 2019-08-24 22:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, f.fainelli, frank-w, netdev, sean.wang, linux-mips,
opensource, linux-mediatek, john, matthias.bgg, vivien.didelot,
linux-arm-kernel
In-Reply-To: <20190824221519.GF8251@lunn.ch>
On Sun, Aug 25, 2019 at 12:15:19AM +0200, Andrew Lunn wrote:
> 65;5402;1cOn Sat, Aug 24, 2019 at 02:18:03PM -0700, David Miller wrote:
> > From: Andrew Lunn <andrew@lunn.ch>
> > Date: Fri, 23 Aug 2019 03:09:28 +0200
> >
> > > That would be Russell.
> > >
> > > We should try to improve MAINTAINER so that Russell King gets picked
> > > by the get_maintainer script.
> >
> > Shoule he be added to the mt7530 entry?
>
> Hi David
>
> No. I think we need a phylink entry. And then make use of the K: line
> format to list keywords. I hope that even though changes like this
> don't touch any files listed as being part of phylink, they will match
> the keyword and pickup Russell.
Note that phylink itself is already covered by
"SFF/SFP/SFP+ MODULE SUPPORT"
but doesn't pick up on keywords.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: dsa: mt7530: Convert to PHYLINK and add support for port 5
From: Russell King - ARM Linux admin @ 2019-08-24 22:29 UTC (permalink / raw)
To: René van Dorst
Cc: Sean Wang, Andrew Lunn, Vivien Didelot, Florian Fainelli,
David S . Miller, Matthias Brugger, Frank Wunderlich, netdev,
linux-mips, linux-mediatek, John Crispin, linux-arm-kernel
In-Reply-To: <20190821144547.15113-1-opensource@vdorst.com>
On Wed, Aug 21, 2019 at 04:45:44PM +0200, René van Dorst wrote:
> 1. net: dsa: mt7530: Convert to PHYLINK API
> This patch converts mt7530 to PHYLINK API.
> 2. dt-bindings: net: dsa: mt7530: Add support for port 5
> 3. net: dsa: mt7530: Add support for port 5
> These 2 patches adding support for port 5 of the switch.
>
> v1->v2:
> * Mostly phylink improvements after review.
> rfc -> v1:
> * Mostly phylink improvements after review.
> * Drop phy isolation patches. Adds no value for now.
> René van Dorst (3):
> net: dsa: mt7530: Convert to PHYLINK API
> dt-bindings: net: dsa: mt7530: Add support for port 5
> net: dsa: mt7530: Add support for port 5
>
> .../devicetree/bindings/net/dsa/mt7530.txt | 218 ++++++++++
> drivers/net/dsa/mt7530.c | 371 +++++++++++++++---
> drivers/net/dsa/mt7530.h | 61 ++-
> 3 files changed, 577 insertions(+), 73 deletions(-)
Having looked through this set of patches, I don't see anything
from the phylink point of view that concerns me. So, for the
series from the phylink perspective:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
I did notice a dev_info() in patch 3 that you may like to consider
whether they should be printed at info level or debug level. You
may keep my ack on the patch when fixing that.
I haven't considered whether the patch passes davem's style
requirements for networking code; what I spotted did look like
the declarations were upside-down christmas tree.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: dsa: mt7530: Convert to PHYLINK and add support for port 5
From: Russell King - ARM Linux admin @ 2019-08-24 22:18 UTC (permalink / raw)
To: David Miller
Cc: andrew, f.fainelli, frank-w, netdev, sean.wang, linux-mips,
opensource, linux-mediatek, john, matthias.bgg, vivien.didelot,
linux-arm-kernel
In-Reply-To: <20190824.141803.1656753287804303137.davem@davemloft.net>
On Sat, Aug 24, 2019 at 02:18:03PM -0700, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Fri, 23 Aug 2019 03:09:28 +0200
>
> > That would be Russell.
> >
> > We should try to improve MAINTAINER so that Russell King gets picked
> > by the get_maintainer script.
>
> Shoule he be added to the mt7530 entry?
Probably some way to make MAINTAINERS pick up on phylink-containing
patches. Something like:
K: phylink
maybe?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: dsa: mt7530: Convert to PHYLINK and add support for port 5
From: Andrew Lunn @ 2019-08-24 22:15 UTC (permalink / raw)
To: David Miller
Cc: opensource, sean.wang, vivien.didelot, f.fainelli, matthias.bgg,
netdev, linux-arm-kernel, linux-mediatek, john, linux-mips,
frank-w
In-Reply-To: <20190824.141803.1656753287804303137.davem@davemloft.net>
65;5402;1cOn Sat, Aug 24, 2019 at 02:18:03PM -0700, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Fri, 23 Aug 2019 03:09:28 +0200
>
> > That would be Russell.
> >
> > We should try to improve MAINTAINER so that Russell King gets picked
> > by the get_maintainer script.
>
> Shoule he be added to the mt7530 entry?
Hi David
No. I think we need a phylink entry. And then make use of the K: line
format to list keywords. I hope that even though changes like this
don't touch any files listed as being part of phylink, they will match
the keyword and pickup Russell.
I need to do some testing and see if this actually works.
Andrew
^ permalink raw reply
* Re: [PATCH 4.14] tcp: fix tcp_rtx_queue_tail in case of empty retransmit queue
From: Jonathan Lemon @ 2019-08-24 22:05 UTC (permalink / raw)
To: Tim Froidcoeur
Cc: matthieu.baerts, aprout, cpaasch, davem, edumazet, gregkh, jtl,
linux-kernel, mkubecek, ncardwell, sashal, stable, ycheng, netdev
In-Reply-To: <20190824060351.3776-1-tim.froidcoeur@tessares.net>
On 23 Aug 2019, at 23:03, Tim Froidcoeur wrote:
> Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> triggers following stack trace:
>
> [25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
> [25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
> [25244.888167] Call Trace:
> [25244.889182] <IRQ>
> [25244.890001] tcp_fragment+0x9c/0x2cf
> [25244.891295] tcp_write_xmit+0x68f/0x988
> [25244.892732] __tcp_push_pending_frames+0x3b/0xa0
> [25244.894347] tcp_data_snd_check+0x2a/0xc8
> [25244.895775] tcp_rcv_established+0x2a8/0x30d
> [25244.897282] tcp_v4_do_rcv+0xb2/0x158
> [25244.898666] tcp_v4_rcv+0x692/0x956
> [25244.899959] ip_local_deliver_finish+0xeb/0x169
> [25244.901547] __netif_receive_skb_core+0x51c/0x582
> [25244.903193] ? inet_gro_receive+0x239/0x247
> [25244.904756] netif_receive_skb_internal+0xab/0xc6
> [25244.906395] napi_gro_receive+0x8a/0xc0
> [25244.907760] receive_buf+0x9a1/0x9cd
> [25244.909160] ? load_balance+0x17a/0x7b7
> [25244.910536] ? vring_unmap_one+0x18/0x61
> [25244.911932] ? detach_buf+0x60/0xfa
> [25244.913234] virtnet_poll+0x128/0x1e1
> [25244.914607] net_rx_action+0x12a/0x2b1
> [25244.915953] __do_softirq+0x11c/0x26b
> [25244.917269] ? handle_irq_event+0x44/0x56
> [25244.918695] irq_exit+0x61/0xa0
> [25244.919947] do_IRQ+0x9d/0xbb
> [25244.921065] common_interrupt+0x85/0x85
> [25244.922479] </IRQ>
>
> tcp_rtx_queue_tail() (called by tcp_fragment()) can call
> tcp_write_queue_prev() on the first packet in the queue, which will trigger
> the BUG in tcp_write_queue_prev(), because there is no previous packet.
>
> This happens when the retransmit queue is empty, for example in case of a
> zero window.
>
> Patch is needed for 4.4, 4.9 and 4.14 stable branches.
>
> Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
> Change-Id: I839bde7167ae59e2f7d916c913507372445765c5
> Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> Reviewed-by: Christoph Paasch <cpaasch@apple.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCHv4 0/2] fix dev null pointer dereference when send packets larger than mtu in collect_md mode
From: David Miller @ 2019-08-24 21:51 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, sbrivio, wenxu, ast, eric.dumazet, ja
In-Reply-To: <20190822141949.29561-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Thu, 22 Aug 2019 22:19:47 +0800
> When we send a packet larger than PMTU, we need to reply with
> icmp_send(ICMP_FRAG_NEEDED) or icmpv6_send(ICMPV6_PKT_TOOBIG).
>
> But with collect_md mode, kernel will crash while accessing the dst dev
> as __metadata_dst_init() init dst->dev to NULL by default. Here is what
> the code path looks like, for GRE:
...
> We could not fix it in __metadata_dst_init() as there is no dev supplied.
> Look in to the __icmp_send()/decode_session{4,6} code we could find the dst
> dev is actually not needed. In __icmp_send(), we could get the net by skb->dev.
> For decode_session{4,6}, as it was called by xfrm_decode_session_reverse()
> in this scenario, the oif is not used by
> fl4->flowi4_oif = reverse ? skb->skb_iif : oif;
>
> The reproducer is easy:
...
Series applied, and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 8/9] net: dsa: mv88e6xxx: support Block Address setting in hidden registers
From: Vivien Didelot @ 2019-08-24 21:36 UTC (permalink / raw)
To: Marek Behun; +Cc: netdev, Andrew Lunn, Florian Fainelli, Vladimir Oltean
In-Reply-To: <20190824225216.264fe7b0@nic.cz>
Hi Marek,
On Sat, 24 Aug 2019 22:52:16 +0200, Marek Behun <marek.behun@nic.cz> wrote:
> > There's something I'm having trouble to follow here. This series keeps
> > adding and modifying its own code. Wouldn't it be simpler for everyone
> > if you directly implement the final mv88e6xxx_port_hidden_{read,write}
> > functions taking this block argument, and update the code to switch to it?
>
> I wanted the commits to be atomic, in the sense that one commit does
> not do three different things at once. Renaming macros is cosmetic
> change, and moving functions to another file is a not a semantic
> change, while adding additional argument to functions is a semantic
> change. I can of course do all in one patch, but I though it would be
> better not to.
You add code, move it, rename it, then change it. It is hard to follow and
read, especially in a series of 9 patches.
I think you could do it the other way around. For example implement the
.serdes_get_lane operation, its users, the mv88e6xxx_port_hidden_* API, its
users, remove or convert old code, etc. Atomicity has nothing to do with it.
> > While at it, I don't really mind the "hidden" name, but is this the name
> > used in the documentation, if any?
>
> Yes, the registers are indeed named Hidden Registers in documentation.
OK good to know, port_hidden_ makes sense indeed then.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net 0/9] rxrpc: Fix use of skb_cow_data()
From: David Miller @ 2019-08-24 21:35 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <156647655350.10908.12081183247715153431.stgit@warthog.procyon.org.uk>
I'm marking this series "deferred" while you investigate skb_unshare()
etc.
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix lack of conn cleanup when local endpoint is cleaned up
From: David Miller @ 2019-08-24 21:35 UTC (permalink / raw)
To: dhowells; +Cc: netdev, marc.dionne, linux-afs, linux-kernel
In-Reply-To: <156647679816.11606.13713532963081370001.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 22 Aug 2019 13:26:38 +0100
> + spin_lock(&rxnet->client_conn_cache_lock);
> + nr_active = rxnet->nr_active_client_conns;
> +
> + list_for_each_entry_safe(conn, tmp, &rxnet->idle_client_conns,
> + cache_link) {
> + if (conn->params.local == local) {
> + ASSERTCMP(conn->cache_state, ==, RXRPC_CONN_CLIENT_IDLE);
> +
> + trace_rxrpc_client(conn, -1, rxrpc_client_discard);
> + if (!test_and_clear_bit(RXRPC_CONN_EXPOSED, &conn->flags))
> + BUG();
> + conn->cache_state = RXRPC_CONN_CLIENT_INACTIVE;
> + list_move(&conn->cache_link, &graveyard);
> + nr_active--;
> + }
> + }
> +
> + rxnet->nr_active_client_conns = nr_active;
> + spin_unlock(&rxnet->client_conn_cache_lock);
> + ASSERTCMP(nr_active, >=, 0);
> +
> + spin_lock(&rxnet->client_conn_cache_lock);
> + while (!list_empty(&graveyard)) {
> + conn = list_entry(graveyard.next,
> + struct rxrpc_connection, cache_link);
> + list_del_init(&conn->cache_link);
> + spin_unlock(&rxnet->client_conn_cache_lock);
> +
> + rxrpc_put_connection(conn);
> +
> + spin_lock(&rxnet->client_conn_cache_lock);
> + }
> + spin_unlock(&rxnet->client_conn_cache_lock);
> +
> + _leave(" [culled]");
Once you've removed the entries from the globally visible idle_client_comms
list, and put them on the local garbage list, they cannot be seen in any way
by external threads of control outside of this function.
Therefore, you don't need to take the client_conn_cache_lock at all in the
second while loop.
^ permalink raw reply
* Re: [PATCH] net: use unlikely for dql_avail case
From: David Miller @ 2019-08-24 21:23 UTC (permalink / raw)
To: xiaolinkui; +Cc: ast, daniel, kafai, songliubraving, yhs, netdev, bpf
In-Reply-To: <20190822065816.23619-1-xiaolinkui@kylinos.cn>
From: xiaolinkui <xiaolinkui@kylinos.cn>
Date: Thu, 22 Aug 2019 14:58:16 +0800
> This is an unlikely case, use unlikely() on it seems logical.
>
> Signed-off-by: xiaolinkui <xiaolinkui@kylinos.cn>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5e: Use PTR_ERR_OR_ZERO in mlx5e_tc_add_nic_flow()
From: David Miller @ 2019-08-24 21:22 UTC (permalink / raw)
To: yuehaibing
Cc: saeedm, leon, netdev, linux-rdma, kernel-janitors, linux-kernel
In-Reply-To: <20190822065219.73945-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 22 Aug 2019 06:52:19 +0000
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Saeed, please pick this up if you haven't already.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] cirrus: cs89x0: remove set but not used variable 'lp'
From: David Miller @ 2019-08-24 21:22 UTC (permalink / raw)
To: yuehaibing; +Cc: netdev, kernel-janitors, hulkci
In-Reply-To: <20190822063517.71231-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 22 Aug 2019 06:35:17 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/cirrus/cs89x0.c: In function 'cs89x0_platform_probe':
> drivers/net/ethernet/cirrus/cs89x0.c:1847:20: warning:
> variable 'lp' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit 6751edeb8700 ("cirrus: cs89x0: Use
> managed interfaces")
Please use a proper Fixes: tag.
^ permalink raw reply
* Re: [PATCH -next] net: mediatek: remove set but not used variable 'status'
From: David Miller @ 2019-08-24 21:21 UTC (permalink / raw)
To: maowenan
Cc: nbd, john, sean.wang, nelson.chang, matthias.bgg, netdev,
linux-mediatek, linux-kernel, kernel-janitors
In-Reply-To: <20190822063026.70044-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Thu, 22 Aug 2019 14:30:26 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function mtk_handle_irq:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:1951:6: warning: variable status set but not used [-Wunused-but-set-variable]
>
> It is not used since commit 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support")
This is not a standard commit tag, please use Fixes: or similar.
^ permalink raw reply
* Re: [PATCH net-next] net/rds: Fix info leak in rds6_inc_info_copy()
From: David Miller @ 2019-08-24 21:20 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <1566443904-12671-1-git-send-email-ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Wed, 21 Aug 2019 20:18:24 -0700
> The rds6_inc_info_copy() function has a couple struct members which
> are leaking stack information. The ->tos field should hold actual
> information and the ->flags field needs to be zeroed out.
>
> Fixes: 3eb450367d08 ("rds: add type of service(tos) infrastructure")
> Fixes: b7ff8b1036f0 ("rds: Extend RDS API for IPv6 support")
> Reported-by: 黄ID蝴蝶 <butterflyhuangxx@gmail.com>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Why would an info leak bug fix, present in current kernels, be targetted
at 'net-next' instead of 'net'?
Please retarget this at 'net' properly, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: dsa: mt7530: Convert to PHYLINK and add support for port 5
From: David Miller @ 2019-08-24 21:18 UTC (permalink / raw)
To: andrew
Cc: opensource, sean.wang, vivien.didelot, f.fainelli, matthias.bgg,
netdev, linux-arm-kernel, linux-mediatek, john, linux-mips,
frank-w
In-Reply-To: <20190823010928.GK13020@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 23 Aug 2019 03:09:28 +0200
> That would be Russell.
>
> We should try to improve MAINTAINER so that Russell King gets picked
> by the get_maintainer script.
Shoule he be added to the mt7530 entry?
^ permalink raw reply
* Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support
From: Marek Behun @ 2019-08-24 21:01 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Andrew Lunn, Vivien Didelot, David Ahern,
Stephen Hemminger, Chris Healy, Vladimir Oltean
In-Reply-To: <a7fed8ab-60f3-a30c-5634-fd89e4daf44d@gmail.com>
On Sat, 24 Aug 2019 13:04:04 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> 1) Your approach is kind of interesting here, not sure if it is the best
> but it is not outright wrong. In the past, we had been talking about
> different approaches, some of which seemed too simplistic or too narrow
> on the use case, and some of which that are up in the air and were not
> worked on.
>
> - John Crispin submitted a patch series for the MTK switch driver a
> while back that was picked up by Frank Wunderlich more recently. This
> approach uses a Device Tree based configuration in order to statically
> assign ports, or groups of ports to a specific DSA master device. This
> is IMHO wrong because a) DT is not to impose a policy but strictly
> describe HW, and b) there was no way to change that static assignment at
> runtime.
>
> - Based on that patch series, Andrew, Vivien, Frank and myself discussed
> two possible options:
> - allowing the enslaving of DSA master devices in the bridge, so as to
> provide a hint that specific DSA slave network devices should be
> "bound"/"linked" to a specific DSA master device. This requires
> modifications in the bridge layer to avoid undoing what commit
> 8db0a2ee2c6302a1dcbcdb93cb731dfc6c0cdb5e ("net: bridge: reject
> DSA-enabled master netdevices as bridge members"). This would also
> require a bridge to be set-up
>
> - enhancing the iproute2 command and backing kernel code in order to
> allow defining that a DSA slave device may be enslaved into a specific
> DSA master, similarly to how you currently enslave a device into a
> bridge, you could "enslave" a DSA slave to a DSA master with something
> that could look like this:
>
> ip link set dev sw0p0 master eth0 # Associate port 0 with eth0
> ip link set dev sw0p1 master eth1 # Associate port 1 with eth1
>
> To date, this may be the best way to do what we want here, rather than
> use the iflink which is a bit re-purposing something that is not exactly
> meant for that.
We cannot use "set master" to set CPU port, since that is used for
enslaving interfaces to bridges. There are usecases where these would
conflict with each other. The semantics would become complicated and
the documentation would became weird to users.
We are *already* using the iflink property to report which CPU device
is used as CPU destination port for a given switch slave interface. So
why to use that for changing this, also?
If you think that iflink should not be used for this, and other agree,
then we should create a new property, something like dsa-upstream, (eg.
ip link set dev sw0p0 dsa-upstream eth0). Using the "master" property
is not right, IMO.
Marek
^ 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