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-leds" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
