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

Message-ID: <7b3356a9-8f2b-49de-7ad3-b01c3279eac0@linaro.org>
Date:   Fri, 18 Nov 2022 15:03:41 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     neil.armstrong@...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 18/11/2022 14:30, neil.armstrong@...aro.org wrote:
> On 18/11/2022 11:45, Krzysztof Kozlowski wrote:
>> On 17/11/2022 10:47, Neil Armstrong wrote:
>>>>
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    const: qcom,mpss-dsm-mem
>>>>
>>>> Why do we need dedicated binding and compatible for it instead of using
>>>> memory-region phandle in the device?
>>>
>>> So like rmtfs, this memory zone is shared between APPS and the MPSS subsystem.
>>>
>>> Like rmtfs it makes no sense to link it to the MPSS PAS, since it's only a launcher,
>>> it doesn't represent the MPSS subsystem.
>>
>> This also does not represent a device. Memory region is not a device, so
>> this is as well not correct representation of hardware.
> 
> I never used the term device so far, but a shared memory region with a platform
> specific process to share the region between subsystems.

Yes, but you create a device in patch #2 for this binding.

> 
>>
>>>
>>> In the PAS startup process, the resources are released from APPS once the MPSS subsystem
>>> is running, which is not the case with the MPSS DSM where it must be shared during the whole
>>> lifetime of the system.
>>
>> I don't think that PAS releases the region. I checked the
>> qcom_q6v5_pas.c and there is only ioremap. The device stays loaded thus
>> the memory stays mapped.
> Yes PAS does release the firmware region when the firmware is started,
> qcom_scm_pas_metadata_release() does that.

Indeed, I see it now.

> 
>>
>> 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.

The point is that this memory region is nothing special and does not
deserve its own compatible. We keep adding here compatibles to fulfill
some Linux implementation specifics, don't we?

Best regards,
Krzysztof