Re: [PATCH] led/led-class: Handle LEDs with the same name

[Ricardo Ribalda Delgado]

Hello Bryan

On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu <cooloney@xxxxxxxxx> 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 {

pci0{
  reg = < 0x20000000 0x10000000 >
}

pci1{
  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*/
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.

Thanks!

-- 
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/