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]

Date: Wed, 6 Mar 2024 08:04:49 +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 19:04, Sriram Dash wrote:
> On 3/5/2024 10:42 PM, Krzysztof Kozlowski wrote:
>> 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...
>>
> 
> SA8775 will be using it as pilot. Will include the target name.
> 
>>> 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.
>>
> 
> The plan is to include multiple power-domains and fw-managed
> property or similar in the device tree and fw-managed property
> will be deciding if we need some resource management offloaded
> to firmware. So, OS is always in control here. The decision
> making will be done in the drivers. Also, there will be no
> separate vendor hooks.

This does not answer ABI breakage. Also, I don't have a clue what are
"vendor hooks".

Best regards,
Krzysztof