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 22:02:14 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
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 9, 2023 at 9:30 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
> On Thu, Nov 09, 2023 at 09:04:29PM +0100, Linus Walleij wrote:

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

Makes me even more convinced that we should just revert this. i.e.
commit 0b01392c18b9993a584f36ace1d61118772ad0ca
i2c: pxa: move to generic GPIO recovery

There is even:
https://lore.kernel.org/linux-i2c/20201209204645.GF3499@kunai/

"In case we missed a glitch, we can still revert the patch later."
Well this is later.

Robert can you see if it possible to revert, that things work after a
revert and send a revert patch?

> > > 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)"

I found it:
https://lore.kernel.org/all/20191206173343.GX25745@shell.armlinux.org.uk/

Sadly I had no good advice for any simple elegant solutions
to the problem, but the more complicated solution does
work so let's go for that.

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

I think we need to go back to this.

It's nice with the ambition to create generic code of course, but
sometimes it is better to just roll something IP-unique.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ