* [PATCH] leds: triggers: netdev: add a check, whether device is up @ 2023-11-04 12:58 Klaus Kudielka 2023-11-04 14:29 ` Andrew Lunn 0 siblings, 1 reply; 4+ messages in thread From: Klaus Kudielka @ 2023-11-04 12:58 UTC (permalink / raw) To: Pavel Machek, Lee Jones Cc: Andrew Lunn, Christian Marangi, David S . Miller, Jakub Kicinski, Samuel Holland, Jisheng Zhang, Li Zetao, linux-leds, linux-kernel, Klaus Kudielka Some net devices do not report NO-CARRIER, if they haven't been brought up. In that case, the netdev trigger results in a wrong link state being displayed. Fix this, by adding a check, whether the device is up. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> --- drivers/leds/trigger/ledtrig-netdev.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c index e358e77e4b..bd5e21d0f0 100644 --- a/drivers/leds/trigger/ledtrig-netdev.c +++ b/drivers/leds/trigger/ledtrig-netdev.c @@ -195,7 +195,8 @@ static void get_device_state(struct led_netdev_data *trigger_data) { struct ethtool_link_ksettings cmd; - trigger_data->carrier_link_up = netif_carrier_ok(trigger_data->net_dev); + trigger_data->carrier_link_up = netif_running(trigger_data->net_dev) && + netif_carrier_ok(trigger_data->net_dev); if (!trigger_data->carrier_link_up) return; -- 2.42.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] leds: triggers: netdev: add a check, whether device is up 2023-11-04 12:58 [PATCH] leds: triggers: netdev: add a check, whether device is up Klaus Kudielka @ 2023-11-04 14:29 ` Andrew Lunn 2023-11-04 15:27 ` Klaus Kudielka 0 siblings, 1 reply; 4+ messages in thread From: Andrew Lunn @ 2023-11-04 14:29 UTC (permalink / raw) To: Klaus Kudielka Cc: Pavel Machek, Lee Jones, Christian Marangi, David S . Miller, Jakub Kicinski, Samuel Holland, Jisheng Zhang, Li Zetao, linux-leds, linux-kernel On Sat, Nov 04, 2023 at 01:58:40PM +0100, Klaus Kudielka wrote: > Some net devices do not report NO-CARRIER, if they haven't been brought > up. Hi Klaus We should probably fix the driver. What device is it? > In that case, the netdev trigger results in a wrong link state being > displayed. Fix this, by adding a check, whether the device is up. Is it wrong? Maybe the carrier really is up, even if the interface is admin down. Broadcast packets are being received by the hardware. Maybe there is a BMC sharing the link and it is active? It is not a clear cut wrong to me. And its a way to find broken drivers. We might want to discuss this some more. Andrew ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] leds: triggers: netdev: add a check, whether device is up 2023-11-04 14:29 ` Andrew Lunn @ 2023-11-04 15:27 ` Klaus Kudielka 2023-11-04 16:32 ` Klaus Kudielka 0 siblings, 1 reply; 4+ messages in thread From: Klaus Kudielka @ 2023-11-04 15:27 UTC (permalink / raw) To: Andrew Lunn Cc: Pavel Machek, Lee Jones, Christian Marangi, David S . Miller, Jakub Kicinski, Samuel Holland, Jisheng Zhang, Li Zetao, linux-leds, linux-kernel On Sat, 2023-11-04 at 15:29 +0100, Andrew Lunn wrote: > On Sat, Nov 04, 2023 at 01:58:40PM +0100, Klaus Kudielka wrote: > > Some net devices do not report NO-CARRIER, if they haven't been brought > > up. > > Hi Klaus > > We should probably fix the driver. What device is it? > > > In that case, the netdev trigger results in a wrong link state being > > displayed. Fix this, by adding a check, whether the device is up. > > Is it wrong? Maybe the carrier really is up, even if the interface is > admin down. Broadcast packets are being received by the > hardware. Maybe there is a BMC sharing the link and it is active? My particular example is Turris Omnia, eth2 (WAN), connected to SFP. SFP module is inserted, but no fiber connected, so definitely no carrier. *Without* the patch: After booting, the device is down, but netdev trigger reports "link" active. This looks wrong to me. I can then "ip link set eth2 up", and the "link" goes away - as I would have expected it to be from the beginning. > It is not a clear cut wrong to me. And its a way to find broken > drivers. We might want to discuss this some more. Maybe an initialization issue. Just a guess, I'm really not an expert here: phylink_start() is the first one that does netif_carrier_off() and thus sets the NOCARRIER bit, but that only happens when bringing the device up. Before that, I would not know who cares about setting the NOCARRIER bit. Anyway, it's only a cosmetic issue, but it has been bugging me for too long :) Best regards, Klaus ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] leds: triggers: netdev: add a check, whether device is up 2023-11-04 15:27 ` Klaus Kudielka @ 2023-11-04 16:32 ` Klaus Kudielka 0 siblings, 0 replies; 4+ messages in thread From: Klaus Kudielka @ 2023-11-04 16:32 UTC (permalink / raw) To: Andrew Lunn Cc: Pavel Machek, Lee Jones, Christian Marangi, David S . Miller, Jakub Kicinski, Samuel Holland, Jisheng Zhang, Li Zetao, linux-leds, linux-kernel On Sat, 2023-11-04 at 16:27 +0100, Klaus Kudielka wrote: > > phylink_start() is the first one that does netif_carrier_off() and thus > sets the NOCARRIER bit, but that only happens when bringing the device up. > > Before that, I would not know who cares about setting the NOCARRIER bit. A different, driver-specific solution could be like this (tested and working): --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -5690,6 +5690,7 @@ static int mvneta_probe(struct platform_device *pdev) /* 9676 == 9700 - 20 and rounding to 8 */ dev->max_mtu = 9676; + netif_carrier_off(dev); err = register_netdev(dev); if (err < 0) { dev_err(&pdev->dev, "failed to register\n"); Would that be the "correct" approach? Regards, Klaus ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-11-04 16:32 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-11-04 12:58 [PATCH] leds: triggers: netdev: add a check, whether device is up Klaus Kudielka 2023-11-04 14:29 ` Andrew Lunn 2023-11-04 15:27 ` Klaus Kudielka 2023-11-04 16:32 ` Klaus Kudielka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox