linux-kernel - Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1478f2c1989ab735b0f86d2fe579f94f@agner.ch>
Date:   Thu, 29 Sep 2016 09:33:53 -0700
From:   Stefan Agner <stefan@...er.ch>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
        linus.walleij@...aro.org, shawnguo@...nel.org,
        aalonso@...escale.com, b38343@...escale.com, ldewangan@...dia.com,
        van.freenix@...il.com, p.zabel@...gutronix.de,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when
 freeing GPIO

On 2016-09-27 21:14, Viresh Kumar wrote:
> On 27-09-16, 20:38, Stefan Agner wrote:
>> The i.MX I2C driver touches the pinctrl in its prepare/unprepare
>> callbacks.
>>
>> So, on a i.MX or Vybrid, the call chain looks like this:
>>
>> i2c_generic_gpio_recovery
>>     -> i2c_get_gpios_for_recovery
>>        -> gpio_request_one
>>     -> i2c_generic_recovery
>>        -> prepare_recovery (i2c_imx_prepare_recovery)
>>           -> pinctrl_select_state [gpio]
> 
> Why is this done here? And not in gpio_request_one?
> 

You need to differentiate between Vybrid and i.MX:

Vybrid muxes a pin to GPIO on gpio_request_one (via .gpio_request_enable
callback)
i.MX does not mux a pin as GPIO on its own, but needs to be muxed
explicitly. That has been always the case...

I don't know what behavior is right, it is just "different"...

In Vybrid I did it that way because I knew that was the behavior of
another SoC I worked on (namely a Tegra)... And I had to touch the
pinctrl register anyway (using gpio_set_direction, to set the
direction).

I guess in the end it boils down to one question: Is the GPIO and
pinctrl API ment to be orthogonal? If so, then we probably should select
the GPIO via pinctrl in the i.MX I2C driver but mux the pin in
gpio_request_one similar as we do it on Vybrid... But that would be
rather invasive change...

@Shawn, Linus Walleij, others, what is your take on that?

>>        -> unprepare_recovery (i2c_imx_unprepare_recovery)
>>           -> pinctrl_select_state [default]
>>     -> i2c_put_gpios_for_recovery
>>        -> gpio_free

Currently free does not restore the last pinmux, so if the API's are
meant to be completely orthogonal we need to store the pinmux in
gpio_request_one so we can restore it in gpio_free.

--
Stefan