linux-kernel - Re: [PATCH 04/10] drm/tidss: Move reset to the end of dispc

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] [day] [month] [year] [list]

Message-ID: <da8e16ab-9630-4532-9f0a-628e3480f0bd@ideasonboard.com>
Date:   Mon, 6 Nov 2023 13:56:06 +0200
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Aradhya Bhatia <a-bhatia1@...com>,
        Devarsh Thakkar <devarsht@...com>,
        Jyri Sarha <jyri.sarha@....fi>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 04/10] drm/tidss: Move reset to the end of dispc_init()

On 06/11/2023 00:54, Laurent Pinchart wrote:
> On Thu, Nov 02, 2023 at 08:40:10AM +0200, Tomi Valkeinen wrote:
>> On 01/11/2023 15:57, Laurent Pinchart wrote:
>>> On Wed, Nov 01, 2023 at 11:17:41AM +0200, Tomi Valkeinen wrote:
>>>> We do a DSS reset in the middle of the dispc_init(). While that happens
>>>> to work now, we should really make sure that e..g the fclk, which is
>>>> acquired only later in the function, is enabled when doing a reset. This
>>>> will be handled in a later patch, but for now, let's move the
>>>> dispc_softreset() call to the end of dispc_init(), which is a sensible
>>>> place for it anyway.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
>>>
>>> Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
>>>
>>> But do I understand correctly that the device isn't powered up at this
>>> point ? That seems problematic.
>>
>> Indeed. It's fixed later in this series.
>>
>>> I'm also not sure why we need to reset the device at probe time.
>>
>> That's the usual place to do a reset, to make sure the HW is in a known
>> state, is it not? Where would you place it?
> 
> The first time the device is used, or possibly every time it is resumed
> ? It seems that you're resuming it at probe time for the only reason
> that you want to then reset it. Resuming it at probe could get entirely
> skipped.

As I mentioned in the earlier reply, I feel better resetting as early as 
possible. Otherwise the DSS may be running, in an unknown state, doing 
things.

It's hard to say if that would cause problems or not. The DSS IP would 
be using clocks that have not been set up or enabled by the driver, 
which might mean that the clock rates get changed underneath, caused by 
some other driver configuring its clocks. That might lead to DSS IP 
misbehaving. Whether that would cause any issues, hard to say.

Still, I'd much rather have the DSS IP in a known state.

We could reset it every time the DSS is resumed, and that would be safe, 
but it also feels pointless, as the DSS is in a known state already 
(presuming it was reset in probe).

  Tomi