linux-kernel - Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: mpm: Pass MSG RAM slice through phandle

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, 12 Apr 2023 19:06:24 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Stephan Gerhold <stephan@...hold.net>
Cc:     Rob Herring <robh@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Gross <agross@...nel.org>, linux-kernel@...r.kernel.org,
        Shawn Guo <shawn.guo@...aro.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Marc Zyngier <maz@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: mpm: Pass MSG
 RAM slice through phandle



On 12.04.2023 18:53, Krzysztof Kozlowski wrote:
> On 12/04/2023 14:09, Konrad Dybcio wrote:
>>
>>
>> On 12.04.2023 13:55, Krzysztof Kozlowski wrote:
>>> On 12/04/2023 13:47, Konrad Dybcio wrote:
>>>>> For unrelated reasons I actually have some patches for this, that switch
>>>>> the /smd top-level node to a "remoteproc-like" node dedicated to the
>>>>> RPM, similar to how WCNSS/ADSP/Modem/etc are represented. I need this to
>>>>> add additional (optional) properties like "resets" and "iommus" for the
>>>>> RPM, but it would allow adding arbitrary subnodes as well:
>>>>>
>>>>> https://github.com/msm8916-mainline/linux/commit/35231ac28703805daa8220f1233847c7df34589e
>>>>>
>>>>> I could finish those up and post them if that would help...
>>>> Krzysztof, what do you think?
>>>
>>> I don't know what is there in MSM8916 and how it should be represented.
>> Similarly to other Qualcomm SoCs, MSM8916 has a RPM (Cortex-M3) core,
>> which communicates over the SMD protocol (or G-LINK on >=8996).
>>
>> The Qualcomm firmware loads the RPM fw blob and sets it up early in
>> the boot process, but msm8916-mainline folks managed to get TF-A
>> going and due to it being less.. invasive.. than the Qualcomm TZ,
>> RPM needs a bit more handling to be accessible.
>>
>> The M3 core is wired up through the CNoC bus and we communicate
>> with it through the MSG RAM and the "APCS mailbox".
> 
> Thanks, that's actually good description. Yet I still do not know what
> is exactly the problem and the question. Linking some out of tree
> commits does not give me the answer, at least I cannot get that answer
> form the link.
> 
> For example what I don't understand is: why additional resources (like
> resets) can be provided only in new binding, but not in the old.
The old binding dictates that the rpm node (which in turn
holds all "devices" that only interface with RPM, like RPMCC) is
a child of smd{}, which does not make sense logically, as SMD is
a protocol (e.g. we don't place devices connected over i2c under
/i2c{}). The rpm node lacks a compatible, as it's representing
an "smd channel", so there's no driver so there's no way to assert
resets etc.

On newer SoCs that still implement SMD RPM (like 8996), we do
actually have a driver and a parent node which it binds to
(rpm-glink).

AFAIU:
In both cases, the "final" drivers (rpmcc, rpmpd..) are bound
after hitting a SMD/GLINK callback that tells Linux we're ready
to rock. That's an issue for Stephan, as these callbacks won't
ever happen if the RPM core is not initialized (and TF-A doesn't
do that).

Konrad
> 
> Best regards,
> Krzysztof
>