[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <606083d8-4332-45e4-be41-08ca5425cc03@kernel.org>
Date: Wed, 23 Oct 2024 08:59:09 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Raj Kumar Bhagat <quic_rajkbhag@...cinc.com>, 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 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.
Best regards,
Krzysztof
Powered by blists - more mailing lists