On Thu, 14 Oct 2021 13:30:39 +0200
Alexander Dahl [off-list ref] wrote:

Hei hei,

Am Thu, Oct 14, 2021 at 12:43:09PM +0200 schrieb Marek Behún:

quoted

On Thu, 14 Oct 2021 12:29:18 +0200
Pavel Machek [off-list ref] wrote:
  

quoted

Hi!
  

quoted

Some RJ-45 connectors have LEDs wired in the following way:

         LED1
      +--|>|--+
      |       |
  A---+--|<|--+---B
         LED2

With + on A and - on B, LED1 is ON and LED2 is OFF. Inverting
the polarity turns LED1 OFF and LED2 ON.

So these LEDs exclude each other.

Add new `excludes` property to the LED binding. The property is
a phandle-array to all the other LEDs that are excluded by this
LED.    

I don't think this belongs to the LED binding.

This is controller limitation, and the driver handling the
controller needs to know about it... so it does not need to learn
that from the LED binding.  

It's not necessarily a controller limitation, rather a limitation of
the board (or ethernet connector, in the case of LEDs on an ethernet
connector).  

Such LEDs are not limited to PHYs or ethernet connectors.  There is
hardware with such dual color LEDs connected to GPIO pins (either
directly to the SoC or through some GPIO expander like an 74hc595
shift register).  That mail points to such hardware:

https://www.spinics.net/lists/linux-leds/msg11847.html

I asked about how this can be modelled back in 2019 and it was also
discussed last year:

https://www.spinics.net/lists/linux-leds/msg11665.html
https://lore.kernel.org/linux-leds/2315048.uTtSMl1LR1@ada/ (local)

The "solution" back when I first asked was treating them as ordinary
GPIO-LEDs and ignore the "exclusion topic" which means in practice the
LED goes OFF if both pins are ON (high) at the same time, which works
well enough in practice.

quoted

But I guess we could instead document this property in the ethernet
PHY controller binding for a given PHY.  

Because such LEDs are not restricted to ethernet PHYs, but can also be
used with GPIOs from the hardware point of view, I would not put it
there.

Furthermore I would not view this as a restriction of the gpio-leds
controller, but it's a property of the LEDs itself or the way they are
wired to the board.

This could (or should as Pavel suggested back in 2019) be put to a new
driver, at least for the GPIO case, but it would need some kind of new
binding anyways.  With that in mind I consider the proposed binding to
be well comprehensible for a human reader/writer.

I'm sorry, I did not have leisure time to implement such a driver yet.
Breadboard hardware for that still waiting in the drawer. :-/

That's why I think we need the `excludes` property.

On the sw side, it should work like this:
$ cd /sys/class/leds
$ echo 1 >LED1/brightness
$ cat LED1/brightness LED2/brightness
1
0
$ echo 1 >LED2/brightness
$ cat LED1/brightness LED2/brightness
0
1

The drivers could also implement brightness_hw_changed for these LEDs.

Marek