All of lore.kernel.org
 help / color / mirror / Atom feed
* [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes
@ 2023-06-19 20:46 Christian Marangi
  2023-06-19 20:46 ` [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode Christian Marangi
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Christian Marangi @ 2023-06-19 20:46 UTC (permalink / raw)
  To: Pavel Machek, Lee Jones, Andrew Lunn, Christian Marangi,
	David S. Miller, Dan Carpenter, linux-leds, linux-kernel, netdev

This is a continue of [1]. It was decided to take a more gradual
approach to implement LEDs support for switch and phy starting with
basic support and then implementing the hw control part when we have all
the prereq done.

This should be the final part for the netdev trigger.
I added net-next tag and added netdev mailing list since I was informed
that this should be merged with netdev branch.

We collect some info around and we found a good set of modes that are
common in almost all the PHY and Switch.

These modes are:
- Modes for dedicated link speed(10, 100, 1000 mbps). Additional mode
  can be added later following this example.
- Modes for half and full duplex.

The original idea was to add hw control only modes.
While the concept makes sense in practice it would results in lots of
additional code and extra check to make sure we are setting correct modes.

With the suggestion from Andrew it was pointed out that using the ethtool
APIs we can actually get the current link speed and duplex and this
effectively removed the problem of having hw control only modes since we
can fallback to software.

Since these modes are supported by software, we can skip providing an
user for this in the LED driver to support hw control for these new modes
(that will come right after this is merged) and prevent this to be another
multi subsystem series.

For link speed and duplex we use ethtool APIs.

To call ethtool APIs, rtnl lock is needed but this can be skipped on
handling netdev events as the lock is already held.

[1] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/

Changes v5:
- Fix conflict error on rebase
- Add Review-by tag by Andrew
Changes v4:
- Add net-next tag
- Add additional patch to expose hw_control via sysfs
- CC netdev mailing list
Changes v3:
- Add Andrew review tag
- Use SPEED_UNKNOWN to init link_speed
- Fix using HALF_DUPLEX as duplex init and use DUPLEX_UNKNOWN instead
Changes v2:
- Drop ACTIVITY patch as it can be handled internally in the LED driver
- Reduce duplicate code and move the link state to a dedicated helper

Christian Marangi (3):
  leds: trigger: netdev: add additional specific link speed mode
  leds: trigger: netdev: add additional specific link duplex mode
  leds: trigger: netdev: expose hw_control status via sysfs

 drivers/leds/trigger/ledtrig-netdev.c | 114 +++++++++++++++++++++++---
 include/linux/leds.h                  |   5 ++
 2 files changed, 109 insertions(+), 10 deletions(-)

-- 
2.40.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode
  2023-06-19 20:46 [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes Christian Marangi
@ 2023-06-19 20:46 ` Christian Marangi
  2023-06-21 14:54   ` Lee Jones
  2023-06-19 20:46 ` [net-next PATCH v5 2/3] leds: trigger: netdev: add additional specific link duplex mode Christian Marangi
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 11+ messages in thread
From: Christian Marangi @ 2023-06-19 20:46 UTC (permalink / raw)
  To: Pavel Machek, Lee Jones, Andrew Lunn, Christian Marangi,
	David S. Miller, Dan Carpenter, linux-leds, linux-kernel, netdev

Add additional modes for specific link speed. Use ethtool APIs to get the
current link speed and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.

This is especially useful for PHY and Switch that supports LEDs hw
control for specific link speed. (example scenario a PHY that have 2 LED
connected one green and one orange where the green is turned on with
1000mbps speed and orange is turned on with 10mpbs speed)

On mode set from sysfs we check if we have enabled split link speed mode
and reject enabling generic link mode to prevent wrong and redundant
configuration.

Rework logic on the set baseline state to support these new modes to
select if we need to turn on or off the LED.

Add additional modes:
- link_10: Turn on LED when link speed is 10mbps
- link_100: Turn on LED when link speed is 100mbps
- link_1000: Turn on LED when link speed is 1000mbps

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/leds/trigger/ledtrig-netdev.c | 80 +++++++++++++++++++++++----
 include/linux/leds.h                  |  3 +
 2 files changed, 73 insertions(+), 10 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
index 2311dae7f070..f625738392bf 100644
--- a/drivers/leds/trigger/ledtrig-netdev.c
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -13,6 +13,7 @@
 #include <linux/atomic.h>
 #include <linux/ctype.h>
 #include <linux/device.h>
+#include <linux/ethtool.h>
 #include <linux/init.h>
 #include <linux/jiffies.h>
 #include <linux/kernel.h>
@@ -21,6 +22,7 @@
 #include <linux/module.h>
 #include <linux/netdevice.h>
 #include <linux/mutex.h>
+#include <linux/rtnetlink.h>
 #include <linux/timer.h>
 #include "../leds.h"
 
@@ -52,6 +54,8 @@ struct led_netdev_data {
 	unsigned int last_activity;
 
 	unsigned long mode;
+	int link_speed;
+
 	bool carrier_link_up;
 	bool hw_control;
 };
@@ -77,7 +81,24 @@ static void set_baseline_state(struct led_netdev_data *trigger_data)
 	if (!trigger_data->carrier_link_up) {
 		led_set_brightness(led_cdev, LED_OFF);
 	} else {
+		bool blink_on = false;
+
 		if (test_bit(TRIGGER_NETDEV_LINK, &trigger_data->mode))
+			blink_on = true;
+
+		if (test_bit(TRIGGER_NETDEV_LINK_10, &trigger_data->mode) &&
+		    trigger_data->link_speed == SPEED_10)
+			blink_on = true;
+
+		if (test_bit(TRIGGER_NETDEV_LINK_100, &trigger_data->mode) &&
+		    trigger_data->link_speed == SPEED_100)
+			blink_on = true;
+
+		if (test_bit(TRIGGER_NETDEV_LINK_1000, &trigger_data->mode) &&
+		    trigger_data->link_speed == SPEED_1000)
+			blink_on = true;
+
+		if (blink_on)
 			led_set_brightness(led_cdev,
 					   led_cdev->blink_brightness);
 		else
@@ -161,6 +182,18 @@ static bool can_hw_control(struct led_netdev_data *trigger_data)
 	return true;
 }
 
+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);
+	if (!trigger_data->carrier_link_up)
+		return;
+
+	if (!__ethtool_get_link_ksettings(trigger_data->net_dev, &cmd))
+		trigger_data->link_speed = cmd.base.speed;
+}
+
 static ssize_t device_name_show(struct device *dev,
 				struct device_attribute *attr, char *buf)
 {
@@ -196,8 +229,12 @@ static int set_device_name(struct led_netdev_data *trigger_data,
 		    dev_get_by_name(&init_net, trigger_data->device_name);
 
 	trigger_data->carrier_link_up = false;
-	if (trigger_data->net_dev != NULL)
-		trigger_data->carrier_link_up = netif_carrier_ok(trigger_data->net_dev);
+	trigger_data->link_speed = SPEED_UNKNOWN;
+	if (trigger_data->net_dev != NULL) {
+		rtnl_lock();
+		get_device_state(trigger_data);
+		rtnl_unlock();
+	}
 
 	trigger_data->last_activity = 0;
 
@@ -234,6 +271,9 @@ static ssize_t netdev_led_attr_show(struct device *dev, char *buf,
 
 	switch (attr) {
 	case TRIGGER_NETDEV_LINK:
+	case TRIGGER_NETDEV_LINK_10:
+	case TRIGGER_NETDEV_LINK_100:
+	case TRIGGER_NETDEV_LINK_1000:
 	case TRIGGER_NETDEV_TX:
 	case TRIGGER_NETDEV_RX:
 		bit = attr;
@@ -249,7 +289,7 @@ static ssize_t netdev_led_attr_store(struct device *dev, const char *buf,
 				     size_t size, enum led_trigger_netdev_modes attr)
 {
 	struct led_netdev_data *trigger_data = led_trigger_get_drvdata(dev);
-	unsigned long state;
+	unsigned long state, mode = trigger_data->mode;
 	int ret;
 	int bit;
 
@@ -259,6 +299,9 @@ static ssize_t netdev_led_attr_store(struct device *dev, const char *buf,
 
 	switch (attr) {
 	case TRIGGER_NETDEV_LINK:
+	case TRIGGER_NETDEV_LINK_10:
+	case TRIGGER_NETDEV_LINK_100:
+	case TRIGGER_NETDEV_LINK_1000:
 	case TRIGGER_NETDEV_TX:
 	case TRIGGER_NETDEV_RX:
 		bit = attr;
@@ -267,13 +310,20 @@ static ssize_t netdev_led_attr_store(struct device *dev, const char *buf,
 		return -EINVAL;
 	}
 
-	cancel_delayed_work_sync(&trigger_data->work);
-
 	if (state)
-		set_bit(bit, &trigger_data->mode);
+		set_bit(bit, &mode);
 	else
-		clear_bit(bit, &trigger_data->mode);
+		clear_bit(bit, &mode);
+
+	if (test_bit(TRIGGER_NETDEV_LINK, &mode) &&
+	    (test_bit(TRIGGER_NETDEV_LINK_10, &mode) ||
+	     test_bit(TRIGGER_NETDEV_LINK_100, &mode) ||
+	     test_bit(TRIGGER_NETDEV_LINK_1000, &mode)))
+		return -EINVAL;
+
+	cancel_delayed_work_sync(&trigger_data->work);
 
+	trigger_data->mode = mode;
 	trigger_data->hw_control = can_hw_control(trigger_data);
 
 	set_baseline_state(trigger_data);
@@ -295,6 +345,9 @@ static ssize_t netdev_led_attr_store(struct device *dev, const char *buf,
 	static DEVICE_ATTR_RW(trigger_name)
 
 DEFINE_NETDEV_TRIGGER(link, TRIGGER_NETDEV_LINK);
+DEFINE_NETDEV_TRIGGER(link_10, TRIGGER_NETDEV_LINK_10);
+DEFINE_NETDEV_TRIGGER(link_100, TRIGGER_NETDEV_LINK_100);
+DEFINE_NETDEV_TRIGGER(link_1000, TRIGGER_NETDEV_LINK_1000);
 DEFINE_NETDEV_TRIGGER(tx, TRIGGER_NETDEV_TX);
 DEFINE_NETDEV_TRIGGER(rx, TRIGGER_NETDEV_RX);
 
@@ -338,6 +391,9 @@ static DEVICE_ATTR_RW(interval);
 static struct attribute *netdev_trig_attrs[] = {
 	&dev_attr_device_name.attr,
 	&dev_attr_link.attr,
+	&dev_attr_link_10.attr,
+	&dev_attr_link_100.attr,
+	&dev_attr_link_1000.attr,
 	&dev_attr_rx.attr,
 	&dev_attr_tx.attr,
 	&dev_attr_interval.attr,
@@ -368,9 +424,10 @@ static int netdev_trig_notify(struct notifier_block *nb,
 	mutex_lock(&trigger_data->lock);
 
 	trigger_data->carrier_link_up = false;
+	trigger_data->link_speed = SPEED_UNKNOWN;
 	switch (evt) {
 	case NETDEV_CHANGENAME:
-		trigger_data->carrier_link_up = netif_carrier_ok(dev);
+		get_device_state(trigger_data);
 		fallthrough;
 	case NETDEV_REGISTER:
 		if (trigger_data->net_dev)
@@ -384,7 +441,7 @@ static int netdev_trig_notify(struct notifier_block *nb,
 		break;
 	case NETDEV_UP:
 	case NETDEV_CHANGE:
-		trigger_data->carrier_link_up = netif_carrier_ok(dev);
+		get_device_state(trigger_data);
 		break;
 	}
 
@@ -427,7 +484,10 @@ static void netdev_trig_work(struct work_struct *work)
 	if (trigger_data->last_activity != new_activity) {
 		led_stop_software_blink(trigger_data->led_cdev);
 
-		invert = test_bit(TRIGGER_NETDEV_LINK, &trigger_data->mode);
+		invert = test_bit(TRIGGER_NETDEV_LINK, &trigger_data->mode) ||
+			 test_bit(TRIGGER_NETDEV_LINK_10, &trigger_data->mode) ||
+			 test_bit(TRIGGER_NETDEV_LINK_100, &trigger_data->mode) ||
+			 test_bit(TRIGGER_NETDEV_LINK_1000, &trigger_data->mode);
 		interval = jiffies_to_msecs(
 				atomic_read(&trigger_data->interval));
 		/* base state is ON (link present) */
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 8af62ff431f0..126b79019429 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -555,6 +555,9 @@ static inline void *led_get_trigger_data(struct led_classdev *led_cdev)
 /* Trigger specific enum */
 enum led_trigger_netdev_modes {
 	TRIGGER_NETDEV_LINK = 0,
+	TRIGGER_NETDEV_LINK_10,
+	TRIGGER_NETDEV_LINK_100,
+	TRIGGER_NETDEV_LINK_1000,
 	TRIGGER_NETDEV_TX,
 	TRIGGER_NETDEV_RX,
 
-- 
2.40.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [net-next PATCH v5 2/3] leds: trigger: netdev: add additional specific link duplex mode
  2023-06-19 20:46 [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes Christian Marangi
  2023-06-19 20:46 ` [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode Christian Marangi
@ 2023-06-19 20:46 ` Christian Marangi
  2023-06-21 14:55   ` Lee Jones
  2023-06-19 20:47 ` [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs Christian Marangi
  2023-06-21 22:10 ` [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes patchwork-bot+netdevbpf
  3 siblings, 1 reply; 11+ messages in thread
From: Christian Marangi @ 2023-06-19 20:46 UTC (permalink / raw)
  To: Pavel Machek, Lee Jones, Andrew Lunn, Christian Marangi,
	David S. Miller, Dan Carpenter, linux-leds, linux-kernel, netdev

Add additional modes for specific link duplex. Use ethtool APIs to get the
current link duplex and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.

This is especially useful for PHY and Switch that supports LEDs hw
control for specific link duplex.

Add additional modes:
- half_duplex: Turn on LED when link is half duplex
- full_duplex: Turn on LED when link is full duplex

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/leds/trigger/ledtrig-netdev.c | 27 +++++++++++++++++++++++++--
 include/linux/leds.h                  |  2 ++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
index f625738392bf..2c1c9e95860e 100644
--- a/drivers/leds/trigger/ledtrig-netdev.c
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -55,6 +55,7 @@ struct led_netdev_data {
 
 	unsigned long mode;
 	int link_speed;
+	u8 duplex;
 
 	bool carrier_link_up;
 	bool hw_control;
@@ -98,6 +99,14 @@ static void set_baseline_state(struct led_netdev_data *trigger_data)
 		    trigger_data->link_speed == SPEED_1000)
 			blink_on = true;
 
+		if (test_bit(TRIGGER_NETDEV_HALF_DUPLEX, &trigger_data->mode) &&
+		    trigger_data->duplex == DUPLEX_HALF)
+			blink_on = true;
+
+		if (test_bit(TRIGGER_NETDEV_FULL_DUPLEX, &trigger_data->mode) &&
+		    trigger_data->duplex == DUPLEX_FULL)
+			blink_on = true;
+
 		if (blink_on)
 			led_set_brightness(led_cdev,
 					   led_cdev->blink_brightness);
@@ -190,8 +199,10 @@ static void get_device_state(struct led_netdev_data *trigger_data)
 	if (!trigger_data->carrier_link_up)
 		return;
 
-	if (!__ethtool_get_link_ksettings(trigger_data->net_dev, &cmd))
+	if (!__ethtool_get_link_ksettings(trigger_data->net_dev, &cmd)) {
 		trigger_data->link_speed = cmd.base.speed;
+		trigger_data->duplex = cmd.base.duplex;
+	}
 }
 
 static ssize_t device_name_show(struct device *dev,
@@ -230,6 +241,7 @@ static int set_device_name(struct led_netdev_data *trigger_data,
 
 	trigger_data->carrier_link_up = false;
 	trigger_data->link_speed = SPEED_UNKNOWN;
+	trigger_data->duplex = DUPLEX_UNKNOWN;
 	if (trigger_data->net_dev != NULL) {
 		rtnl_lock();
 		get_device_state(trigger_data);
@@ -274,6 +286,8 @@ static ssize_t netdev_led_attr_show(struct device *dev, char *buf,
 	case TRIGGER_NETDEV_LINK_10:
 	case TRIGGER_NETDEV_LINK_100:
 	case TRIGGER_NETDEV_LINK_1000:
+	case TRIGGER_NETDEV_HALF_DUPLEX:
+	case TRIGGER_NETDEV_FULL_DUPLEX:
 	case TRIGGER_NETDEV_TX:
 	case TRIGGER_NETDEV_RX:
 		bit = attr;
@@ -302,6 +316,8 @@ static ssize_t netdev_led_attr_store(struct device *dev, const char *buf,
 	case TRIGGER_NETDEV_LINK_10:
 	case TRIGGER_NETDEV_LINK_100:
 	case TRIGGER_NETDEV_LINK_1000:
+	case TRIGGER_NETDEV_HALF_DUPLEX:
+	case TRIGGER_NETDEV_FULL_DUPLEX:
 	case TRIGGER_NETDEV_TX:
 	case TRIGGER_NETDEV_RX:
 		bit = attr;
@@ -348,6 +364,8 @@ DEFINE_NETDEV_TRIGGER(link, TRIGGER_NETDEV_LINK);
 DEFINE_NETDEV_TRIGGER(link_10, TRIGGER_NETDEV_LINK_10);
 DEFINE_NETDEV_TRIGGER(link_100, TRIGGER_NETDEV_LINK_100);
 DEFINE_NETDEV_TRIGGER(link_1000, TRIGGER_NETDEV_LINK_1000);
+DEFINE_NETDEV_TRIGGER(half_duplex, TRIGGER_NETDEV_HALF_DUPLEX);
+DEFINE_NETDEV_TRIGGER(full_duplex, TRIGGER_NETDEV_FULL_DUPLEX);
 DEFINE_NETDEV_TRIGGER(tx, TRIGGER_NETDEV_TX);
 DEFINE_NETDEV_TRIGGER(rx, TRIGGER_NETDEV_RX);
 
@@ -394,6 +412,8 @@ static struct attribute *netdev_trig_attrs[] = {
 	&dev_attr_link_10.attr,
 	&dev_attr_link_100.attr,
 	&dev_attr_link_1000.attr,
+	&dev_attr_full_duplex.attr,
+	&dev_attr_half_duplex.attr,
 	&dev_attr_rx.attr,
 	&dev_attr_tx.attr,
 	&dev_attr_interval.attr,
@@ -425,6 +445,7 @@ static int netdev_trig_notify(struct notifier_block *nb,
 
 	trigger_data->carrier_link_up = false;
 	trigger_data->link_speed = SPEED_UNKNOWN;
+	trigger_data->duplex = DUPLEX_UNKNOWN;
 	switch (evt) {
 	case NETDEV_CHANGENAME:
 		get_device_state(trigger_data);
@@ -487,7 +508,9 @@ static void netdev_trig_work(struct work_struct *work)
 		invert = test_bit(TRIGGER_NETDEV_LINK, &trigger_data->mode) ||
 			 test_bit(TRIGGER_NETDEV_LINK_10, &trigger_data->mode) ||
 			 test_bit(TRIGGER_NETDEV_LINK_100, &trigger_data->mode) ||
-			 test_bit(TRIGGER_NETDEV_LINK_1000, &trigger_data->mode);
+			 test_bit(TRIGGER_NETDEV_LINK_1000, &trigger_data->mode) ||
+			 test_bit(TRIGGER_NETDEV_HALF_DUPLEX, &trigger_data->mode) ||
+			 test_bit(TRIGGER_NETDEV_FULL_DUPLEX, &trigger_data->mode);
 		interval = jiffies_to_msecs(
 				atomic_read(&trigger_data->interval));
 		/* base state is ON (link present) */
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 126b79019429..3a65ff72bb04 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -558,6 +558,8 @@ enum led_trigger_netdev_modes {
 	TRIGGER_NETDEV_LINK_10,
 	TRIGGER_NETDEV_LINK_100,
 	TRIGGER_NETDEV_LINK_1000,
+	TRIGGER_NETDEV_HALF_DUPLEX,
+	TRIGGER_NETDEV_FULL_DUPLEX,
 	TRIGGER_NETDEV_TX,
 	TRIGGER_NETDEV_RX,
 
-- 
2.40.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs
  2023-06-19 20:46 [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes Christian Marangi
  2023-06-19 20:46 ` [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode Christian Marangi
  2023-06-19 20:46 ` [net-next PATCH v5 2/3] leds: trigger: netdev: add additional specific link duplex mode Christian Marangi
@ 2023-06-19 20:47 ` Christian Marangi
  2023-06-20  3:50   ` Kalesh Anakkur Purayil
  2023-06-21 14:55   ` Lee Jones
  2023-06-21 22:10 ` [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes patchwork-bot+netdevbpf
  3 siblings, 2 replies; 11+ messages in thread
From: Christian Marangi @ 2023-06-19 20:47 UTC (permalink / raw)
  To: Pavel Machek, Lee Jones, Andrew Lunn, Christian Marangi,
	David S. Miller, Dan Carpenter, linux-leds, linux-kernel, netdev

Expose hw_control status via sysfs for the netdev trigger to give
userspace better understanding of the current state of the trigger and
the LED.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/leds/trigger/ledtrig-netdev.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
index 2c1c9e95860e..32b66703068a 100644
--- a/drivers/leds/trigger/ledtrig-netdev.c
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -406,6 +406,16 @@ static ssize_t interval_store(struct device *dev,
 
 static DEVICE_ATTR_RW(interval);
 
+static ssize_t hw_control_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	struct led_netdev_data *trigger_data = led_trigger_get_drvdata(dev);
+
+	return sprintf(buf, "%d\n", trigger_data->hw_control);
+}
+
+static DEVICE_ATTR_RO(hw_control);
+
 static struct attribute *netdev_trig_attrs[] = {
 	&dev_attr_device_name.attr,
 	&dev_attr_link.attr,
@@ -417,6 +427,7 @@ static struct attribute *netdev_trig_attrs[] = {
 	&dev_attr_rx.attr,
 	&dev_attr_tx.attr,
 	&dev_attr_interval.attr,
+	&dev_attr_hw_control.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(netdev_trig);
-- 
2.40.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs
  2023-06-19 20:47 ` [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs Christian Marangi
@ 2023-06-20  3:50   ` Kalesh Anakkur Purayil
  2023-06-20 13:21     ` Andrew Lunn
  2023-06-21 14:55   ` Lee Jones
  1 sibling, 1 reply; 11+ messages in thread
From: Kalesh Anakkur Purayil @ 2023-06-20  3:50 UTC (permalink / raw)
  To: Christian Marangi
  Cc: Pavel Machek, Lee Jones, Andrew Lunn, David S. Miller,
	Dan Carpenter, linux-leds, linux-kernel, netdev


[-- Attachment #1.1: Type: text/plain, Size: 1637 bytes --]

On Tue, Jun 20, 2023 at 2:18 AM Christian Marangi <ansuelsmth@gmail.com>
wrote:

> Expose hw_control status via sysfs for the netdev trigger to give
> userspace better understanding of the current state of the trigger and
> the LED.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  drivers/leds/trigger/ledtrig-netdev.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c
> b/drivers/leds/trigger/ledtrig-netdev.c
> index 2c1c9e95860e..32b66703068a 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -406,6 +406,16 @@ static ssize_t interval_store(struct device *dev,
>
>  static DEVICE_ATTR_RW(interval);
>
> +static ssize_t hw_control_show(struct device *dev,
> +                              struct device_attribute *attr, char *buf)
> +{
> +       struct led_netdev_data *trigger_data =
> led_trigger_get_drvdata(dev);
> +
> +       return sprintf(buf, "%d\n", trigger_data->hw_control);
>
[Kalesh]: How about using sysfs_emit?

> +}
> +
> +static DEVICE_ATTR_RO(hw_control);
> +
>  static struct attribute *netdev_trig_attrs[] = {
>         &dev_attr_device_name.attr,
>         &dev_attr_link.attr,
> @@ -417,6 +427,7 @@ static struct attribute *netdev_trig_attrs[] = {
>         &dev_attr_rx.attr,
>         &dev_attr_tx.attr,
>         &dev_attr_interval.attr,
> +       &dev_attr_hw_control.attr,
>         NULL
>  };
>  ATTRIBUTE_GROUPS(netdev_trig);
> --
> 2.40.1
>
>
>

-- 
Regards,
Kalesh A P

[-- Attachment #1.2: Type: text/html, Size: 2529 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs
  2023-06-20  3:50   ` Kalesh Anakkur Purayil
@ 2023-06-20 13:21     ` Andrew Lunn
  2023-06-20 14:25       ` Kalesh Anakkur Purayil
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2023-06-20 13:21 UTC (permalink / raw)
  To: Kalesh Anakkur Purayil
  Cc: Christian Marangi, Pavel Machek, Lee Jones, David S. Miller,
	Dan Carpenter, linux-leds, linux-kernel, netdev

>     +static ssize_t hw_control_show(struct device *dev,
>     +                              struct device_attribute *attr, char *buf)
>     +{
>     +       struct led_netdev_data *trigger_data = led_trigger_get_drvdata
>     (dev);
>     +
>     +       return sprintf(buf, "%d\n", trigger_data->hw_control);
> 
> [Kalesh]: How about using sysfs_emit? 

Currently, there are zero instances of sysfs_emit() in ledtrig-netdev,
and in any files in drivers/leds/trigger/, or even drivers/leds.

So i think it would be better to keep this consistent with the rest of
the code in this file, and have a follow up patchset which reviews and
converts the 52 sprintf() in drivers/leds.

	 Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs
  2023-06-20 13:21     ` Andrew Lunn
@ 2023-06-20 14:25       ` Kalesh Anakkur Purayil
  0 siblings, 0 replies; 11+ messages in thread
From: Kalesh Anakkur Purayil @ 2023-06-20 14:25 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Christian Marangi, Pavel Machek, Lee Jones, David S. Miller,
	Dan Carpenter, linux-leds, linux-kernel, netdev


[-- Attachment #1.1: Type: text/plain, Size: 952 bytes --]

On Tue, Jun 20, 2023 at 6:51 PM Andrew Lunn <andrew@lunn.ch> wrote:

> >     +static ssize_t hw_control_show(struct device *dev,
> >     +                              struct device_attribute *attr, char
> *buf)
> >     +{
> >     +       struct led_netdev_data *trigger_data =
> led_trigger_get_drvdata
> >     (dev);
> >     +
> >     +       return sprintf(buf, "%d\n", trigger_data->hw_control);
> >
> > [Kalesh]: How about using sysfs_emit?
>
> Currently, there are zero instances of sysfs_emit() in ledtrig-netdev,
> and in any files in drivers/leds/trigger/, or even drivers/leds.
>
> So i think it would be better to keep this consistent with the rest of
> the code in this file, and have a follow up patchset which reviews and
> converts the 52 sprintf() in drivers/leds.
>
Sounds good, thank you

Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>

>
>          Andrew
>


-- 
Regards,
Kalesh A P

[-- Attachment #1.2: Type: text/html, Size: 1744 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode
  2023-06-19 20:46 ` [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode Christian Marangi
@ 2023-06-21 14:54   ` Lee Jones
  0 siblings, 0 replies; 11+ messages in thread
From: Lee Jones @ 2023-06-21 14:54 UTC (permalink / raw)
  To: Christian Marangi
  Cc: Pavel Machek, Andrew Lunn, David S. Miller, Dan Carpenter,
	linux-leds, linux-kernel, netdev

On Mon, 19 Jun 2023, Christian Marangi wrote:

> Add additional modes for specific link speed. Use ethtool APIs to get the
> current link speed and enable the LED accordingly. Under netdev event
> handler the rtnl lock is already held and is not needed to be set to
> access ethtool APIs.
> 
> This is especially useful for PHY and Switch that supports LEDs hw
> control for specific link speed. (example scenario a PHY that have 2 LED
> connected one green and one orange where the green is turned on with
> 1000mbps speed and orange is turned on with 10mpbs speed)
> 
> On mode set from sysfs we check if we have enabled split link speed mode
> and reject enabling generic link mode to prevent wrong and redundant
> configuration.
> 
> Rework logic on the set baseline state to support these new modes to
> select if we need to turn on or off the LED.
> 
> Add additional modes:
> - link_10: Turn on LED when link speed is 10mbps
> - link_100: Turn on LED when link speed is 100mbps
> - link_1000: Turn on LED when link speed is 1000mbps
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  drivers/leds/trigger/ledtrig-netdev.c | 80 +++++++++++++++++++++++----
>  include/linux/leds.h                  |  3 +
>  2 files changed, 73 insertions(+), 10 deletions(-)

Acked-by: Lee Jones <lee@kernel.org>

-- 
Lee Jones [李琼斯]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 2/3] leds: trigger: netdev: add additional specific link duplex mode
  2023-06-19 20:46 ` [net-next PATCH v5 2/3] leds: trigger: netdev: add additional specific link duplex mode Christian Marangi
@ 2023-06-21 14:55   ` Lee Jones
  0 siblings, 0 replies; 11+ messages in thread
From: Lee Jones @ 2023-06-21 14:55 UTC (permalink / raw)
  To: Christian Marangi
  Cc: Pavel Machek, Andrew Lunn, David S. Miller, Dan Carpenter,
	linux-leds, linux-kernel, netdev

On Mon, 19 Jun 2023, Christian Marangi wrote:

> Add additional modes for specific link duplex. Use ethtool APIs to get the
> current link duplex and enable the LED accordingly. Under netdev event
> handler the rtnl lock is already held and is not needed to be set to
> access ethtool APIs.
> 
> This is especially useful for PHY and Switch that supports LEDs hw
> control for specific link duplex.
> 
> Add additional modes:
> - half_duplex: Turn on LED when link is half duplex
> - full_duplex: Turn on LED when link is full duplex
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  drivers/leds/trigger/ledtrig-netdev.c | 27 +++++++++++++++++++++++++--
>  include/linux/leds.h                  |  2 ++
>  2 files changed, 27 insertions(+), 2 deletions(-)

Acked-by: Lee Jones <lee@kernel.org>

-- 
Lee Jones [李琼斯]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs
  2023-06-19 20:47 ` [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs Christian Marangi
  2023-06-20  3:50   ` Kalesh Anakkur Purayil
@ 2023-06-21 14:55   ` Lee Jones
  1 sibling, 0 replies; 11+ messages in thread
From: Lee Jones @ 2023-06-21 14:55 UTC (permalink / raw)
  To: Christian Marangi
  Cc: Pavel Machek, Andrew Lunn, David S. Miller, Dan Carpenter,
	linux-leds, linux-kernel, netdev

On Mon, 19 Jun 2023, Christian Marangi wrote:

> Expose hw_control status via sysfs for the netdev trigger to give
> userspace better understanding of the current state of the trigger and
> the LED.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  drivers/leds/trigger/ledtrig-netdev.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)

Acked-by: Lee Jones <lee@kernel.org>

-- 
Lee Jones [李琼斯]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes
  2023-06-19 20:46 [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes Christian Marangi
                   ` (2 preceding siblings ...)
  2023-06-19 20:47 ` [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs Christian Marangi
@ 2023-06-21 22:10 ` patchwork-bot+netdevbpf
  3 siblings, 0 replies; 11+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-06-21 22:10 UTC (permalink / raw)
  To: Christian Marangi
  Cc: pavel, lee, andrew, davem, dan.carpenter, linux-leds,
	linux-kernel, netdev

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 19 Jun 2023 22:46:57 +0200 you wrote:
> This is a continue of [1]. It was decided to take a more gradual
> approach to implement LEDs support for switch and phy starting with
> basic support and then implementing the hw control part when we have all
> the prereq done.
> 
> This should be the final part for the netdev trigger.
> I added net-next tag and added netdev mailing list since I was informed
> that this should be merged with netdev branch.
> 
> [...]

Here is the summary with links:
  - [net-next,v5,1/3] leds: trigger: netdev: add additional specific link speed mode
    https://git.kernel.org/netdev/net-next/c/d5e01266e7f5
  - [net-next,v5,2/3] leds: trigger: netdev: add additional specific link duplex mode
    https://git.kernel.org/netdev/net-next/c/f22f95b9ff15
  - [net-next,v5,3/3] leds: trigger: netdev: expose hw_control status via sysfs
    https://git.kernel.org/netdev/net-next/c/b655892ffd6d

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-06-21 22:10 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-19 20:46 [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes Christian Marangi
2023-06-19 20:46 ` [net-next PATCH v5 1/3] leds: trigger: netdev: add additional specific link speed mode Christian Marangi
2023-06-21 14:54   ` Lee Jones
2023-06-19 20:46 ` [net-next PATCH v5 2/3] leds: trigger: netdev: add additional specific link duplex mode Christian Marangi
2023-06-21 14:55   ` Lee Jones
2023-06-19 20:47 ` [net-next PATCH v5 3/3] leds: trigger: netdev: expose hw_control status via sysfs Christian Marangi
2023-06-20  3:50   ` Kalesh Anakkur Purayil
2023-06-20 13:21     ` Andrew Lunn
2023-06-20 14:25       ` Kalesh Anakkur Purayil
2023-06-21 14:55   ` Lee Jones
2023-06-21 22:10 ` [net-next PATCH v5 0/3] leds: trigger: netdev: add additional modes patchwork-bot+netdevbpf

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.