From: <Ryan.Wanner@microchip.com>
To: <linus.walleij@linaro.org>
Cc: <linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-gpio@vger.kernel.org>, <alexandre.belloni@bootlin.com>,
<Ludovic.Desroches@microchip.com>, <Nicolas.Ferre@microchip.com>,
<Claudiu.Beznea@microchip.com>
Subject: Re: I2c GPIO Recovery with pinctrl strict mode
Date: Fri, 17 Feb 2023 17:36:47 +0000 [thread overview]
Message-ID: <46dd4d9a-7dc8-48f9-69d4-d18ca6433acc@microchip.com> (raw)
In-Reply-To: <CACRpkdaKYN9eRtuOhBBp_50sR71AQvNSKtjAR1RZPhaKYhfJVw@mail.gmail.com>
On 2/13/23 02:29, Linus Walleij wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Fri, Feb 10, 2023 at 4:21 PM <Ryan.Wanner@microchip.com> wrote:
>
>> I am trying to enable .strict in the Atmel pinctrl driver, and that is
>> what is causing my issues.
>
> Strictly speaking (ha!) that flag is for when you *cannot* use a pin
> in GPIO mode at the same time as another mode.
>
> Example: if you use the pin in I2C mode, then reading the GPIO
> input register will *not* reflect the value on the electrical line,
> because it has been decoupled physically. Then .strict should
> be true.
>
> The strict mode was not intended for policy, i.e. stopping kernel
> developers from doing wrong things. They have enough tools to
> do wrong things anyway, one more or less doesn't matter.
I understand, so .strict keeps the pins mapped to one ownership,
so if I2C has those pins GPIO could not have access to them.
When it comes to I2c recovery, looking at the I2C generic recovery,
the pins are both being used by the I2C and the GPIO at the same time.
This cannot happen with strict mode. So since I am enabling strict mode
for pinctrl-atmel-pio4.c I2C recovery cannot work?
Thanks,
Ryan
>
> Yours,
> Linus Walleij
next prev parent reply other threads:[~2023-02-17 17:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 17:56 I2c GPIO Recovery with pinctrl strict mode Ryan.Wanner
2023-02-09 10:32 ` Linus Walleij
2023-02-09 13:24 ` Michael Walle
2023-02-10 15:21 ` Ryan.Wanner
2023-02-13 9:29 ` Linus Walleij
2023-02-17 17:36 ` Ryan.Wanner [this message]
2023-02-18 23:29 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46dd4d9a-7dc8-48f9-69d4-d18ca6433acc@microchip.com \
--to=ryan.wanner@microchip.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox