linux-kernel - Re: [RFC PATCH 1/6] dt-bindings: net: wireless: update required properties for ath12k PCI 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: <b2a18ac5-727d-4f5b-9465-c360e6432dc5@quicinc.com>
Date: Fri, 25 Oct 2024 15:29:49 +0530
From: Raj Kumar Bhagat <quic_rajkbhag@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, <ath12k@...ts.infradead.org>
CC: <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>,
        Bjorn
 Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [RFC PATCH 1/6] dt-bindings: net: wireless: update required
 properties for ath12k PCI module

On 10/23/2024 5:38 PM, Krzysztof Kozlowski wrote:
> On 23/10/2024 12:28, Raj Kumar Bhagat wrote:
>> On 10/23/2024 12:29 PM, Krzysztof Kozlowski wrote:
>>> On 23/10/2024 08:53, Raj Kumar Bhagat wrote:
>>>> On 10/23/2024 12:17 PM, Krzysztof Kozlowski wrote:
>>>>> On 23/10/2024 08:45, Raj Kumar Bhagat wrote:
>>>>>> On 10/23/2024 12:05 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 23/10/2024 08:03, Raj Kumar Bhagat wrote:
>>>>>>>> The current device-tree bindings for the Ath12K module list many
>>>>>>>> WCN7850-specific properties as required. However, these properties are
>>>>>>>> not applicable to other Ath12K devices.
>>>>>>>>
>>>>>>>> Hence, remove WCN7850-specific properties from the required section,
>>>>>>>> retaining only generic properties valid across all Ath12K devices.
>>>>>>>> WCN7850-specific properties will remain required based on the device's
>>>>>>>> compatible enum.
>>>>>>> Just not true. These apply to all devices described in this binding.
>>>>>>>
>>>>>>> NAK.
>>>>>>>
>>>>>>> Don't send patches for your downstream stuff.
>>>>>> This is not for downstream. This series is the per-requisite for ath12k
>>>>>> MLO support in upstream.
>>>>>>
>>>>>> In the subsequent patch [2/6] we are adding new device (QCN9274) in this
>>>>>> binding that do not require the WCN7850 specific properties.
>>>>>>
>>>>>> This is a refactoring patch for the next patch [2/6].
>>>>> It's just wrong. Not true. At this point of patch there are no other
>>>>> devices. Don't refactor uselessly introducing incorrect hardware
>>>> Ok then, If we squash this patch with the next patch [2/6], that actually adding
>>>> the new device, then this patch changes are valid right?
>>> Yes, except I asked to have separate binding for devices with different
>>> interface (WSI). You add unrelated devices to same binding, growing it
>>> into something tricky to manage. Your second patch misses if:then
>>> disallwing all this WSI stuff for existing device... and then you should
>>> notice there is absolutely *nothing* in common.
>>>
>> I understand your point about having separate bindings if there are no common
>> properties. However, the title and description of this binding indicate that it
>> is intended for Qualcomm ath12k wireless devices with a PCI bus. Given this, the
>> QCN9274 seems to fit within the same binding.
> Feel free to fix it. Or add common schema used by multiple bindings.
> 
>> Additionally, there will likely be more properties added in the future that could
>> be common. For example, the “qcom,ath12k-calibration-variant” property (which the
> You are supposed to add them now, not later. See writing bindings. They
> are supposed to be complete.
> 

Sure will add "qcom,ath12k-calibration-variant" in next version.

>> ath12k host currently doesn’t support reading and using, hence we are not adding it
>> now) could be a common property.
> What is "host"? Either the device has this property or not. Whether host
> supports something does not really matter, right? You have hardware
> property or you have it *not*.

Ah, my bad. I meant to say “ath12k driver”.