[lkml]   [2015]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] led/led-class: Handle LEDs with the same name
Hello Bryan

On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu <> wrote:
> DT just describe the hardware, so if it's a different hardware, they
> should have different name.
> red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and 1.

I think I have not managed to explain myself properly.

We have a host computer. with 2 pcie slots. The host is described with
a DT that looks like:

&axi1 {

reg = < 0x20000000 0x10000000 >

reg = < 0x30000000 0x10000000 >

The user can connect anything to the pci slots. (pci0 and pci1)

Lets say that we have a type of add-on card. Described by this DT
overlay (card.dtb):

&pci {

gpio_0: gpio_0 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x30040000 010000 >;

leds {
reg = < 0x30040000 010000 >;
compatible = "gpio-leds";
red {
gpios = <&gpio_0 0 0>;
linux,default-trigger = "drop-qt5023_video0";


The user connects two of those cards to the system (at locations pci0 and pci1).

Then we have TWO gpios chip. Each of them have a led named red. When
the second gpio-led is probed we have an error. Everything else
(address offset, phandle, device renaming) is handled properly already
by the kernel.

On this system I cannot control card.dtb, or which type of cards will
the user connect to the system. The DT is generated in run-time based
on the hardware connected to the pci slots.

I humbly believe that the issue here is that the subsystem does not
protect ourselves against name collisions, because a month ago a
device tree was considered immutable and in full control of the system
designer, unfortunately this is not the case anymore.


Ricardo Ribalda

 \ /
  Last update: 2015-02-18 01:41    [W:0.090 / U:11.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site