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: <4302310a-b233-4cea-9a4b-d463fd1f455f@kernel.org>
Date: Thu, 5 Jun 2025 11:07:53 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>,
 Michal Wilczynski <m.wilczynski@...sung.com>
Cc: Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>,
 Fu Wei <wefu@...hat.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
 Frank Binns <frank.binns@...tec.com>, Matt Coster <matt.coster@...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 05/06/2025 10:10, Bartosz Golaszewski wrote:
>>
>> Bart,
>> Given Krzysztof's valid concerns about the current name based
>> lookup in pwrseq_get() and the benefits of phandle based resource
>> linking in OF platforms: Would you be open to a proposal for extending
>> the pwrseq API to allow consumers to obtain a sequencer (or a specific
>> target sequence) via a phandle defined in their Device Tree node? For
>> instance, a consumer device could specify power-sequencer =
>> <&aon> and a new API variant could resolve this.
>>
> 
> I can be open to it all I want, but I bet Krzysztof won't be open to
> introducing anything like a power-sequencer device property in DT
> bindings. Simply because there's no such thing in the physical world.

Yep

> The concept behind the power sequencing framework was to bind
> providers to consumers based on existing links modelling real device
> properties (which a "power-sequencer" is not). I commented on it under
> another email saying that you already have a link here - the
> power-domains property taking the aon phandle. In your pwrseq

Exactly.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ