linux-kernel - Re: [PATCH] drm/bridge: ti-sn65dsi86: fix REFCLK setting

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=WfV1Kr5hFSqf=t0OS3qFSGfQ3_+LQ-57nMKHXRSYvZ-w@mail.gmail.com>
Date: Mon, 9 Jun 2025 15:29:28 -0700
From: Doug Anderson <dianders@...omium.org>
To: Michael Walle <mwalle@...nel.org>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	Jayesh Choudhary <j-choudhary@...com>
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi86: fix REFCLK setting

Hi,

On Wed, May 28, 2025 at 6:21 AM Michael Walle <mwalle@...nel.org> wrote:
>
> The bridge has three bootstrap pins which are sampled to determine the
> frequency of the external reference clock. The driver will also
> (over)write that setting. But it seems this is racy after the bridge is
> enabled. It was observed that although the driver write the correct
> value (by sniffing on the I2C bus), the register has the wrong value.
> The datasheet states that the GPIO lines have to be stable for at least
> 5us after asserting the EN signal. Thus, there seems to be some logic
> which samples the GPIO lines and this logic appears to overwrite the
> register value which was set by the driver. Waiting 20us after
> asserting the EN line resolves this issue.

+Jayesh might have some insight?



> Signed-off-by: Michael Walle <mwalle@...nel.org>
> ---
> I couldn't find a good commit for a Fixes: tag and I'm not sure how
> fixes are handled in drm.
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 60224f476e1d..fcef43154558 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -386,6 +386,17 @@ static int __maybe_unused ti_sn65dsi86_resume(struct device *dev)
>
>         gpiod_set_value_cansleep(pdata->enable_gpio, 1);
>
> +       /*
> +        * After EN is deasserted and an external clock is detected, the bridge
> +        * will sample GPIO3:1 to determine its frequency. The driver will
> +        * overwrite this setting. But this is racy. Thus we have to wait a
> +        * couple of us. According to the datasheet the GPIO lines has to be
> +        * stable at least 5 us (td5) but it seems that is not enough and the
> +        * refclk frequency value is lost/overwritten by the bridge itself.
> +        * Waiting for 20us seems to work.
> +        */
> +       usleep_range(20, 30);

It might be worth pointing at _where_ the driver overwrites this
setting, or maybe at least pointing to something that makes it easy to
find which exact bits you're talking about.

This looks reasonable to me, though.

Reviewed-by: Douglas Anderson <dianders@...omium.org>