Message ID | 20231104125840.27914-1-klaus.kudielka@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp1631226vqu; Sat, 4 Nov 2023 05:59:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFzIQprVm2buaqgO3ehZStiPcxHbceFEXlAKi1Z+xORHgQfjS3b8JinSdsMY3y5IRYDWNky X-Received: by 2002:a05:6a21:19c:b0:17e:aa00:ca62 with SMTP id le28-20020a056a21019c00b0017eaa00ca62mr8819389pzb.17.1699102787837; Sat, 04 Nov 2023 05:59:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1699102787; cv=none; d=google.com; s=arc-20160816; b=zaZbOQWTUPLGdaDF4dP2OApUb1Zns+Ek7dUMNId4etGDJmhf1zwP9FXwXdsdJqaVEM J4uGRJFWqmFwUsrNPNCgSzygWW+w6owtOV30hOtb+m9j09cbnzh1X4G9fWgMJ07E0lq7 VgCpclX3HjtfSU6t+44iKMasbGwuWa9t3sqeKlsCZCwBh4RIPUE7Bpv6mXEKX0CqisrZ /5Bp9xf5mkQOHjx8TD4WjR79NA4F0dMy+qUFm0xfnoMMzlRd6RHCI4PlHG6mOa3ws0lt b36Id8fzsa+dSwjXLFOPUu1eiIQbyUMz5xxcO834ffDaFHYYFu20RcVlKueLc1BAlS43 WhAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ObsqG9+10NLUeAHOgwfeMmWgkHs3rhcD4ztf3mot19o=; fh=0n3NWNs32lj2+xUso8mC23IeZ65TTdPxfVz9mxMzJnM=; b=WSEFsECjoSz5D5liuUW3X/4Ahb5E51qUhsPMSYghYgo3RiKqxCr/NuPBP+SNWDTQZR sPiI1mkRYhpIfEM5BDdO55CMZG2aVbjwwQdAX7YlVsTFoWWNg0ODWzVFjty1nGy/HpKX /fwZ+1Qc7DUrW1ZvFUVlJfPUxYgCC5E02/vGjli2tO7spqfvma3gGZDjKDCcPTtV98ui eziyq0ivdP3AREmw0s3n4cbhHUeRfroCM7tn8omCxLNxwEtsEq2dXlKG4j6wSn2+S/xy qcHHDCckExyt1OT5f26Kt0ri1LXnZnVlg1eH0iv+OKEwyS/ghiZjmorXC8LaGlz5mgTg vs1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PZ8Om298; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id s17-20020a056a0008d100b006910a45a234si3827415pfu.202.2023.11.04.05.59.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Nov 2023 05:59:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PZ8Om298; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 89901803ACA8; Sat, 4 Nov 2023 05:59:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231538AbjKDM7l (ORCPT <rfc822;lhua1029@gmail.com> + 35 others); Sat, 4 Nov 2023 08:59:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbjKDM7k (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 4 Nov 2023 08:59:40 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB9DD194; Sat, 4 Nov 2023 05:59:37 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50943ccbbaeso4211018e87.2; Sat, 04 Nov 2023 05:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699102776; x=1699707576; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ObsqG9+10NLUeAHOgwfeMmWgkHs3rhcD4ztf3mot19o=; b=PZ8Om298AfkI3IiDU1vDX57PE9d+pz4nVDZGp2kDYEamHTPbI3WiIGkHkQbr+htb97 H+F4wvZL5EnxV1wBbBRjvS+cWZeRTWGmFEhBgTic97Xury4x//waV9qddedyCsXOtK2Y +MJezsYQYmGaDoZzh9dxq/1k2+eVsfUE17wBUbQKasAsye3H9HLX7UU1kluU6/po4vdi JZYfup3Ofo1ezX7GZ30J6WE5o8O+F0cV9t9YnmrpO/uNGJICvcPA+iFUyllO+PxMVupM 9nQi5W968d/oXSCORbIlGhrPu0nrEW8IVeLa/Nsn22FRCBRpUc+d6J8gK35NOY4AQdNv iQbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699102776; x=1699707576; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ObsqG9+10NLUeAHOgwfeMmWgkHs3rhcD4ztf3mot19o=; b=B0+4vF6LzkRBbmlISe6UkzHSP6Fka0og2+eNbSYMD8EGqeoPspW3jnQeqxZDvXXQv7 Lk/YLUq6ssYj9NfGuwNdsXzP2b1r5mbFUJc/tZ2EsIpRUL6ghcVP7KPSritbmnRa2zws D1eBwVkAEFYd35rpWO9FyL505q3ULHIjxCozD4o4Ss5HacOGGz6uOxl4vZEDuKTQIeQw uK/9rNIPDVNVzI6Kiy4xyL+LaObb7kKnoyUvnTyIZcwgMV48axmQEyZXKAmxIjyB26p1 3ks9YR73m/pVwYPrWCwH6wqV8y2qJm2F6o9jVDywQZE9CDS8gXF15U6nfkh9F1CRiUHa EGsw== X-Gm-Message-State: AOJu0YybOTBt9+g49KTN4sUyxD3ju8sh0+TBrpzBzwHVF19DAUmhUvNE whhRBsn7Q/Sj5D65Dy2SkNo= X-Received: by 2002:a05:6512:202a:b0:509:4980:7bf0 with SMTP id s10-20020a056512202a00b0050949807bf0mr6170428lfs.38.1699102775647; Sat, 04 Nov 2023 05:59:35 -0700 (PDT) Received: from mars.. ([2a02:168:6806:0:e018:7b08:28f0:78c5]) by smtp.gmail.com with ESMTPSA id r13-20020a05600c458d00b00406443c8b4fsm5707383wmo.19.2023.11.04.05.59.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Nov 2023 05:59:35 -0700 (PDT) From: Klaus Kudielka <klaus.kudielka@gmail.com> To: Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch>, Christian Marangi <ansuelsmth@gmail.com>, "David S . Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Samuel Holland <samuel@sholland.org>, Jisheng Zhang <jszhang@kernel.org>, Li Zetao <lizetao1@huawei.com>, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, Klaus Kudielka <klaus.kudielka@gmail.com> Subject: [PATCH] leds: triggers: netdev: add a check, whether device is up Date: Sat, 4 Nov 2023 13:58:40 +0100 Message-ID: <20231104125840.27914-1-klaus.kudielka@gmail.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Sat, 04 Nov 2023 05:59:45 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781638404843892479 X-GMAIL-MSGID: 1781638404843892479 |
Series |
leds: triggers: netdev: add a check, whether device is up
|
|
Commit Message
Klaus Kudielka
Nov. 4, 2023, 12:58 p.m. UTC
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(-)
Comments
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
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
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
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;