From: "Heiko Stübner" <heiko@sntech.de>
To: linux-leds@vger.kernel.org, Marek Vasut <marex@denx.de>
Cc: Marek Vasut <marex@denx.de>, Andrew Lunn <andrew@lunn.ch>,
Christian Marangi <ansuelsmth@gmail.com>,
Conor Dooley <conor+dt@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Lee Jones <lee@kernel.org>, Lukasz Majewski <lukma@denx.de>,
Pavel Machek <pavel@ucw.cz>, Rob Herring <robh@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] leds: trigger: netdev: Introduce OF mode configuration using netdev-trigger-mode property
Date: Thu, 07 Aug 2025 23:41:01 +0200 [thread overview]
Message-ID: <3258356.fEcJ0Lxnt5@diego> (raw)
In-Reply-To: <20250113002346.297481-2-marex@denx.de>
Hi Marek,
Am Montag, 13. Januar 2025, 01:23:38 Mitteleuropäische Sommerzeit schrieb Marek Vasut:
> Introduce netdev trigger specific netdev-trigger-mode property which
> is used to configure the netdev trigger mode flags. Those mode flags
> define events on which the LED acts upon when the hardware offload is
> enabled. This is traditionally configured via sysfs, but that depends
> on userspace, which is available too late and makes ethernet PHY LEDs
> not work e.g. when NFS root is being mounted.
>
> For each LED with linux,default-trigger = "netdev" described in DT, the
> optional netdev-trigger-mode property supplies the default configuration
> of the PHY LED mode via DT. This property should be set to a subset of
> TRIGGER_NETDEV_* flags.
>
> For each LED with linux,default-trigger = "netdev" described in DT, the
> netdev trigger is activated during kernel boot. The trigger is extended
> the parse the netdev-trigger-mode property and set it as a default value
> of trigger_data->mode.
>
> It is not possible to immediately configure the LED mode, because the
> interface to which the PHY and the LED is connected to might not be
> attached to the PHY yet. The netdev_trig_notify() is called when the
> PHY got attached to interface, extend netdev_trig_notify() to detect
> the condition where the LED does have netdev trigger configured in DT
> but the mode was not yet configured and configure the baseline mode
> from the notifier. This can reuse most of set_device_name() except for
> the rtnl_lock() which cannot be claimed in the notifier, so split the
> relevant core code into set_device_name_locked() and call only the core
> code.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> drivers/leds/trigger/ledtrig-netdev.c | 51 ++++++++++++++++++++-------
> 1 file changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
> index c15efe3e50780..20dfc9506c0a6 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -23,6 +23,7 @@
> #include <linux/module.h>
> #include <linux/netdevice.h>
> #include <linux/mutex.h>
> +#include <linux/of.h>
> #include <linux/phy.h>
> #include <linux/rtnetlink.h>
> #include <linux/timer.h>
> @@ -256,19 +257,9 @@ static ssize_t device_name_show(struct device *dev,
> return len;
> }
>
> -static int set_device_name(struct led_netdev_data *trigger_data,
> - const char *name, size_t size)
> +static void set_device_name_locked(struct led_netdev_data *trigger_data,
> + const char *name, size_t size)
> {
> - if (size >= IFNAMSIZ)
> - return -EINVAL;
> -
> - cancel_delayed_work_sync(&trigger_data->work);
> -
> - /*
> - * Take RTNL lock before trigger_data lock to prevent potential
> - * deadlock with netdev notifier registration.
> - */
> - rtnl_lock();
> mutex_lock(&trigger_data->lock);
>
> if (trigger_data->net_dev) {
> @@ -298,6 +289,24 @@ static int set_device_name(struct led_netdev_data *trigger_data,
> set_baseline_state(trigger_data);
>
> mutex_unlock(&trigger_data->lock);
> +}
> +
> +static int set_device_name(struct led_netdev_data *trigger_data,
> + const char *name, size_t size)
> +{
> + if (size >= IFNAMSIZ)
> + return -EINVAL;
> +
> + cancel_delayed_work_sync(&trigger_data->work);
> +
> + /*
> + * Take RTNL lock before trigger_data lock to prevent potential
> + * deadlock with netdev notifier registration.
> + */
> + rtnl_lock();
> +
> + set_device_name_locked(trigger_data, name, size);
> +
> rtnl_unlock();
>
> return 0;
> @@ -579,6 +588,20 @@ static int netdev_trig_notify(struct notifier_block *nb,
> && evt != NETDEV_CHANGENAME)
> return NOTIFY_DONE;
>
> + if (evt == NETDEV_REGISTER && !trigger_data->device_name[0] &&
> + led_cdev->hw_control_get && led_cdev->hw_control_set &&
> + led_cdev->hw_control_is_supported) {
> + struct device *ndev = led_cdev->hw_control_get_device(led_cdev);
> + if (ndev) {
> + const char *name = dev_name(ndev);
> +
> + trigger_data->hw_control = true;
> +
> + cancel_delayed_work_sync(&trigger_data->work);
> + set_device_name_locked(trigger_data, name, strlen(name));
> + }
> + }
> +
hmm, somehow this did not work for me as is, because the devicename
never makes it to the trigger. It seems because
phy_led_hw_control_get_device()
of course only returns a device after the phy got attached somewhere and
NULL otherwise.
Testsystem is a Qnap TS233 NAS with RK3568 SoC using a dwmac on
6.16 kernel and 3 LEDs attached to the Motorcomm PHY.
On boot into regular Debian I see some separate steps, generating
events in the netdev trigger:
- dwmac probes and probes the phy
I see a number of expected NETDEV_REGISTER events
- systemd renames the interface to end0
[ 6.502455] rk_gmac-dwmac fe2a0000.ethernet end0: renamed from eth0
[ 6.509696] netdev_trig_notify evt 11
- dhclient end0
[ 62.156033] rk_gmac-dwmac fe2a0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 62.165292] phy_attach_direct
... only here phydev->attached_dev is set ...
[...]
[ 62.240004] rk_gmac-dwmac fe2a0000.ethernet end0: configuring for phy/rgmii link mode
[ 62.250517] netdev_trig_notify evt 1
[ 65.315407] rk_gmac-dwmac fe2a0000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 65.315415] netdev_trig_notify evt 4
changing from
evt == NETDEV_REGISTER
to
evt == NETDEV_UP
in the conditional up there, makes the device_name resolve work for me.
But right now, I have no clue if that is a bit no-no :-)
Or do we want a NETDEV_PHY_ATTACH (+_DETACH) event type ?
I'll try to poke things more
Heiko
> if (!(dev == trigger_data->net_dev ||
> (evt == NETDEV_CHANGENAME && !strcmp(dev->name, trigger_data->device_name)) ||
> (evt == NETDEV_REGISTER && !strcmp(dev->name, trigger_data->device_name))))
> @@ -689,6 +712,7 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
> struct led_netdev_data *trigger_data;
> unsigned long mode = 0;
> struct device *dev;
> + u32 val;
> int rc;
>
> trigger_data = kzalloc(sizeof(struct led_netdev_data), GFP_KERNEL);
> @@ -706,7 +730,8 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
> trigger_data->net_dev = NULL;
> trigger_data->device_name[0] = 0;
>
> - trigger_data->mode = 0;
> + rc = of_property_read_u32(led_cdev->dev->of_node, "netdev-trigger-mode", &val);
> + trigger_data->mode = rc ? 0 : val;
> atomic_set(&trigger_data->interval, msecs_to_jiffies(NETDEV_LED_DEFAULT_INTERVAL));
> trigger_data->last_activity = 0;
>
>
next prev parent reply other threads:[~2025-08-07 21:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 0:23 [PATCH 1/2] dt-bindings: leds: Document netdev trigger netdev-trigger-mode property Marek Vasut
2025-01-13 0:23 ` [PATCH 2/2] leds: trigger: netdev: Introduce OF mode configuration using " Marek Vasut
2025-01-16 13:47 ` Andrew Lunn
2025-01-21 11:27 ` Marek Vasut
2025-08-07 21:41 ` Heiko Stübner [this message]
2025-01-16 13:32 ` [PATCH 1/2] dt-bindings: leds: Document netdev trigger " Andrew Lunn
2025-01-17 16:00 ` Christian Marangi
2025-01-21 0:00 ` Marek Vasut
2025-01-21 11:37 ` Marek Vasut
2025-08-07 10:09 ` Heiko Stübner
2025-08-09 16:29 ` Andrew Lunn
2025-08-09 19:58 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3258356.fEcJ0Lxnt5@diego \
--to=heiko@sntech.de \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hkallweit1@gmail.com \
--cc=jacek.anaszewski@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=lukma@denx.de \
--cc=marex@denx.de \
--cc=pavel@ucw.cz \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).