linux-kernel - Re: [PATCH] drm/bridge: ti-sn65dsi83: Fix delay after reset deassert to match spec

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: <7761d66c-a8a7-c11a-9c09-a47f57bd1311@kontron.de>
Date:   Thu, 24 Nov 2022 12:07:33 +0100
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Alexander Stein <alexander.stein@...tq-group.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...il.com>,
        dri-devel@...ts.freedesktop.org,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org, Marek Vasut <marex@...x.de>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Robert Foss <robert.foss@...aro.org>,
        Frieder Schrempf <frieder@...s.de>
Cc:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Jonas Karlman <jonas@...boo.se>,
        José Expósito <jose.exposito89@...il.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi83: Fix delay after reset deassert
 to match spec

On 24.11.22 12:00, Alexander Stein wrote:
> Am Dienstag, 22. November 2022, 09:12:18 CET schrieb Frieder Schrempf:
>> From: Frieder Schrempf <frieder.schrempf@...tron.de>
>>
>> The datasheet specifies a delay of 10 milliseconds, but the current
>> driver only waits for 1 ms. Fix this to make sure the initialization
>> sequence meets the spec.
>>
>> Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and
>> SN65DSI84 driver") Signed-off-by: Frieder Schrempf
>> <frieder.schrempf@...tron.de>
>> ---
>>  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 7ba9467fff12..047c14ddbbf1
>> 100644
>> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> @@ -346,7 +346,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
>> *bridge,
>>
>>  	/* Deassert reset */
>>  	gpiod_set_value_cansleep(ctx->enable_gpio, 1);
>> -	usleep_range(1000, 1100);
>> +	usleep_range(10000, 11000);
>>
>>  	/* Get the LVDS format from the bridge state. */
>>  	bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
> 
> How about using fsleep?
> 
> Either way:
> Reviewed-by: Alexander Stein <alexander.stein@...tq-group.com>

Thanks for the review! I didn't know about fsleep. Anyway this would
probably be a separate change as the driver currently uses usleep
everywhere else. But I will keep it in mind for the future.