> Thanks!
On Tue, Feb 17, 2015 at 5:11 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@xxxxxxxxx> wrote:
> Hello Bryan
>
> On Wed, Feb 18, 2015 at 1:52 AM, Bryan Wu <cooloney@xxxxxxxxx> wrote:
>>>
>>> Lets say that we have a type of add-on card. Described by this DT
>>> overlay (card.dtb):
>>>
>>
>> I think who write this card.dtb should understand this issue. And
>> choose the right name.
>
> card.dtb just describe the hardware in the card, and it is not be
> aware of the rest of the system.
>
> I dont think it is practical to have card_HOST0_PCI1.dtb,
> card_HOST0_PCI2.dtb to HOST0_PCI16.dtb and then HOST1_, HOST2....
>
>>> gpio_0: gpio_0 {
>>What happen if you just use name 'gpio: gpio {' here.? Any conflicts
>>or kernel oops?
>
> No problem here, one will create the device
>
> /sys/devices/pci0000:00/0000:00:05.0/0000:01:00.0/30040000.gpio
>
> and the other:
>
> /sys/devices/pci0000:00/0000:00:06.0/0000:01:00.0/40040000.gpio
>
> Name is created with hierarnchy
>
> /sys/class/gpio/ will also work fine, because the gpiochip id is
> created dynamically
>
> On the other hand all the leds are under,
>
> /sys/class/leds/NAME
>
> Do not have any dynamic naming or hierarchical name.
>
I got it. In this case we need to give the leds device a unique name.
Go back to your patch, you're adding 0, 1 at the end of the name of
leds. It's better like GPIO I think you can pick up <reg> value of
leds device node and put it in front of the name of leds. like
/sys/class/leds/30040000.red and /sys/class/leds/40040000.red.
Thanks,
-Bryan
--
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
