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] [day] [month] [year] [list]

Message-ID: <20141203171057.GD28857@lahna.fi.intel.com>
Date:	Wed, 3 Dec 2014 19:10:57 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Fabio Estevam <festevam@...il.com>,
	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>,
	Bryan Wu <cooloney@...il.com>
Subject: Re: DT parsing : duplicate name error

On Wed, Dec 03, 2014 at 04:07:58PM +0000, Grant Likely wrote:
> 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.

Does it need to be taken from the node name? What if we generate the
name based on the leds device name?

Something like "leds-gpio:0" and "leds-gpio:1" or so.
--
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/