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: Fri, 9 Feb 2024 00:14:38 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Sibi Sankar <quic_sibis@...cinc.com>, sudeep.holla@....com,
 cristian.marussi@....com, andersson@...nel.org, jassisinghbrar@...il.com,
 robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org
Cc: linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, quic_rgottimu@...cinc.com,
 quic_kshivnan@...cinc.com, conor+dt@...nel.org
Subject: Re: [RFC 1/7] dt-bindings: mailbox: qcom: Add CPUCP mailbox
 controller bindings

On 8.02.2024 11:22, Sibi Sankar wrote:
> 
> 
> On 1/18/24 01:23, Konrad Dybcio wrote:
>>
>>
>> On 1/17/24 18:34, Sibi Sankar wrote:
>>> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox
>>> controller.
>>>
>>> Signed-off-by: Sibi Sankar <quic_sibis@...cinc.com>
>>> ---
>>
> 
> Hey Konrad,
> 
> Thanks for taking time to review the series.
> 
>> [...]
>>
>>> +  - |
>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +
>>> +    mailbox@...30000 {
>>> +        compatible = "qcom,x1e80100-cpucp-mbox", "qcom,cpucp-mbox";
>>> +        reg = <0x17430000 0x10000>, <0x18830000 0x300>;
>>
>> These reg spaces are quite far apart.. On 7280-8550, a similar
>> mailbox exists, although it's dubbed RIMPS-mbox instead. In
>> that case, I separated the mbox into tx (via
>> qcom-apcs-ipc-mailbox.c) and rx (with a simple driver). Still
>> haven't pushed or posted that anywhere, I'd need to access
>> another machine..
>>
>> On (some of) these SoCs, one of the channels (rx[1], iirc?) clearly
>> bleeds into the CPUFREQ_HW/OSM register region, which gives an
>> impression of misrepresenting the hardware. X1E doesn't have a
>> node for cpufreq_hw defined, so I can't tell whether it's also the
>> case here.
> 
> I am aware of ^^ discussion and the X1E doesn't have this problem.
> Both the regions described are only used for mailbox communication.
> X1E uses the scmi perf protocol for cpu dvfs.

Yes, that's clear.

I am however asking for something different: I presume the CPUSS
IP hasn't changed too much on this SoC, other than having new cores and
OSM now being controlled through a different firmware interface, and I'd
like to keep the hardware description in our DT as close to the metal as
possible.

In other words, if the good ol' OSM hardware is indeed there under however
many layers of firmware, and if RX does indeed bleed into its register
space, I'd prefer there be at least a syscon node describing the actual
block, and not a magic hwio entry that's many zeroes away.

Konrad


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ