linux-kernel - Re: DT parsing : duplicate name error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACxGe6s-dKRtwjBhVE2d1L-qOYX_71hQOT9svu4m_+kDZESPaw@mail.gmail.com>
Date:	Wed, 3 Dec 2014 16:07:58 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Fabio Estevam <festevam@...il.com>
Cc:	Jean-Michel Hautbois <jean-michel.hautbois@...alys.com>,
	linux-next <linux-next@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Fabio Estevam <fabio.estevam@...escale.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Bryan Wu <cooloney@...il.com>
Subject: Re: DT parsing : duplicate name error

On Wed, Dec 3, 2014 at 4:04 PM, Fabio Estevam <festevam@...il.com> wrote:
> On Wed, Dec 3, 2014 at 1:41 PM, Grant Likely <grant.likely@...retlab.ca> 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.

Rafael, Thoughts?

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/