linux-kernel - Re: [PATCH v1 1/5] dt-bindings: soc: qcom: Add 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: <424de835-0b9b-49d5-a0d8-dc74c58ff5a1@linaro.org>
Date:   Tue, 24 Oct 2023 15:55:04 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Zhenhua Huang <quic_zhenhuah@...cinc.com>, agross@...nel.org,
        andersson@...nel.org, konrad.dybcio@...aro.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org
Cc:     linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...cinc.com,
        quic_tingweiz@...cinc.com
Subject: Re: [PATCH v1 1/5] dt-bindings: soc: qcom: Add memory_dump driver
 bindings

On 24/10/2023 12:57, Zhenhua Huang wrote:
> 
> 
> On 2023/10/23 20:52, Krzysztof Kozlowski wrote:
>> On 23/10/2023 13:54, Zhenhua Huang wrote:
>>>
>>>
>>> On 2023/10/23 17:27, Krzysztof Kozlowski wrote:
>>>> On 23/10/2023 11:20, Zhenhua Huang wrote:
>>>>> Add bindings for the QCOM Memory Dump driver providing debug
>>>>
>>>> Bindings are for hardware, not driver. This suggests it is not suitable
>>>> for bindings at all.
>>>>
>>>>> facilities. Firmware dumps system cache, internal memory,
>>>>> peripheral registers to reserved DDR as per the table which
>>>>> populated by the driver, after crash and warm reset.
>>>>
>>>> Again driver :/
>>>
>>> Thanks for pointing out. Qualcomm memory dump device is a reserved
>>> memory region which is used to communicate with firmware. I will update
>>> description in next version.
>>
>> I have still doubts that it is suitable for DT. I usually expect  such
>> firmware feature-drivers to be instantiated by existing firmware
>> drivers. You do not need DT for this.
> 
> Got it, as it interacts with firmware, you think it should be a firmware 
> driver? But it seems there should not be existing suitable place to put 
> it now(qcom_scm.c is for TZ). Shall we create one new file like 
> *qcom_sdi.c* in drivers/firmware and put it there? Because SDI(system 
> debug image, which is part of bootloader) is the firmware doing the things.

Dunno, didn't think about this. I comment here only about bindings. This
does not look suitable for bindings. That's it.

Best regards,
Krzysztof