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]
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/

Powered by blists - more mailing lists