[PATCH v2] gpio: davinci: fix gpio selection for OF
nsekhar at ti.com
Mon Mar 17 09:29:41 EDT 2014
On Friday 14 March 2014 04:32 PM, Linus Walleij wrote:
> On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler <holler at ahsoftware.de> wrote:
>> Am 11.03.2014 11:15, schrieb Linus Walleij:
>>> On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler <holler at ahsoftware.de> wrote:
>>>> The driver missed an of_xlate function to translate gpio numbers
>>>> as found in the DT to the correct chip and number.
>>>> While there I've set #gpio_cells to a fixed value of 2.
>>>> I've used gpio-pxa.c as template for those changes and tested my changes
>>>> successfully on a da850 board using entries for gpio-leds in a DT. So I didn't
>>>> reinvent the wheel but just copied and tested stuff.
>>>> Thanks to Grygorii Strashko for the hint to the existing code in gpio-pxa.
>>>> Signed-off-by: Alexander Holler <holler at ahsoftware.de>
>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
>>> This v2 version applied, thanks!
>> Thanks, but actually that should have been a fix for 3.14 with which the
>> OF functionality for davinci gpio gets introduced. I assum with the
>> patch in for-next, 3.14 will appear with that functionality broken and
>> it will become a candidate for -stable.
> I just get the impression that DT support for DaVinci in v3.14 is so risky
> and unstable that noone except those implementing it (i.e. you) is really
> using it, is that correct?
> In that case it is hardly a fix that we need to rush out to the entire world.
One thing to note is that this driver is used by keystone too and all
its users are DT-only. Although I do not see any in-kernel DT GPIO users
I can confirm the patch does not break my gpiolib based test module
(test with and without DT), but then it did not have an issue even before.
More information about the linux-arm-kernel