Re: DT parsing : duplicate name error

[Fabio Estevam]

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.

Any ideas?

On linux-next I am only able to get two LEDs without 'label' property
to work if I do the following:

git checkout a43f2cbbb009f96
git revert a43f2cbbb009f96
git revert 5c51277a9ab
--
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/