From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olliver Schinagl Subject: Re: [PATCH v1 4/4] leds: no longer use unnamed gpios Date: Wed, 14 Jan 2015 14:20:07 +0100 Message-ID: <54B66D07.8040807@schinagl.nl> References: <1420621722-7428-1-git-send-email-oliver+list@schinagl.nl> <1420621722-7428-5-git-send-email-oliver+list@schinagl.nl> <20150107235522.GA6670@dtor-ws> <54AE43A9.3020309@schinagl.nl> <20150108221249.GH23256@dtor-ws> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from 7of9.schinagl.nl ([88.159.158.68]:60929 "EHLO 7of9.schinagl.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752228AbbANNUO (ORCPT ); Wed, 14 Jan 2015 08:20:14 -0500 In-Reply-To: Sender: linux-gpio-owner@vger.kernel.org List-Id: linux-gpio@vger.kernel.org To: Linus Walleij , Dmitry Torokhov Cc: Rob Herring , Olliver Schinagl , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Alexandre Courbot , Bryan Wu , Richard Purdie , Robin Gong , "Rafael J. Wysocki" , Aaron Lu , Mika Westerberg , Grant Likely , Wolfram Sang , Alexander Shiyan , Jingoo Han , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , linux-inpu On 14-01-15 13:45, Linus Walleij wrote: > On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov > 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 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? Olliver > > Yours, > Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752952AbbANNUR (ORCPT ); Wed, 14 Jan 2015 08:20:17 -0500 Received: from 7of9.schinagl.nl ([88.159.158.68]:60929 "EHLO 7of9.schinagl.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752228AbbANNUO (ORCPT ); Wed, 14 Jan 2015 08:20:14 -0500 Message-ID: <54B66D07.8040807@schinagl.nl> Date: Wed, 14 Jan 2015 14:20:07 +0100 From: Olliver Schinagl User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Linus Walleij , Dmitry Torokhov CC: Rob Herring , Olliver Schinagl , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Alexandre Courbot , Bryan Wu , Richard Purdie , Robin Gong , "Rafael J. Wysocki" , Aaron Lu , Mika Westerberg , Grant Likely , Wolfram Sang , Alexander Shiyan , Jingoo Han , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-input@vger.kernel.org" , "linux-leds@vger.kernel.org" Subject: Re: [PATCH v1 4/4] leds: no longer use unnamed gpios References: <1420621722-7428-1-git-send-email-oliver+list@schinagl.nl> <1420621722-7428-5-git-send-email-oliver+list@schinagl.nl> <20150107235522.GA6670@dtor-ws> <54AE43A9.3020309@schinagl.nl> <20150108221249.GH23256@dtor-ws> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14-01-15 13:45, Linus Walleij wrote: > On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov > 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 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? Olliver > > Yours, > Linus Walleij