mbox series

[RFC,0/6] wifi: ath12k: Add WSI node for QCN9274 in RDP433 for MLO

Message ID 20241023060352.605019-1-quic_rajkbhag@quicinc.com
Headers show
Series wifi: ath12k: Add WSI node for QCN9274 in RDP433 for MLO | expand

Message

Raj Kumar Bhagat Oct. 23, 2024, 6:03 a.m. UTC
The RDP433 is a Qualcomm Reference Design Platform based on the
IPQ9574. It features three QCN9274 WiFi devices connected to PCIe1,
PCIe2, and PCIe3. These devices are also interconnected via a WLAN
Serial Interface (WSI) connection. This WSI connection is essential
to exchange control information among these devices.

This patch series describes the WSI interface found in QCN9274 and
uses this device-tree node in the Ath12k driver to provide details
of adjacent devices in Multi Link Operation (MLO) among multiple
QCN9274 devices.

NOTES:
1. As ath12k MLO patches are not ready yet, this patchset does not apply
   to the ath.git ath-next branch and that's why the patchset is marked
   as RFC. These are the work-in-progress patches we have at the moment.
   The full set of MLO patches is available at:
   https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/log/?h=ath12k-mlo-qcn9274

2. The dependency marked below applies only to the DTS patch. The
   dt-bindings patches do not have this dependency.

Depends-On: [PATCH V7 0/4] Add PCIe support for IPQ9574
Link: https://lore.kernel.org/linux-pci/20240801054803.3015572-1-quic_srichara@quicinc.com/

Aditya Kumar Singh (1):
  wifi: ath12k: assign unique hardware link IDs during QMI host cap

Harshitha Prem (1):
  wifi: ath12k: parse multiple device information from device tree

Karthikeyan Periyasamy (1):
  wifi: ath12k: Send partner device details in QMI MLO capability

Raj Kumar Bhagat (3):
  dt-bindings: net: wireless: update required properties for ath12k PCI
    module
  dt-bindings: net: wireless: ath12k: describe WSI property for QCN9274
  arm64: dts: qcom: ipq9574: Add WiFi nodes for RDP433

 .../bindings/net/wireless/qcom,ath12k.yaml    |  90 +++++++++++++--
 arch/arm64/boot/dts/qcom/ipq9574-rdp433.dts   |  62 +++++++++-
 drivers/net/wireless/ath/ath12k/core.c        | 106 ++++++++++++++++--
 drivers/net/wireless/ath/ath12k/core.h        |   2 +
 drivers/net/wireless/ath/ath12k/qmi.c         |  98 +++++++++++++---
 5 files changed, 322 insertions(+), 36 deletions(-)


base-commit: 7603a9349b2fc64152a734f253cf8d8e5befb6db
prerequisite-patch-id: d1334693a2e8da65ae7b458ee4adb459850ad2e7
prerequisite-patch-id: 87f73b342f67c2636390a7da1294cee90f1fff48
prerequisite-patch-id: 46d8302766527d16cdd90c59ded6cbae0ec4ad70
prerequisite-patch-id: b17db6783b1c35f3e8812f621730fe0a1a57a14e

Comments

Raj Kumar Bhagat Oct. 25, 2024, 9:59 a.m. UTC | #1
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”.