On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@xxxxxxxxxxx> wrote: > Hey Dmitry, > > > On 08-01-15 00:55, Dmitry Torokhov wrote: >> >> On Wed, Jan 07, 2015 at 10:08:42AM +0100, Olliver Schinagl wrote: >>> >>> From: Olliver Schinagl <oliver@xxxxxxxxxxx> >>> >>> The gpio document says we should not use unnamed bindings for gpios. >>> This patch uses the 'led-' prefix to the gpios and updates code and >>> documents. Because the devm_get_gpiod_from_child() falls back to using >>> old-style unnamed gpios, we can update the code first, and update >>> dts files as time allows. [...] >>> --- a/drivers/leds/leds-gpio.c >>> +++ b/drivers/leds/leds-gpio.c >>> @@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct >>> platform_device *pdev) >>> struct gpio_led led = {}; >>> const char *state = NULL; >>> - led.gpiod = devm_get_gpiod_from_child(dev, NULL, child); >>> + led.gpiod = devm_get_gpiod_from_child(dev, "led", child); >> >> Would not this break existing boards using old bindings? You need to >> handle both cases: if you can't located "led-gpios" then you will have to >> try just "gpios". > > Very true. I was rather even hoping we could update all bindings, I don't > mind going through the available dts files to fix them ... But need to know > that that's the proper way to go before doing the work ;) That will not work. You cannot make changes that require a new dtb with a new kernel. This would also break for the other way around (i.e. a new dtb and old kernel). You would have to search for both led-gpios and gpios. I'm not sure if we can do that generically for all GPIOs. If you had a node with both "blah-gpios" and "gpios", it would break. I would hope there are no such cases like that. We also now have to consider how ACPI identifies GPIOs and whether this makes sense. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html