On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl <oli...@schinagl.nl> wrote: > > On 14-01-15 13:45, Linus Walleij wrote: >> >> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov >> <dmitry.torok...@gmail.com> wrote: >>> >>> On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote: >>>> >>>> On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oli...@schinagl.nl> >>>> wrote: >>>>>>> >>>>>>> --- 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. >>> >>> I think only the driver itself can know about such "legacy" mappings and >>> make a decision. >> >> Yeah leds-gpio.c will need to be patched to check for "led-gpios" first >> and then fall back to "gpios" if not found. > > yeah I've done the work, just need to double check it and resend a v2. > > Linus, I assume you want the already applied patches omitted from v2?
Yes, please base new revisions on Linus' devel branch, omitting any patches that he has already accepted. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html