mbox series

[0/3] leds: trigger: netdev: add additional modes

Message ID 20230609135103.14221-1-ansuelsmth@gmail.com
Headers show
Series leds: trigger: netdev: add additional modes | expand

Message

Christian Marangi June 9, 2023, 1:51 p.m. UTC 
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.

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.
- Mode for unified tx and rx traffic.

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. For the unified tx and rx
mode, we simply add extra logic to the work function we already have in
the netdev trigger.

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/
Christian Marangi (3):
  leds: trigger: netdev: add additional specific link speed mode
  leds: trigger: netdev: add additional specific link duplex mode
  leds: trigger: netdev: add additional mode for unified tx/rx traffic

 drivers/leds/trigger/ledtrig-netdev.c | 129 +++++++++++++++++++++++---
 include/linux/leds.h                  |   6 ++
 2 files changed, 124 insertions(+), 11 deletions(-)

Comments

Andrew Lunn June 9, 2023, 2:25 p.m. UTC | #1 
> +	if (trigger_data->net_dev != NULL) {
> +		struct ethtool_link_ksettings cmd;
> +

cmd is a stack variable, so contains random junk:

>  		trigger_data->carrier_link_up = netif_carrier_ok(trigger_data->net_dev);
>  
> +		if (trigger_data->carrier_link_up) {
> +			rtnl_lock();
> +			__ethtool_get_link_ksettings(trigger_data->net_dev, &cmd);

/* Internal kernel helper to query a device ethtool_link_settings. */
int __ethtool_get_link_ksettings(struct net_device *dev,
				 struct ethtool_link_ksettings *link_ksettings)
{
	ASSERT_RTNL();

	if (!dev->ethtool_ops->get_link_ksettings)
		return -EOPNOTSUPP;

If the op is not implemented, it just returns.


> +			rtnl_unlock();
> +
> +			trigger_data->link_speed = cmd.base.speed;

and now you are accessing the random junk.

> +			__ethtool_get_link_ksettings(trigger_data->net_dev, &cmd);
> +
> +			trigger_data->link_speed = cmd.base.speed;

You have this code three times. I suggest you pull it out into a
little helper, and within the helper, deal with the return code, and
set speed to 0 if it is unknown.

    Andrew
Andrew Lunn June 9, 2023, 2:36 p.m. UTC | #2 
On Fri, Jun 09, 2023 at 03:51:03PM +0200, Christian Marangi wrote:
> Add additional mode for unified tx/rx traffic. LED will blink on both tx
> or rx traffic.
> 
> This is especially useful for PHY and Switch that supports LEDs hw
> control that doesn't support split tx/rx traffic but supports blinking
> on any kind of traffic in the link.
> 
> On mode set from sysfs we check if we have enabled split tx/rx mode and
> reject enabling activity mode to prevent wrong and redundant
> configuration.

TRIGGER_NETDEV_TX + TRIGGER_NETDEV_RX = TRIGGER_NETDEV_ACTIVITY:

When calling into the driver, it probably makes the drivers simpler if
you do this simplification. Within the trigger code, keep them
separate, because that is what the user has configured.

I know such a simplification will make the marvell PHY driver simpler.

	Andrew