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: <dfec6a0b-86c6-fb61-51f6-d1e400a6f5ef@linaro.org>
Date:   Fri, 18 Nov 2022 11:45:34 +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 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.

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

We have already three of such "memory region devices" and we keep
growing it. It's not scalable.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ