Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753690AbaLCQQl (ORCPT ); Wed, 3 Dec 2014 11:16:41 -0500 Received: from mail-ig0-f176.google.com ([209.85.213.176]:34073 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752838AbaLCQIU (ORCPT ); Wed, 3 Dec 2014 11:08:20 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Grant Likely Date: Wed, 3 Dec 2014 16:07:58 +0000 X-Google-Sender-Auth: bi6KXL9lgdBDnCz5eaLL-TG0bVo Message-ID: Subject: Re: DT parsing : duplicate name error To: Fabio Estevam Cc: Jean-Michel Hautbois , linux-next , linux-kernel , Fabio Estevam , "Rafael J. Wysocki" , Mika Westerberg , Bryan Wu Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 3, 2014 at 4:04 PM, Fabio Estevam wrote: > On Wed, Dec 3, 2014 at 1:41 PM, Grant Likely 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/