[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD++jLmGMWjCD0gUcaJPuK0UzJa7nX1bdoVu-BA7aHAgcLTSpg@mail.gmail.com>
Date: Fri, 16 Jan 2026 14:59:56 +0100
From: Linus Walleij <linusw@...nel.org>
To: 李杰 <lj29312931@...il.com>
Cc: wsa@...nel.org, linux-i2c@...r.kernel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
Bartosz Golaszewski <brgl@...nel.org>, Linux pin control <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v1 0/2] i2c: add support for forced SDA recovery
Hi Jie,
On Thu, Jan 15, 2026 at 2:13 PM 李杰 <lj29312931@...il.com> wrote:
> Even if FLAG_OPEN_DRAIN is set, the function falls back to
> gc->get_direction() if the FLAG_IS_OUT bit hasn't been established
> yet. Crucially, some ASICs do not even implement a readable direction
> bit in hardware.
>
> In many true open-drain hardware implementations, a line driven "high"
> (high-impedance) is physically reported as an Input by the hardware
> register.
If this is the actual problem, then this is a Linux problem and not something
that should be solved by adding new flags to the OS-neutral device tree.
So we can immediately stop trying to add stuff to device tree for this.
What you would have to do is to augment the driver framework and
code in Linux to deal with open drain modes better.
> The function returns 1 because the line is currently high/floating or
> the hardware lacks direction reporting.
>
> The I2C core then assumes the pin is "Input-only" and skips the
> assignment of bri->set_sda.
>
> Bus recovery becomes impossible even though the hardware is fully
> capable of driving the line low.
So you need to think about what the framework needs to provide
for the I2C recovery code to realize this line is open drain and
can actually be driven high and low.
You can't just rely on gpiod_get_direction() to be the only thing
that will ever be provided just because it looks like that today.
For example: if <linux/gpio/consumer.h> would provide
gpiod_is_single_ended() (meaning it is open drain or open source)
I think you could use this instead of special "force" flags.
So implement something like that in the gpiolib code and
headers instead. This avoid hacks like random DT flags.
If the right open drain or open source flags are set on the line
in the device tree then the gpiolib knows this and then you know
you can also actively drive these lines and all you need is
a way to query it.
Yours,
Linus Walleij
Powered by blists - more mailing lists