linux-kernel - Re: [PATCH] i2c: core: dont change pinmux state to GPIO during recovery setup

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]

Date:   Thu, 9 Nov 2023 20:30:02 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Robert Marko <robert.marko@...tura.hr>, wsa@...nel.org,
        codrin.ciubotariu@...rochip.com, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH] i2c: core: dont change pinmux state to GPIO during
 recovery setup

On Thu, Nov 09, 2023 at 09:04:29PM +0100, Linus Walleij wrote:
> Hi Robert!
> 
> Thanks for getting back on this issue.
> 
> On Thu, Nov 9, 2023 at 8:10 PM Robert Marko <robert.marko@...tura.hr> wrote:
> 
> > Yes, I2C recovery is required on this board as otherwise the I2C bus will
> > get stuck after a certain number of SFP module plug/unplug events or
> > sometimes even just randomly, I2C recovery allows the bus to recover
> > and continue working.
> 
> OK makes sense.
> 
> > Maybe my commit message was confusing, so I will try and explain further.
> > I2C recovery did work on Armada 3720 just fine until the driver was converted
> > to use the generic I2C recovery which is now part of the I2C core.
> >
> > After it was converted to it, the I2C bus completely stopped working
> > on Armada 3720
> > if I2C recovery is enabled by making the recovery pinctrl available in DTS.
> 
> Shouldn't we just revert that patch until we can figure this out then?

Note that when I wrote the i2c-pxa recovery code (which was developed
and tested on Armada 3720 - the uDPU) it had to work... when the
suggestion came up to implement generic recovery, I stated:

http://archive.lwn.net:8080/linux-kernel/20200705210942.GA1055@...ai/T/#mf7f862fcd53245f14fb650d33c29cf139d41039d

> > I then spent quite a while trying to bisect the exact change that
> > causes this issue
> > in the conversion as code is almost identical to what the driver was
> > doing previously,
> > and have bisected it down to pinctrl_select_state(bri->pinctrl,
> > bri->pins_gpio) being
> > called before SDA and SCL pins are obtained via devm_gpiod_get().

Yes, indeed. That's because the pinctrl internals get confused. I sent
you an email about it on 6th December 2019

"pinctrl states vs pinmux vs gpio (i2c bus recovery)"

which is why i2c-pxa did things the way it did in my commit
"i2c: pxa: implement generic i2c bus recovery".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!