linux-kernel - Re: [RFC 0/3] Enable firmware-managed USB resources on Qcom targets

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: <4d2501a7-d56d-4736-95d7-41556166859b@linaro.org>
Date: Tue, 5 Mar 2024 18:12:18 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Sriram Dash <quic_sriramd@...cinc.com>, andersson@...nel.org,
 konrad.dybcio@...aro.org, vkoul@...nel.org, kishon@...nel.org,
 robh@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 gregkh@...uxfoundation.org, quic_wcheng@...cinc.com,
 Thinh.Nguyen@...opsys.com, p.zabel@...gutronix.de,
 linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, quic_psodagud@...cinc.com,
 quic_nkela@...cinc.com, manivannan.sadhasivam@...aro.org,
 ulf.hansson@...aro.org, sudeep.holla@....com, quic_shazhuss@...cinc.com
Subject: Re: [RFC 0/3] Enable firmware-managed USB resources on Qcom targets

On 05/03/2024 17:57, Sriram Dash wrote:
> Some target systems allow multiple resources to be managed by firmware.

Which? Why this is so vague...

> On these targets, tasks related to clocks, regulators, resets, and
> interconnects can be delegated to the firmware, while the remaining
> responsibilities are handled by Linux.
> 
> To support the management of partial resources in Linux and leave the rest
> to firmware, multiple power domains are introduced. Each power domain can
> manage one or more resources, depending on the specific use case.
> 
> These power domains handle SCMI calls to the firmware, enabling the
> activation and deactivation of firmware-managed resources.
> 
> The driver is responsible for managing multiple power domains and
> linking them to consumers as needed. Incase there is only single
> power domain, it is considered to be a standard GDSC hooked on to
> the qcom dt node which is read and assigned to device structure
> (by genpd framework) before the driver probe even begins.

This will break the ABI. Sorry, come with an ABI stable solution.

Best regards,
Krzysztof