linux-kernel - Re: [PATCH v3 3/8] drm/imagination: Use pwrseq for TH1520 GPU power management

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: <44fdaa5c-0fa4-457e-b193-e83cd06c1aed@kernel.org>
Date: Fri, 13 Jun 2025 12:01:01 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Michal Wilczynski <m.wilczynski@...sung.com>,
 Bartosz Golaszewski <brgl@...ev.pl>, Matt Coster <matt.coster@...tec.com>,
 "krzk+dt@...nel.org" <krzk+dt@...nel.org>
Cc: Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>,
 Fu Wei <wefu@...hat.com>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
 Frank Binns <frank.binns@...tec.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>,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, Ulf Hansson <ulf.hansson@...aro.org>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v3 3/8] drm/imagination: Use pwrseq for TH1520 GPU power
 management

On 13/06/2025 11:49, Michal Wilczynski wrote:
> 
> 
> On 6/13/25 10:25, Michal Wilczynski wrote:
>>
>>
>> On 6/13/25 08:44, Krzysztof Kozlowski wrote:
>>> On 11/06/2025 14:01, Michal Wilczynski wrote:
>>>>
>>>> However, this leads me back to a fundamental issue with the
>>>> consumer side implementation in the generic pvr_device.c driver. The
>>>> current fallback code is:
>>>>
>>>> /*
>>>>  * If the error is -EPROBE_DEFER, it's because the
>>>>  * optional sequencer provider is not present
>>>>  * and it's safe to fall back on manual power-up.
>>>>  */
>>>> if (pwrseq_err == -EPROBE_DEFER)
>>>>         pvr_dev->pwrseq = NULL;
>>>>
>>>> As Krzysztof noted, simply ignoring -EPROBE_DEFER is not ideal. But if I
>>>> change this to a standard deferred probe, the pvr_device.c driver will
>>>
>>> Why? You have specific compatible for executing such quirks only for
>>> given platform.
> 
> I realized now that you may have meant the "thead,th1520-gpu" compatible,
> not the "thead,th1520" SoC compatible.
> 
> In any case, the whole reason for using the pwrseq framework is to avoid
> polluting the generic driver with SoC specific logic and instead offload
> that responsibility to a pwrseq provider. Therefore, I can't simply add
> a check like if (compatible == "thead,th1520-gpu") to the generic driver
> to decide whether to get a power sequencer. This entire matching
> responsibility was intended to be offloaded to the pwrseq framework.

No, just do how all drivers are doing - driver match data, describing
that there is some component, e.g. quirks/flags, number of clocks and
their names typically. In your case - name or presence of pwrseq.



Best regards,
Krzysztof