Linux GPIO subsystem development
 help / color / mirror / Atom feed
From: Linus Walleij <linusw@kernel.org>
To: Jie Li <lj29312931@gmail.com>
Cc: wsa@kernel.org, linux-i2c@vger.kernel.org, robh@kernel.org,
	 krzk+dt@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org,  linus.walleij@linaro.org,
	linux-kernel@vger.kernel.org,
	 Bartosz Golaszewski <brgl@kernel.org>,
	Linux pin control <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v1 0/2] i2c: add support for forced SDA recovery
Date: Thu, 15 Jan 2026 10:27:21 +0100	[thread overview]
Message-ID: <CAD++jLkyTMXAE_M2JFF5jzzLZ2Z-CV89uEGh4xHopWrGoYncbA@mail.gmail.com> (raw)
In-Reply-To: <20260114141352.103425-1-jie.i.li@nokia.com>

Hi Jie,

thanks for your patch!

On Wed, Jan 14, 2026 at 3:13 PM Jie Li <lj29312931@gmail.com> wrote:

> This series addresses a limitation in the I2C bus recovery mechanism when
> dealing with certain open-drain GPIO configurations where the direction
> cannot be automatically detected.

I'm sorry but I don't understand the premise. How can we even get here?

So the mechanism is about I2C that is using a regular I2C block, and
the pins get re-muxed to GPIO to drive recovery using the I2C
core GPIO-mode recovery mechanism with bridge->sda_gpiod
which is retrieved in the core from "sda" which in DT is
sda-gpios = <....>; (calong with similarly named SCL) for
GPIO-mode recovery.

So if that is set in an input mode, such as during devm_gpiod_get()
reading the initial direction of the line,
so gpiod_get_direction(bri->sda_gpiod) == 1.
this patch set will go and write output values to the line
*anyway* because "it works".

This is how I understand the patch set.

In which scenario do you have a device tree where you can add
"force-set-sda" to a DT node, but you *can't* just fix up the
SCL/SDA flags like this:

#include <dt-bindings/gpio/gpio.h>

sda-gpios = <&gpio0 5 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
scl-gpios = <&gpio0 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;

?

We should possibly also enforce it from the I2C recovery core,
for SDA we are currently doing:

gpiod = devm_gpiod_get(dev, "sda", GPIOD_IN);

what happens if you patch i2c-core-base.c to simply do:

gpiod = devm_gpiod_get(dev, "sda", GPIOD_OUT_HIGH_OPEN_DRAIN);

(Based on SDA resting polarity being high.)
I'm more uncertain about that one because I don't know exactly
how hardware behaves in response to this, but can you test this
first if you have to hack around in the core?

Yours,
Linus Walleij

       reply	other threads:[~2026-01-15  9:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260114141352.103425-1-jie.i.li@nokia.com>
2026-01-15  9:27 ` Linus Walleij [this message]
2026-01-15 13:12   ` [PATCH v1 0/2] i2c: add support for forced SDA recovery 李杰
2026-01-16 13:59     ` Linus Walleij
2026-01-25 19:51       ` [PATCH v2 0/2] i2c: improve bus recovery for single-ended GPIOs Jie Li
2026-01-25 19:51         ` [PATCH v2 1/2] gpiolib: add gpiod_is_single_ended() helper Jie Li
2026-01-27  9:46           ` Linus Walleij
2026-01-25 19:51         ` [PATCH v2 2/2] i2c: core: support recovery for single-ended GPIOs Jie Li
2026-01-27  9:47           ` Linus Walleij
2026-02-01 11:18             ` [PATCH v3 0/2] i2c: improve bus " Jie Li
2026-02-01 11:18               ` [PATCH v3 1/2] gpiolib: add gpiod_is_single_ended() helper Jie Li
2026-02-01 11:18               ` [PATCH v3 2/2] i2c: core: support recovery for single-ended GPIOs Jie Li
2026-05-04 12:14                 ` Wolfram Sang
2026-05-09  9:12                   ` [PATCH v4 0/2] i2c: improve bus " Jie Li
2026-05-09  9:12                     ` [PATCH v4 1/2] gpiolib: add gpiod_is_single_ended() helper Jie Li
2026-05-09  9:12                     ` [PATCH v4 2/2] i2c: core: support recovery for single-ended GPIOs Jie Li
2026-05-09 10:10                       ` Wolfram Sang
2026-05-11  7:25                         ` 李杰
2026-04-22 18:47               ` [PATCH v3 0/2] i2c: improve bus " 李杰

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=CAD++jLkyTMXAE_M2JFF5jzzLZ2Z-CV89uEGh4xHopWrGoYncbA@mail.gmail.com \
    --to=linusw@kernel.org \
    --cc=brgl@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lj29312931@gmail.com \
    --cc=robh@kernel.org \
    --cc=wsa@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