linux-kernel - Re: pca953x issue when driving a DSI bridge

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, 11 May 2023 10:49:53 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
Cc:     linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        brgl@...ev.pl, linus.walleij@...aro.org
Subject: Re: pca953x issue when driving a DSI bridge

On Wed, May 10, 2023 at 11:18 PM Jean-Michel Hautbois
<jeanmichel.hautbois@...eli.org> wrote:
> On 10/05/2023 19:25, andy.shevchenko@...il.com wrote:
> > Wed, May 10, 2023 at 06:12:19PM +0200, Jean-Michel Hautbois kirjoitti:

...

> >> [   11.273968]  gpiod_set_value+0x5c/0xcc
> >> [   11.277722]  ti_sn65dsi86_resume+0x4c/0x94 [ti_sn65dsi86]
> >
> > Your problem even worse, i.e. ->resume() might sleep.
>
> Indeed it is worse ;-).
>
> >> [   11.283131]  __rpm_callback+0x48/0x19c
> >> [   11.286885]  rpm_callback+0x6c/0x80
> >> [   11.290375]  rpm_resume+0x3b0/0x660
> >> [   11.293864]  __pm_runtime_resume+0x4c/0x90
> >> [   11.297960]  __device_attach+0x90/0x1e4
> >> [   11.301797]  device_initial_probe+0x14/0x20
> >> [   11.305980]  bus_probe_device+0x9c/0xa4
> >> [   11.309817]  device_add+0x3d8/0x820
> >> [   11.313308]  __auxiliary_device_add+0x40/0xa0
> >> [   11.317668]  ti_sn65dsi86_add_aux_device.isra.0+0xb0/0xe0 [ti_sn65dsi86]
> >> [   11.324381]  ti_sn65dsi86_probe+0x20c/0x2ec [ti_sn65dsi86]
> >> [   11.329876]  i2c_device_probe+0x3b8/0x3f0
> >> [   11.333889]  really_probe+0xc0/0x3dc

...

> >> I suppose this is not a corner case and we may have other drivers and other
> >> boards connecting a GPIO which can sleep in a context where it should not ?
> >>
> >> I would like to add one thing: on this board, the expander is routed in a
> >> way that makes it impossible to "sleep" as the reset is forced pulled-up and
> >> the power regulators are fixed and can't be stopped.
> >
> > Can you elaborate why you think there is a problem?
>
> I didn't know if it could be an issue or not, so I mentioned it but
> sounds like a nonsense :-).

Maybe not. I don't know that hardware, schematics and more information
is needed to understand. But I leave it to you.

> >> I don't know how to address this issue nicely and any thoughts is
> >> appreciated !
> >
> > As a workaround you can consider the code around i2c_in_atomic_xfer_mode()
> > but since I have heard about i.MX8 so many negative remarks which makes me
> > think that hardware is a train wreck and shouldn't be used at all.

> Not sure to get the workaround proposal right...

There are possibilities to have atomic I2C transfers, but as comment
says (on top of the above mentioned function) that is only for PMIC
communications at the system shutdown.

In your case I would try the easiest way (taking into account that
hardware connection is not preventing us from sleeping context), i.e.
check if the function that has GPIO call may sleep on its own and
simply replace gpiod_set_value() by gpiod_set_value_cansleep().

> I won't argue about i.MX8 ;-).


-- 
With Best Regards,
Andy Shevchenko