Re: DT parsing : duplicate name error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2014-12-03 17:07 GMT+01:00 Grant Likely <grant.likely@xxxxxxxxxxxx>:
> On Wed, Dec 3, 2014 at 4:04 PM, Fabio Estevam <festevam@xxxxxxxxx> wrote:
>> On Wed, Dec 3, 2014 at 1:41 PM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
>>
>>> From a quick reading of the backlog, for some reason the new device is
>>> getting assigned NULL as the device name in led_classdev_register().
>>> Probably because led_cdev->name is set to NULL. The leds are getting
>>> bound to the LED driver in gpio_led_probe() which is the non-DT path
>>> for creating LED devices. That would mean there is pdata attached to
>>> the LED device, but I haven't dug any farther than that. Really need
>>> the bisect to narrow down what is going on.
>>
>> Ok, so this issue happens when two or more gpio-leds do not contain
>> the 'label' property.
>>
>> 'label' is an optional property according to
>> Documentation/devicetree/bindings/leds/common.txt:
>>
>> "Optional properties for child nodes:
>> - label : The label for this LED.  If omitted, the label is
>>   taken from the node name (excluding the unit address)."
>>
>> This works fine on 3.17.1 as we used to have this logic in leds-gpio:
>> led.name = of_get_property(child, "label", NULL) ? : child->name;
>>
>> ,but since commit a43f2cbbb009f96 ("leds: leds-gpio: Make use of
>> device property API "), this is no longer true:
>>
>>  + fwnode_property_read_string(child, "label", &led.name);
>>
>> If 'label' is not present then both of the LEDs will have the same
>> name and then the duplicate name error will happen.
>>
>> So we would need something like this:
>>
>>  if (fwnode_property_present(child, "label"))
>>        fwnode_property_read_string(child, "label", &led.name);
>>  else
>>      get the name from the child ---> This is what I am not sure how
>> to do after the conversion to use fwnode_handle.
>
> Ah, that makes sense. The device properties change needs to be
> reworked/fixed up to have a DT specific part when the label property
> is missing. Either that or the device properties API needs to gain the
> ability to return the node name.

Nice catch Fabio :).
I like the idea of returning of node name when label is not specified in DT.

> Rafael, Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux