linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
>  
> 





  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).