[U-Boot] [PATCH] dm: gpio: handle GPIO_ACTIVE_LOW flag in DT

From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] dm: gpio: handle GPIO_ACTIVE_LOW flag in DT
Date: Wed, 20 Apr 2016 08:40:17 -0600	[thread overview]
Message-ID: <CAPnjgZ2jZ7opVw_5Hy2D2h=r4apJ-6jhJWWZKToNb3f0fiMfqQ@mail.gmail.com> (raw)
In-Reply-To: <570BDC0D.8020102@nelint.com>

Hi Eric,

On 11 April 2016 at 11:17, Eric Nelson <eric@nelint.com> wrote:
> On 04/11/2016 09:53 AM, Simon Glass wrote:
>> Hi,
>>
>> On 11 April 2016 at 10:10, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> On 04/11/2016 09:12 AM, Simon Glass wrote:
>>>>
>>>> Hi Eric,
>>>>
>>>> On 11 April 2016 at 09:10, Eric Nelson <eric@nelint.com> wrote:
>>>>>
>
> <snip>
>
>>>>>> I don't think you need __maybe_unused
>>>>>>
>>>>>> static int gpio_find_and_xlate(...)
>>>>>> {
>>>>>>     get ops...
>>>>>>
>>>>>>     if (ops->xlate)
>>>>>>        return ops->xlate(....)
>>>>>>     else
>>>>>>        return gpio_default_xlate()...
>>>>>> }
>>>>>>
>>>>>> gpio_default_xlate() (or whatever name you use) should be exported so
>>>>>> drivers can use it.
>>>>>>
>>>>>
>>>>> This will leak gpio_default_xlate (locally named gpio_xlate_offs_flags)
>>>>> into machines that don't need it.
>>>>>
>>>>> I can go the route you suggest above, but it will cost the tegra
>>>>> and sandbox builds ~64 bytes ;)
>>>>>
>>>>
>>>> Sure, but we can live with that.
>>>
>>>
>>> You can avoid that by requiring that ops->xlate always be non-NULL, and
>>> simply referencing the default function from drivers that want to use it.
>>> Not a big deal either way though.
>>
>> I'd prefer not to do that. It just adds cruft, the removal of which is
>> the purpose of Eric's series.
>>
>
> We must be close to the goal now, since we're picking apart stuff like
> this!
>
> Since I've done it both ways locally, I'll try to recap.
>
> Requiring an xlate puts a greater demand on the drivers, and requires
> an extra patch to get Vybrid working (adding xlate to vybrid_gpio.c)
> but does make it clearer which drivers need updates to handle DT
> parsing.
>
> There are a lot of them:
>         altera_pio
>         at91_gpio
>         atmel_pio4
>         axp_gpio
>         bcm2835_gpio
>         dwapb_gpio
>         gpio-uniphier
>         hi6220_gpio
>         intel_ich6_gpio
>         lpc32xx_gpio
>         msm_gpio
>         mvebu_gpio
>         pm8916_gpio
>
> None of these have dts files in either U-Boot or the kernel, so this
> doesn't appear to be a problem.
>
> Calling gpio_xlate_offs_flags as done in the V2 I just sent adds 64
> bytes of code to the output for all machines, but transparently adds
> support for machines like vybrid and mxc.

Yes that seems OK to me. Can you please send a new version of the series?

Regards,
Simon