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.
Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com>
---
.../bindings/net/wireless/qcom,ath12k.yaml | 29 +++++++++++++------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
index 1b5884015b15..ecf38af747f7 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2024 Linaro Limited
+# Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k.yaml#
@@ -52,18 +53,28 @@ properties:
required:
- compatible
- reg
- - vddaon-supply
- - vddwlcx-supply
- - vddwlmx-supply
- - vddrfacmn-supply
- - vddrfa0p8-supply
- - vddrfa1p2-supply
- - vddrfa1p8-supply
- - vddpcie0p9-supply
- - vddpcie1p8-supply
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - pci17cb,1107
+ then:
+ required:
+ - vddaon-supply
+ - vddwlcx-supply
+ - vddwlmx-supply
+ - vddrfacmn-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p8-supply
+ - vddpcie0p9-supply
+ - vddpcie1p8-supply
+
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
--
2.34.1On 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. Best regards, Krzysztof
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].
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 description. Best regards, Krzysztof
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?
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
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.
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. > 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*. > > If you still recommend creating a separate binding for the QCN9274, we are open to > working on that. Best regards, Krzysztof
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”.
© 2016 - 2024 Red Hat, Inc.