linux-kernel - Re: [PATCH v2 9/9] i2c: riic: Implement bus recovery

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: <Z_9fh2nfwAaUnhVV@shikoro>
Date: Wed, 16 Apr 2025 09:43:03 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc: Chris Brandt <chris.brandt@...esas.com>,
	Andi Shyti <andi.shyti@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Wolfram Sang <wsa@...nel.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2 9/9] i2c: riic: Implement bus recovery

Hi Prabhakar,

finally some time for this!

> Based on the feedback from the HW engineer the restriction is valid
> see attached image (i2c-pullup.png). The SCL and SDA are Schmitt
> input/open-drain output pins for both master and slave operations.
> Because the output is open drain, an external pull-up resistor is
> required.

That confirms what I was saying. It is required. There is no difference
between setting the bit manually and the IP core doing it internally.

> Assuming there is an external pull-up resistor for all the platforms I
> implemented the I2C bus recovery using the generic recovery algorithm
> and I'm seeing issues, as the required number of clock pulses are not
> being triggered (Note, the i2c clock frequency is 400000Hz where the
> below tests are run).

So, my take is to check further why this is the case. The code looks
mostly good, except for bus_free:

> +static int riic_get_bus_free(struct i2c_adapter *adap)
> +{
> +       struct riic_dev *riic = i2c_get_adapdata(adap);
> +
> +       udelay(5);

I wonder about the udelay here. Both, why this is necessary and where
the value comes from.

> +
> +       /* Check if the bus is busy or SDA is not high */
> +       if ((riic_readb(riic, RIIC_ICCR2) & ICCR2_BBSY) ||
> +           !(riic_readb(riic, RIIC_ICCR1) & ICCR1_SDAI))

And maybe if we can't skip reading SDAI here?

> +               return -EBUSY;
> +
> +       return 1;
> +}

Have you already played with these options? If you didn't and don't have
time to do so, I can also check it. I luckily got a G3S meanwhile.

Happy hacking,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)