linux-kernel - Re: [PATCH 1/2] dt-bindings: reserved-memory: document Qualcomm MPSS DSM memory

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] [day] [month] [year] [list]

Message-ID: <891304de-c216-fecf-00ee-d70d61c847b6@linaro.org>
Date:   Tue, 29 Nov 2022 09:27:24 +0100
From:   neil.armstrong@...aro.org
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Frank Rowand <frowand.list@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: reserved-memory: document Qualcomm MPSS
 DSM memory

On 24/11/2022 14:57, Krzysztof Kozlowski wrote:
> On 23/11/2022 11:19, neil.armstrong@...aro.org wrote:
>>>>> We have already three of such "memory region devices" and we keep
>>>>> growing it. It's not scalable.
>>>>
>>>> If we want to properly describe this, we must then represent the MPSS subsystem
>>>> and associate this memory region.
>>>
>>> I don't see why. None of devices in your DTS reference this memory
>>> region, so it is purely to keep it mapped for Modem, right? In such case
>>> I still do not get why PAS/PIL, who starts and stops the remote
>>> processor, could not prepare the memory and share it with modem.
>>
>> OK you've got a point, but this is still an implementation detail.
>>
>> I got some more background about why this memory zone appeared, before it
>> was including in the modem reserved-memories, but for flexibility reasons
>> this is now in the hands of the APPS runtime (linux) to setup this memory
>> zone and share it to the MPSS subsystem.
>>
>> So the only requirement for the PAS is to make sure this zone is shared
>> before starting the startup process, not to actually do the share setup.
>>
>> The zone will need to be shared whatever the PAS state is (probe, startup, remove, ...).
> 
> I don't understand here. The memory region should be shared before
> remote processor start or before the PAS probe? If the second, why? What
> if your driver probes a bit later - after PAS probe? Then all is lost...

After offline discussions, I'll associate the DSM memory zone to the PAS MPSS
loader instead to make sure the zone is shared before startup.

Thanks,
Neil

> 
> Best regards,
> Krzysztof
>