Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Michael Walle <michael@walle.cc>,
	andrew@lunn.ch, anthony.l.nguyen@intel.com,
	bigeasy@linutronix.de, davem@davemloft.net,
	dvorax.fuxbrumer@linux.intel.com, f.fainelli@gmail.com,
	jacek.anaszewski@gmail.com, kuba@kernel.org, kurt@linutronix.de,
	linux-leds@vger.kernel.org, netdev@vger.kernel.org, pavel@ucw.cz,
	sasha.neftin@intel.com, vinicius.gomes@intel.com,
	vitaly.lifshits@intel.com
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs
Date: Thu, 29 Jul 2021 10:59:01 +0200	[thread overview]
Message-ID: <20210729105901.35a73431@thinkpad> (raw)
In-Reply-To: <25d3e798-09f5-56b5-5764-c60435109dd2@gmail.com>

Hello Heiner,

On Wed, 28 Jul 2021 22:43:30 +0200
Heiner Kallweit <hkallweit1@gmail.com> wrote:

> Did we come to any conclusion?
> 
> My preliminary r8169 implementation now creates the following LED names:
> 
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300
> 
> I understood that LEDs should at least be renamed to r8169-0300::link-0
> to link-2 Is this correct? Or do we have to wait with any network LED support
> for a name discussion outcome?

I would expect some of the LEDs to, by default, indicate activity.
So maybe look at the settings BIOS left, and if the setting is to
indicate link, use the "link" function, and if activity, use the
"activity" function? 

> For the different LED modes I defined private hw triggers (using trigger_type
> to make the triggers usable with r8169 LEDs only). The trigger attribute now
> looks like this:
> 
> [none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT
>
> Nice, or? Issue is just that these trigger names really should be made a
> standard for all network LEDs. I don't care about the exact naming, important
> is just that trigger names are the same, no matter whether it's about a r8169-
> or igc- or whatever network chip controlled LEDs.

This is how I at first proposed doing this, last year. But this is
WRONG!

First, we do not want a different trigger for each possible
configuration. We want one trigger, and then choose configuration via
other sysfs file. I.e. a "hw" trigger, which, when activated, would
create sysfs files "link" and "act", via which you can configure those
options.

Second, we already have a standard LED trigger for network devices,
netdev! So what we should do is use the netdev trigger, and offload
blinking to the LED controller if it supports it. The problems with
this are:
1. not yet implemented in upstream, see my latest version
   https://lore.kernel.org/linux-leds/20210601005155.27997-1-kabel@kernel.org/
2. netdev trigger currently does not support all these different link
   functions. We have these settings:
     device_name: network interface name, i.e. eth0
     link: 0 - do not indicate link
           1 - indicate link (ON when linked)
     tx: 0 - do not blink on transmit
         1 - blink on transmit
     rx: 0 - do not blink on receive
         1 - blink on receive
     interval: duration of LED blink in ms

I would like to extend netdev trigger to support different
configurations. Currently my ideas are as follows:
- a new sysfs file, "advanced", will show up when netdev trigger is
  enabled (and if support is compiled in)
- when advanced is set to 1, for each possible link mode (10base-t,
  100base-t, 1000base-t, ...) a new sysfs directory will show up, and
  in each of these directories the following files:
    rx, tx, link, interval, brightness
    multi_intensity (if the LED is a multi-color LED)
  and possibly even
    pattern
With this, the user can configure more complicated configurations:
- different LED color for different link speeds
- different blink speed for different link speeds
And if some of the configurations are offloadable to the HW, the drivers
can be written to support such offloading. (Maybe even add a read-only
file "offloaded" to indicate if the trigger was offloaded.)

I will work on these ideas in the following weeks and will sent
proposals to linux-leds.

> And I don't have a good solution for initialization yet. LED mode is whatever
> BIOS sets, but initial trigger value is "none". I would have to read the
> initial LED control register values, iterate over the triggers to find the
> matching one, and call led_trigger_set() to properly set this trigger as
> current trigger.

You can set led_cdev->default_trigger prior registering the LED. But
this is moot: we do not want a different trigger for each PHY interface
mode.

Marek

  parent reply	other threads:[~2021-07-29  8:59 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16 21:24 [PATCH net-next 0/5][pull request] 1GbE Intel Wired LAN Driver Updates 2021-07-16 Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 1/5] igc: Add possibility to add flex filter Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 2/5] igc: Integrate flex filter into ethtool ops Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 3/5] igc: Allow for Flex Filters to be installed Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 4/5] igc: Make flex filter more flexible Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 5/5] igc: Export LEDs Tony Nguyen
2021-07-16 21:56   ` Andrew Lunn
2021-07-18 22:10     ` Heiner Kallweit
2021-07-18 22:33       ` Andrew Lunn
2021-07-19  6:17         ` Kurt Kanzenbach
2021-07-19  9:46           ` Jakub Kicinski
2021-07-19  6:06     ` Kurt Kanzenbach
2021-07-19 13:15       ` Andrew Lunn
2021-07-20  8:54         ` Kurt Kanzenbach
2021-07-21 19:18         ` Marek Behún
2021-07-18 22:19   ` Heiner Kallweit
2021-07-19  0:40     ` Andrew Lunn
2021-07-20 15:00       ` Heiner Kallweit
2021-07-20 15:42         ` Andrew Lunn
2021-07-20 20:29           ` Heiner Kallweit
2021-07-21 14:35             ` Andrew Lunn
2021-07-21 16:02               ` Heiner Kallweit
2021-07-21 18:23               ` Pavel Machek
2021-07-21 18:25                 ` Pavel Machek
2021-07-21 18:45             ` Marek Behún
2021-07-21 19:50               ` Andrew Lunn
2021-07-21 20:07                 ` Marek Behún
2021-07-21 20:54                   ` Andrew Lunn
2021-07-21 21:31                     ` Marek Behún
2021-07-21 22:45                     ` Pavel Machek
2021-07-22  1:45                       ` Andrew Lunn
2021-07-22  2:19                         ` Marek Behún
2021-07-21 22:34                   ` Pavel Machek
2021-07-22  3:52                   ` Florian Fainelli
2021-07-26 17:42                   ` Jacek Anaszewski
2021-07-26 18:44                     ` Marek Behún
2021-07-26 20:59                     ` Heiner Kallweit
2021-07-27  0:06                       ` Marek Behún
2021-07-27  1:57                         ` Andrew Lunn
2021-07-27  8:15                           ` Michael Walle
2021-07-27 14:56                             ` Marek Behún
2021-07-27 15:03                               ` Michael Walle
2021-07-27 15:24                                 ` Andrew Lunn
2021-07-27 15:28                                 ` Marek Behún
2021-07-27 15:53                                   ` Michael Walle
2021-07-27 16:23                                     ` Andrew Lunn
2021-07-27 16:32                                     ` Marek Behún
2021-07-27 16:42                                       ` Andrew Lunn
2021-07-27 19:42                                       ` Michael Walle
2021-07-28 20:43                                       ` Heiner Kallweit
2021-07-29  6:39                                         ` Kurt Kanzenbach
2021-07-29  8:59                                         ` Marek Behún [this message]
2021-07-29 21:54                                           ` Heiner Kallweit
2021-08-10 17:29                                         ` Pavel Machek
2021-08-10 17:55                                           ` Marek Behún
2021-08-10 19:53                                             ` Pavel Machek
2021-08-10 20:53                                               ` Marek Behún
2021-08-17 19:02                                                 ` Pavel Machek
2021-08-25 15:26                                                   ` Marek Behún
2021-08-26 12:45                                                     ` Pavel Machek
2021-08-10 20:46                                           ` Heiner Kallweit
2021-08-10 21:21                                             ` Andrew Lunn
2021-07-27 13:55                           ` Marek Behún
2021-08-10 17:22                             ` Documentation for naming LEDs was " Pavel Machek
2021-07-19 21:48   ` Jesse Brandeburg
2021-07-20 13:31     ` Kurt Kanzenbach
2021-07-17  0:30 ` [PATCH net-next 0/5][pull request] 1GbE Intel Wired LAN Driver Updates 2021-07-16 patchwork-bot+netdevbpf
2021-07-17 17:36   ` Andrew Lunn

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=20210729105901.35a73431@thinkpad \
    --to=kabel@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=dvorax.fuxbrumer@linux.intel.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-leds@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sasha.neftin@intel.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vitaly.lifshits@intel.com \
    --subject='Re: [PATCH net-next 5/5] igc: Export LEDs' \
    /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

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