On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhovyeah I've done the work, just need to double check it and resend a v2.
<dmitry.torokhov@xxxxxxxxx> wrote:
On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote:Yeah leds-gpio.c will need to be patched to check for "led-gpios" first
On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl <oliver@xxxxxxxxxxx> wrote:I think only the driver itself can know about such "legacy" mappings and
That will not work. You cannot make changes that require a new dtbVery true. I was rather even hoping we could update all bindings, I don't--- a/drivers/leds/leds-gpio.cWould not this break existing boards using old bindings? You need to
+++ 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);
handle both cases: if you can't located "led-gpios" then you will have to
try just "gpios".
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 ;)
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.
make a decision.
and then fall back to "gpios" if not found.
Yours,
Linus Walleij