Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs

[Marek Behún]

On Thu, 10 Sep 2020 15:15:41 +0200
Andrew Lunn <andrew@xxxxxxx> wrote:

> On Thu, Sep 10, 2020 at 02:23:41PM +0200, Pavel Machek wrote:
> > On Wed 2020-09-09 18:25:51, Marek Behún wrote:  
> > > This patch adds support for controlling the LEDs connected to
> > > several families of Marvell PHYs via the PHY HW LED trigger API.
> > > These families are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510
> > > and 88E1545. More can be added.
> > > 
> > > This patch does not yet add support for compound LED modes. This
> > > could be achieved via the LED multicolor framework.
> > > 
> > > Settings such as HW blink rate or pulse stretch duration are not
> > > yet supported.
> > > 
> > > Signed-off-by: Marek Behún <marek.behun@xxxxxx>  
> > 
> > I suggest limiting to "useful" hardware modes, and documenting what
> > those modes do somewhere.  
> 
> I think to keep the YAML DT verification happy, they will need to be
> listed in the marvell PHY binding documentation.
> 
>        Andrew

Okay, so the netdev trigger offers modes `link`, `rx`, `tx`.
You can enable/disable either of these (via separate sysfs files). `rx`
and `tx` blink the LED, `link` turns the LED on if the interface is
linked.

The phy_led_trigger subsystem works differently. Instead of registering
one trigger (like netdev) it registers one trigger per PHY device and
per speed. So for a PHY with name XYZ and supported speeds 1Gbps,
100Mbps, 10Mbps it registers 3 triggers:
  XYZ:1Gbps XYZ:100Mbps XYZ:10Mbps

This is especially bad on a system where there are many PHYs and they
have long names derived from device tree path.

I propose that at least these HW modes should be available (and
documented) for ethernet PHY controlled LEDs:
  mode to determine link on:
    - `link`
  mode for activity (these should blink):
    - `activity` (both rx and tx), `rx`, `tx`
  mode for link (on) and activity (blink)
    - `link/activity`, maybe `link/rx` and `link/tx`
  mode for every supported speed:
    - `1Gbps`, `100Mbps`, `10Mbps`, ...
  mode for every supported cable type:
    - `copper`, `fiber`, ... (are there others?)
  mode that allows the user to determine link speed
    - `speed` (or maybe `linkspeed` ?)
    - on some Marvell PHYs the speed can be determined by how fast
      the LED is blinking (ie. 1Gbps blinks with default blinking
      frequency, 100Mbps with half blinking frequeny of 1Gbps, 10Mbps
      of half blinking frequency of 100Mbps)
    - on other Marvell PHYs this is instead:
      1Gpbs blinks 3 times, pause, 3 times, pause, ...
      100Mpbs blinks 2 times, pause, 2 times, pause, ...
      10Mpbs blinks 1 time, pause, 1 time, pause, ...
    - we don't need to differentiate these modes with different names,
      because the important thing is just that this mode allows the
      user to determine the speed from how the LED blinks
  mode to just force blinking
    - `blink`
The nice thing is that all this can be documented and done in software
as well.

Moreover I propose (and am willing to do) this:
  Rewrite phy_led_trigger so that it registers one trigger, `phydev`.
  The identifier of the PHY which should be source of the trigger can be
  set via a separate sysfs file, `device_name`, like in netdev trigger.
  The linked speed on which the trigger should light the LED will be
  selected via sysfs file `mode` (or do you propose another name?
  `trigger_on` or something?)

  Example:
    # cd /sys/class/leds/<LED>
    # echo phydev >trigger
    # echo XYZ >device_name
    # cat mode
    1Gbps 100Mbps 10Mbps
    # echo 1Gbps >mode
    # cat mode
    [1Gbps] 100Mbps 10Mbps

  Also the code should be moved from driver/net/phy to
  drivers/leds/trigger.

  The old API can be declared deprecated or removed, but outright
  removal may cause some people to complain.

What do you think?

Marek