linux-kernel - Re: [PATCH v5 01/13] dt-bindings: net: wireless: describe the ath12k AHB module

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: <724a4822-469a-45bb-bfb1-c02b54e971a3@quicinc.com>
Date: Mon, 3 Feb 2025 14:35:41 +0530
From: Raj Kumar Bhagat <quic_rajkbhag@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: <ath12k@...ts.infradead.org>, <linux-wireless@...r.kernel.org>,
        Kalle Valo
	<kvalo@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jeff Johnson
	<jjohnson@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 01/13] dt-bindings: net: wireless: describe the ath12k
 AHB module

On 1/30/2025 1:58 PM, Krzysztof Kozlowski wrote:
>> +  memory-region:
>> +    description:
>> +      phandle to a node describing reserved memory (System RAM memory)
>> +      used by ath12k firmware (see bindings/reserved-memory/reserved-memory.txt)
> Do not say what DT syntax is, so "phandle to a node" is redundant,
> reserved-memory.txt is redundant. The only useful part here is "used by
> ath12k firmware", so based on this none of below are used by the driver
> and driver just passes them to the firmware?
> 

Sure, will rephrase the description.

These reserved memory-regions are utilized by the ath12k firmware. The ath12k driver
stores these memory addresses solely for the purpose of collecting crash dumps
(RAM dumps) when the firmware encounters a crash.

>> +    items:
>> +      - description: Q6 memory region
>> +      - description: m3 dump memory region
>> +      - description: Q6 caldata memory region
>> +      - description: Multi Link Operation (MLO) Global memory region
>> +
>> +  memory-region-names:
>> +    description:
>> +      Name of the reserved memory region used by ath12k firmware
> Drop description.
> 

Sure.

>> +    items:
>> +      - const: q6-region
>> +      - const: m3-dump
>> +      - const: q6-caldb
>> +      - const: mlo-global-mem
>> +
>> +  qcom,ath12k-calibration-variant:
>> +    $ref: /schemas/types.yaml#/definitions/string
> Why this is named after ath12k? Why this is just not
> "qcom,calibration-variant"? None of the other properties have ath12k in
> their names, so why this one in the WSI schema was named like that?
> 

This property is added after the below comment.
https://lore.kernel.org/all/qzjgpwemwaknwbs3dwils6kaa5c3inabfvkaryvc32kblzfhy3@6yduooj4dk63/

This `ath12k` in the name of this property is inherited from the 'qcom,ath10k.yaml' and
'qcom,ath11k.yaml'. Same was followed for WSI schema as well.

>> +    description:
>> +      String to uniquely identify variant of the calibration data for designs
>> +      with colliding bus and device ids
> I don't think this property is here possible. How could you have on the
> same SoC different devices?

The WiFi controller in the SoC includes an internal or external Front-End Module (FEM).
These FEMs can vary and require different calibration data. This property uniquely
identify the variant of calibration data required by a FEM.