[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94defe49-c87a-44f6-8768-03f3d6687ac3@quicinc.com>
Date: Wed, 23 Oct 2024 15:58:02 +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 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.
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
ath12k host currently doesn’t support reading and using, hence we are not adding it
now) could be a common property.
If you still recommend creating a separate binding for the QCN9274, we are open to
working on that.
Thank you for your guidance.
Powered by blists - more mailing lists