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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ