Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop

[Rob Herring (Arm)]

On Mon, 29 Apr 2024 16:04:51 +0200, Marc Gonzalez wrote:
> The ath10k driver waits for an "MSA_READY" indicator
> to complete initialization. If the indicator is not
> received, then the device remains unusable.
> 
> cf. ath10k_qmi_driver_event_work()
> 
> Several msm8998-based devices are affected by this issue.
> Oddly, it seems safe to NOT wait for the indicator, and
> proceed immediately when QMI_EVENT_SERVER_ARRIVE.
> 
> Jeff Johnson wrote:
> 
>   The feedback I received was "it might be ok to change all ath10k qmi
>   to skip waiting for msa_ready", and it was pointed out that ath11k
>   (and ath12k) do not wait for it.
> 
>   However with so many deployed devices, "might be ok" isn't a strong
>   argument for changing the default behavior.
> 
> Kalle Valo first suggested setting a bit in firmware-5.bin to trigger
> work-around in the driver. However, firmware-5.bin is parsed too late.
> So we are stuck with a DT property.
> 
> Signed-off-by: Pierre-Hugues Husson 
> Signed-off-by: Marc Gonzalez 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 5 +
>  1 file changed, 5 insertions(+)
> 

Acked-by: Rob Herring (Arm) 

[PATCH v2] net: wireless: Explicitly include correct DT includes

[Rob Herring]

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
---
v2:
 - Split out can, dsa, wireless, phy/pcs to separate patches
---
 drivers/net/wireless/ath/ath10k/ahb.c| 2 +-
 drivers/net/wireless/ath/ath11k/qmi.c| 1 -
 drivers/net/wireless/ath/wcn36xx/main.c  | 3 +--
 drivers/net/wireless/intersil/orinoco/airport.c  | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7915/init.c | 1 +
 drivers/net/wireless/mediatek/mt76/mt7915/soc.c  | 1 -
 drivers/net/wireless/mediatek/mt76/mt7996/init.c | 1 +
 drivers/net/wireless/silabs/wfx/bus_sdio.c   | 2 +-
 8 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ahb.c 
b/drivers/net/wireless/ath/ath10k/ahb.c
index 4a006fb4d424..76efea2f1138 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -5,7 +5,7 @@
  */
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "core.h"
diff --git a/drivers/net/wireless/ath/ath11k/qmi.c 
b/drivers/net/wireless/ath/ath11k/qmi.c
index d4eaf7d2ba84..98efa0f299ca 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define SLEEP_CLOCK_SELECT_INTERNAL_BIT0x02
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 8dbd115a393c..2bd1163177f0 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -19,9 +19,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/wireless/intersil/orinoco/airport.c 
b/drivers/net/wireless/intersil/orinoco/airport.c
index a890bfa0d5cc..45ac00fdafa5 100644
--- a/drivers/net/wireless/intersil/orinoco/airport.c
+++ b/drivers/net/wireless/intersil/orinoco/airport.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "orinoco.h"
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7915/init.c
index ac2049f49bb3..aec47de35f53 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/init.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "mt7915.h"
 #include "mac.h"
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/soc.c 
b/drivers/net/wireless/mediatek/mt76/mt7915/soc.c
index 32c137066e7f..701a27ffa4c2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/soc.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/soc.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
index f1b48cdda58f..5c980534f611 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "mt7996.h"
 #include "mac.h"
diff --git a/drivers/net/wireless/silabs/wfx/bus_sdio.c 
b/drivers/net/wireless/silabs/wfx/bus_sdio.c
index 51a0d58a9070..909d5f346a01 100644
--- a/drivers/net/wireless/silabs/wfx/bus_sdio.c
+++ b/drivers/net/wireless/silabs/wfx/bus_sdio.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.40.1


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v1] dt-bindings: net: wireless: ath10k: add ieee80211-freq-limit property

[Rob Herring]

On Fri, 09 Jun 2023 19:27:23 +0200, Christian Lamparter wrote:
> This is an existing optional property that ieee80211.yaml/cfg80211
> provides. It's useful to further restrict supported frequencies
> for a specified device through device-tree.
> 
> The driver supported this since ~2018 by
> commit 34d5629d2ca8 ("ath10k: limit available channels via DT 
> ieee80211-freq-limit")
> 
> Signed-off-by: Christian Lamparter 
> ---
> 
> Note: this is for ath10k. The other patch is for a different driver (ath11k).
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.yaml| 5 +
>  1 file changed, 5 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml:171:1: 
[error] duplication of key "allOf" in mapping (key-duplicates)

dtschema/dtc warnings/errors:
make[1]: *** Deleting file 
'Documentation/devicetree/bindings/net/wireless/qcom,ath10k.example.dts'
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml:171:1: found 
duplicate key "allOf" with value "[]" (original value: "[]")
make[1]: *** [Documentation/devicetree/bindings/Makefile:26: 
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs
./Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml:171:1: found 
duplicate key "allOf" with value "[]" (original value: "[]")
Traceback (most recent call last):
  File "/usr/local/bin/dt-doc-validate", line 62, in 
ret |= check_doc(f)
  File "/usr/local/bin/dt-doc-validate", line 31, in check_doc
for error in sorted(dtschema.DTValidator.iter_schema_errors(testtree), 
key=lambda e: e.linecol):
  File "/usr/local/lib/python3.10/dist-packages/dtschema/lib.py", line 736, in 
iter_schema_errors
cls.annotate_error(error, meta_schema, error.schema_path)
  File "/usr/local/lib/python3.10/dist-packages/dtschema/lib.py", line 712, in 
annotate_error
schema = schema[p]
KeyError: 'type'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml:
 ignoring, error parsing file
make: *** [Makefile:1512: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/f30552d1bfdb4c56f99ca79d8fbf52d3fcf71686.1686331623.git.chunk...@gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3 1/2] dt-bindings: net: Convert ATH10K to YAML

[Rob Herring]

On Thu, 06 Apr 2023 14:55:44 +0200, Konrad Dybcio wrote:
> Convert the ATH10K bindings to YAML.
> 
> Dropped properties that are absent at the current state of mainline:
> - qcom,msi_addr
> - qcom,msi_base
> 
> qcom,coexist-support and qcom,coexist-gpio-pin do very little and should
> be reconsidered on the driver side, especially the latter one.
> 
> Somewhat based on the ath11k bindings.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 215 -
>  .../bindings/net/wireless/qcom,ath10k.yaml | 357 
> +
>  2 files changed, 357 insertions(+), 215 deletions(-)
> 

Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.

Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.

Full log is available here: 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230406-topic-ath10k_bindings-v3-1-00895afc7...@linaro.org


wifi@0,0: reg: [[65536, 0, 0, 0, 0], [50397200, 0, 0, 0, 2097152]] is too long
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dtb

wifi@1880: 'qcom,snoc-host-cap-skip-quirk' does not match any of the 
regexes: 'pinctrl-[0-9]+'
arch/arm64/boot/dts/qcom/sdm845-xiaomi-polaris.dtb


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 1/2] dt-bindings: net: Convert ATH10K to YAML

[Rob Herring]

On Thu, 06 Apr 2023 13:54:04 +0200, Konrad Dybcio wrote:
> Convert the ATH10K bindings to YAML.
> 
> Dropped properties that are absent at the current state of mainline:
> - qcom,msi_addr
> - qcom,msi_base
> 
> qcom,coexist-support and qcom,coexist-gpio-pin do very little and should
> be reconsidered on the driver side, especially the latter one.
> 
> Somewhat based on the ath11k bindings.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 215 
>  .../bindings/net/wireless/qcom,ath10k.yaml | 359 
> +
>  2 files changed, 359 insertions(+), 215 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.example.dtb:
 wifi@1880: wifi-firmware: 'wifi-firmware' does not match any of the 
regexes: 'pinctrl-[0-9]+'
From schema: 
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.example.dtb:
 wifi@1880: wifi-firmware: 'iommus' is a required property
From schema: 
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml

doc reference errors (make refcheckdocs):
MAINTAINERS: Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt

See 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230406-topic-ath10k_bindings-v2-1-557f884a6...@linaro.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v6 3/3] wifi: ath10k: only load compatible DT cal data

[Rob Herring]

On Wed, Feb 8, 2023 at 10:51 PM  wrote:
>
> From: Edward Chow 
>
> ath10k might also be sensitive to the issue reported on
> https://github.com/openwrt/openwrt/pull/11345 , loading calibration
> data from a device tree node declared incompatible.
>
> ath10k will first check whether the device tree node is compatible
> with it, using the functionality introduced with the first patch of
> this series, ("PCI: of: Match pci devices or drivers against OF DT
> nodes") and only proceed loading calibration data from compatible node.
>
> Signed-off-by: Edward Chow 
> Reported-by: kernel test robot 

This is for fixes created as a result of kernel test robot report.
Reports on your broken patches should not have this.

> ---
>  drivers/net/wireless/ath/ath10k/core.c | 31 ++
>  drivers/net/wireless/ath/ath10k/hw.h   |  4 
>  drivers/net/wireless/ath/ath10k/pci.c  | 18 ++-
>  drivers/net/wireless/ath/ath10k/pci.h  |  2 ++
>  4 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 5eb131ab916f..4c9e8140aeff 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>
>  #include "core.h"
> @@ -26,6 +28,7 @@
>  #include "testmode.h"
>  #include "wmi-ops.h"
>  #include "coredump.h"
> +#include "pci.h"
>
>  unsigned int ath10k_debug_mask;
>  EXPORT_SYMBOL(ath10k_debug_mask);
> @@ -1958,6 +1961,34 @@ static int ath10k_download_cal_nvmem(struct ath10k 
> *ar, const char *cell_name)
> size_t len;
> int ret;
>
> +   /* devm_nvmem_cell_get() will get a cell first from the OF
> +* DT node representing the given device with nvmem-cell-name
> +* "calibration", and from the global lookup table as a fallback,
> +* and an ath10k device could be either a pci one or a platform one.
> +*
> +* If the OF DT node is not compatible with the real device, the
> +* calibration data got from the node should not be applied.
> +*
> +* dev_is_pci(ar->dev) && ( no OF node || caldata not from node
> +* || not compatible ) -> do not use caldata .
> +*
> +* !dev_is_pci(ar->dev) -> always use caldata .
> +*
> +* The judgement for compatibility differs with ath9k for many
> +* DT using "qcom,ath10k" as compatibility string.
> +*/
> +   if (dev_is_pci(ar->dev) &&
> +   (!ar->dev->of_node ||
> +(of_property_match_string(ar->dev->of_node,
> +  "nvmem-cell-names",
> +  cell_name) < 0) ||
> +!of_device_get_match_data(ar->dev) ||
> +!(((const struct ath10k_hw_misc_flags *)
> +   of_device_get_match_data(ar->dev))->need_calibration) ||
> +!of_pci_node_match_driver(ar->dev->of_node,
> +  _pci_driver)))

That is just plain ugly and not understandable. Why do you still need
of_pci_node_match_driver()? If compatible using VID/PID doesn't match
the actual VID/PID, then you should never probe.

The prior explanations didn't really clear things up either. I'm
really at a loss as to what are the scenarios you need to work. Please
enumerate what are the different scenarios of what's in the DTs and
how you need the kernel/driver to respond.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v5 3/3] wifi: ath10k: only load compatible DT cal data

[Rob Herring]

On Fri, Feb 3, 2023 at 11:15 AM  wrote:
>
> > I think this can be done a bit cleaner and like other drivers. I see 2 
> > options.
> > The first way is use VID/PID compatible strings and don't set the
> > of_node pointer if there is a mismatch.
> Where should I do this? In pci_set_of_node() from drivers/pci/of.c?

Off the top of my head, I think so.

> > Upon further thought, why can't you decide all this just on PCI
> > VID/PID? The giant switch statement in ath10k_pci_probe() could all
> > just be struct of driver_data from the PCI match table.
>
> I cannot decide all this just on PCI VID/PID because PCI VID/PID cannot tell 
> whether calibration data are stored in the device (like most expansion cards) 
> or not (for example, in an NVRAM cell referenced by the device tree).
>

For a given VID/PID, you could have calibration data in DT that you
want to ignore sometimes and not other times (because the compatible
is wrong)?

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v5 3/3] wifi: ath10k: only load compatible DT cal data

[Rob Herring]

On Fri, Feb 3, 2023 at 4:48 AM  wrote:
>
> From: Edward Chow 
>
> ath10k might also be sensitive to the issue reported on
> https://github.com/openwrt/openwrt/pull/11345 , loading calibration
> data from a device tree node declared incompatible.
>
> ath10k will first check whether the device tree node is compatible
> with it, using the functionality introduced with the first patch of
> this series, ("PCI: of: Match pci devices or drivers against OF DT
> nodes") and only proceed loading calibration data from compatible node.
>
> Signed-off-by: Edward Chow 
> Reported-by: kernel test robot 
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 30 ++
>  drivers/net/wireless/ath/ath10k/pci.c  |  2 +-
>  drivers/net/wireless/ath/ath10k/pci.h  |  2 ++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 5eb131ab916f..a776b06f49b5 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>
>  #include "core.h"
> @@ -26,6 +28,7 @@
>  #include "testmode.h"
>  #include "wmi-ops.h"
>  #include "coredump.h"
> +#include "pci.h"
>
>  unsigned int ath10k_debug_mask;
>  EXPORT_SYMBOL(ath10k_debug_mask);
> @@ -1958,6 +1961,33 @@ static int ath10k_download_cal_nvmem(struct ath10k 
> *ar, const char *cell_name)
> size_t len;
> int ret;
>
> +   /* devm_nvmem_cell_get() will get a cell first from the OF
> +* DT node representing the given device with nvmem-cell-name
> +* "calibration", and from the global lookup table as a fallback,
> +* and an ath10k device could be either a pci one or a platform one.
> +*
> +* If the OF DT node is not compatible with the real device, the
> +* calibration data got from the node should not be applied.
> +*
> +* dev_is_pci(ar->dev) && ( no OF node || caldata not from node
> +* || not compatible ) -> do not use caldata .
> +*
> +* !dev_is_pci(ar->dev) -> always use caldata .
> +*
> +* The judgement for compatibility differs with ath9k for many
> +* DT using "qcom,ath10k" as compatibility string.
> +*/
> +   if (dev_is_pci(ar->dev) &&
> +   (!ar->dev->of_node ||
> +(of_property_match_string(ar->dev->of_node,
> +  "nvmem-cell-names",
> +  cell_name) < 0) ||
> +!of_device_is_compatible(ar->dev->of_node,
> + "qcom,ath10k") ||
> +!of_pci_node_match_driver(ar->dev->of_node,
> +  _pci_driver)))
> +   return -ENOENT;

I think this can be done a bit cleaner and like other drivers. I see 2 options.

The first way is use VID/PID compatible strings and don't set the
of_node pointer if there is a mismatch.

If you must use "qcom,ath10k" (and 9k) only, then we should make
of_device_get_match_data() work on PCI drivers. This should just
require adding of_match_table ptr and it needs a data struct with a
flag saying use cal data or not.

Upon further thought, why can't you decide all this just on PCI
VID/PID? The giant switch statement in ath10k_pci_probe() could all
just be struct of driver_data from the PCI match table.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 2/2] dt: bindings: add dt entry for ath10k default BDF name

[Rob Herring]

On Mon, 10 Jan 2022 23:14:15 +, Abhishek Kumar wrote:
> It is possible that BDF name with board-id+chip-id+variant
> combination is not found in the board-2.bin. Such cases can
> cause wlan probe to fail and completely break wifi. In such
> case there can be an optional property to define a default
> BDF name to search for in the board-2.bin file when none of
> the combinations (board-id,chip-id,variant) match.
> To address the above concern provide an optional proptery:
> qcom,ath10k-default-bdf
> 
> Signed-off-by: Abhishek Kumar 
> ---
> 
> Changes in v2:
>  - Changes in v2: none
> 
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt  | 4 
>  1 file changed, 4 insertions(+)
> 

Acked-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v1 01/15] dt-bindings: add pwrseq device tree bindings

[Rob Herring]

On Tue, Oct 26, 2021 at 9:42 AM Dmitry Baryshkov
 wrote:
>
> On 26/10/2021 15:53, Rob Herring wrote:
> > On Wed, Oct 06, 2021 at 06:53:53AM +0300, Dmitry Baryshkov wrote:
> >> Add device tree bindings for the new power sequencer subsystem.
> >> Consumers would reference pwrseq nodes using "foo-pwrseq" properties.
> >> Providers would use '#pwrseq-cells' property to declare the amount of
> >> cells in the pwrseq specifier.
> >
> > Please use get_maintainers.pl.
> >
> > This is not a pattern I want to encourage, so NAK on a common binding.
>
>
> Could you please spend a few more words, describing what is not
> encouraged? The whole foo-subsys/#subsys-cells structure?

No, that's generally how common provider/consumer style bindings work.

> Or just specifying the common binding?

If we could do it again, I would not have mmc pwrseq binding. The
properties belong in the device's node. So don't generalize the mmc
pwrseq binding.

It's a kernel problem if the firmware says there's a device on a
'discoverable' bus and the kernel can't discover it. I know you have
the added complication of a device with 2 interfaces, but please,
let's solve one problem at a time.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v1 01/15] dt-bindings: add pwrseq device tree bindings

[Rob Herring]

On Wed, Oct 06, 2021 at 06:53:53AM +0300, Dmitry Baryshkov wrote:
> Add device tree bindings for the new power sequencer subsystem.
> Consumers would reference pwrseq nodes using "foo-pwrseq" properties.
> Providers would use '#pwrseq-cells' property to declare the amount of
> cells in the pwrseq specifier.

Please use get_maintainers.pl.

This is not a pattern I want to encourage, so NAK on a common binding.

> 
> Signed-off-by: Dmitry Baryshkov 
> ---
>  .../bindings/power/pwrseq/pwrseq.yaml | 32 +++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq.yaml
> 
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq.yaml 
> b/Documentation/devicetree/bindings/power/pwrseq/pwrseq.yaml
> new file mode 100644
> index ..4a8f6c0218bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/pwrseq/pwrseq.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Power Sequencer devices
> +
> +maintainers:
> +  - Dmitry Baryshkov 
> +
> +properties:
> +  "#powerseq-cells":
> +description:
> +  Number of cells in a pwrseq specifier.
> +
> +patternProperties:
> +  ".*-pwrseq$":
> +description: Power sequencer supply phandle(s) for this node
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +qca_pwrseq: qca-pwrseq {
> +  #pwrseq-cells = <1>;
> +};
> +
> +bluetooth {
> +  bt-pwrseq = <_pwrseq 1>;
> +};
> +...
> -- 
> 2.33.0
> 
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests

[Rob Herring]

On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote:
> There are firmware versions which do not support host capability
> QMI request. We suspect either the host cap is not implemented or
> there may be firmware specific issues, but apparently there seem
> to be a generation of firmware that has this particular behavior.
> 
> For example, firmware build on Xiaomi Poco F1 (sdm845) phone:
> "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
> 
> If we do not skip the host cap QMI request on Poco F1, then we
> get a QMI_ERR_MALFORMED_MSG_V01 error message in the
> ath10k_qmi_host_cap_send_sync(). But this error message is not
> fatal to the firmware nor to the ath10k driver and we can still
> bring up the WiFi services successfully if we just ignore it.
> 
> Hence introducing this DeviceTree quirk to skip host capability
> QMI request for the firmware versions which do not support this
> feature.

So if you change the WiFi firmware, you may force a DT change too. Those 
are pretty independent things otherwise.

Why can't you just always ignore this error? If you can't deal with this 
entirely in the driver, then it should be part of the WiFi firmware so 
it's always in sync.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 2/2] dt: bindings: ath10k: Document qcom,ath10k-pre-calibration-data-mtd

[Rob Herring]

On Fri, Sep 18, 2020 at 08:11:03PM +0200, Ansuel Smith wrote:
> Document use of qcom,ath10k-pre-calibration-data-mtd bindings used to
> define from where the driver will load the pre-cal data in the defined
> mtd partition.
> 
> Signed-off-by: Ansuel Smith 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index b61c2d5a0..568364243 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -15,9 +15,9 @@ and also uses most of the properties defined in this doc 
> (except
>  "qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data"
>  to carry pre calibration data.
>  
> -In general, entry "qcom,ath10k-pre-calibration-data" and
> -"qcom,ath10k-calibration-data" conflict with each other and only one
> -can be provided per device.
> +In general, entry "qcom,ath10k-pre-calibration-data",
> +"qcom,ath10k-calibration-data-mtd" and "qcom,ath10k-calibration-data" 
> conflict with
> +each other and only one can be provided per device.
>  
>  SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
>  
> @@ -63,6 +63,12 @@ Optional properties:
>hw versions.
>  - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- qcom,ath10k-pre-calibration-data-mtd :

mtd is a Linuxism.

> + Usage: optional
> + Value type: 
> + Definition: pre calibration data read from mtd partition. Take 3 value, 
> the
> + mtd to read data from, the offset in the mtd partition and 
> the

The phandle is the mtd or partition?

Maybe you should be using nvmem binding here.

> + size of data to read.
>  - -supply: handle to the regulator device tree node
>  optional "supply-name" are "vdd-0.8-cx-mx",
>  "vdd-1.8-xo", "vdd-1.3-rfa", "vdd-3.3-ch0",
> -- 
> 2.27.0
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt: bindings: Add new regulator as optional property for WCN3990

[Rob Herring]

On Fri, 26 Jun 2020 23:31:41 +0530, Rakesh Pillai wrote:
> Add an additional regulator supply as an optional
> property for WCN3990.
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> 
> Signed-off-by: Rakesh Pillai 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3 1/3] dt-bindings: ath10k: Add wifi-firmware subnode for wifi node

[Rob Herring]

On Wed, 15 Apr 2020 23:01:44 +0530, Rakesh Pillai wrote:
> Add a wifi-firmware subnode for the wifi node.
> This wifi-firmware subnode is needed for the
> targets which do not support TrustZone.
> 
> Signed-off-by: Rakesh Pillai 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt   | 14 
> ++
>  1 file changed, 14 insertions(+)
> 

Acked-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 1/3] dt-bindings: ath10k: Add wifi-firmware subnode for wifi node

[Rob Herring]

On Wed, Mar 25, 2020 at 04:31:38PM +0530, Rakesh Pillai wrote:
> Add a wifi-firmware subnode for the wifi node.
> This wifi-firmware subnode is needed for the
> targets which do not support TrustZone.
> 
> Signed-off-by: Rakesh Pillai 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt   | 14 
> ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 71bf91f..65ee68e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -96,6 +96,17 @@ Optional properties:
>  - qcom,coexist-gpio-pin : gpio pin number  information to support coex
> which will be used by wifi firmware.
>  
> +* Subnodes
> +The ath10k wifi node can contain one optional firmware subnode.
> +Firmware subnode is needed when the platform does not have TustZone.
> +The firmware subnode must have:
> +
> +- iommus:
> + Usage: required
> + Value type: 
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +
>  Example (to supply PCI based wifi block details):
>  
>  In this example, the node is defined as child node of the PCI controller.
> @@ -196,4 +207,7 @@ wifi@1800 {
>   memory-region = <_msa_mem>;
>   iommus = <_smmu 0x0040 0x1>;
>   qcom,msa-fixed-perm;
> + wifi-firmware {
> + iommus = <_iommu 0xc22 0x1>;

Why can't you just add a 2nd entry to the existing 'iommus' property? 

A driver doing of_dma_configure() is generally not the right thing to 
do.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCHv2 1/2] dt-bindings: ath10k: Add new dt entries to identify coex support

[Rob Herring]

On Tue, 28 Jan 2020 00:48:55 +0530, Tamizh Chelvam wrote:
> This adds new dt entries qcom,coexist-support and qcom,coexist-gpio-pin
> which will be used by ath10k driver to identify coex support
> of a hardware and notify wifi firmware the gpio pin number.
> This pin number information is needed for the hardware QCA4019.
> 
> Signed-off-by: Tamizh Chelvam 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 7 +++
>  1 file changed, 7 insertions(+)
> 

Reviewed-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] ath10k: Add optional qdss clk

[Rob Herring]

On Sun, 22 Dec 2019 21:48:54 -0800, Bjorn Andersson wrote:
> The WiFi firmware found on sm8150 requires that the QDSS clock is
> ticking in order to operate, so add an optional clock to the binding to
> allow this to be specified in the sm8150 dts and add the clock to the
> list of clocks in the driver.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 2 +-
>  drivers/net/wireless/ath/ath10k/snoc.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt-bindings: ath10k: Add new dt entries to identify coex support

[Rob Herring]

On Sun, Dec 29, 2019 at 10:07 PM  wrote:
>
> Hi Rob,
>
> Thanks for your review comments.
>
> >> This adds new dt entries qcom,coexist-support and
> >> qcom,coexist-gpio-pin
> >> which will be used by ath10k driver to identify coex support
> >> of a hardware and notify wifi firmware the gpio pin number.
> >> This pin number information is needed for the hardware QCA4019.
> >>
> >> Signed-off-by: Tamizh Chelvam 
> >> ---
> >>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 6
> >> ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> index 0171283..a41e936 100644
> >> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> @@ -87,6 +87,10 @@ Optional properties:
> >>  Definition: Quirk specifying that the firmware expects the 8bit
> >> version
> >>  of the host capability QMI request
> >>  - qcom,xo-cal-data: xo cal offset to be configured in xo trim
> >> register.
> >> +- qcom,coexist-support : should contain eithr "0" or "1" to indicate

typo

> >> coex
> >> + support by the hardware.
> >> +- qcom,coexist-gpio-pin : gpio pin number  information to support
> >> coex
> >> +  which will be used by wifi firmware.
> >
> > What combinations of these 2 properties are valid?
> >
> > Is qcom,coexist-gpio-pin required for coexist support? If so then it
> > alone should be enough to enable/disable coexist.
> >
> qcom,coexist-gpio-pin is required for QCA4019 devices. And other ath10k
> devices doesn't required that value.
> So only added two fields to enable/disable coexist and another for
> notifying the gpio pin info.

Okay.

'qcom,coexist-support' can be boolean instead. Unless you need it to
override a default setting.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt-bindings: ath10k: Add new dt entries to identify coex support

[Rob Herring]

On Mon, Dec 16, 2019 at 05:10:14PM +0530, Tamizh Chelvam wrote:
> This adds new dt entries qcom,coexist-support and qcom,coexist-gpio-pin
> which will be used by ath10k driver to identify coex support
> of a hardware and notify wifi firmware the gpio pin number.
> This pin number information is needed for the hardware QCA4019.
> 
> Signed-off-by: Tamizh Chelvam 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 0171283..a41e936 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -87,6 +87,10 @@ Optional properties:
>   Definition: Quirk specifying that the firmware expects the 8bit version
>   of the host capability QMI request
>  - qcom,xo-cal-data: xo cal offset to be configured in xo trim register.
> +- qcom,coexist-support : should contain eithr "0" or "1" to indicate coex
> +  support by the hardware.
> +- qcom,coexist-gpio-pin : gpio pin number  information to support coex
> +   which will be used by wifi firmware.

What combinations of these 2 properties are valid?

Is qcom,coexist-gpio-pin required for coexist support? If so then it 
alone should be enough to enable/disable coexist.

>  
>  Example (to supply PCI based wifi block details):
>  
> @@ -156,6 +160,8 @@ wifi0: wifi@a00 {
>   qcom,msi_addr = <0x0b006040>;
>   qcom,msi_base = <0x40>;
>   qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
> + qcom,coexist-support = <1>;
> + qcom,coexist-gpio-pin = <0x33>;
>  };
>  
>  Example (to supply wcn3990 SoC wifi block details):
> -- 
> 1.9.1

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 1/2] dt: bindings: add dt entry flag to skip SCM call for msa region

[Rob Herring]

On Mon, Nov 11, 2019 at 09:55:07AM +0530, Govind Singh wrote:
> Add boolean context flag to disable SCM call for statically
> mapped msa region.

Can't this be implied by the compatible string?

> 
> Signed-off-by: Govind Singh 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt  | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 017128394a3e..7ba22918bab7 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -88,6 +88,9 @@ Optional properties:
>   of the host capability QMI request
>  - qcom,xo-cal-data: xo cal offset to be configured in xo trim register.
>  
> +- qcom,msa_fixed_perm: Boolean context flag to disable SCM call for 
> statically
> +mapped msa region.
> +

s/_/-/

>  Example (to supply PCI based wifi block details):
>  
>  In this example, the node is defined as child node of the PCI controller.
> @@ -185,4 +188,5 @@ wifi@1800 {
>   vdd-3.3-ch0-supply = <_l25a_3p3>;
>   memory-region = <_msa_mem>;
>   iommus = <_smmu 0x0040 0x1>;
> + qcom,msa_fixed_perm;
>  };
> -- 
> 2.22.0
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] ath10k: Fix HOST capability QMI incompatibility

[Rob Herring]

On Wed, Jul 24, 2019 at 11:31:08PM -0700, Bjorn Andersson wrote:
> The introduction of 768ec4c012ac ("ath10k: update HOST capability QMI
> message") served the purpose of supporting the new and extended HOST
> capability QMI message.
> 
> But while the new message adds a slew of optional members it changes the
> data type of the "daemon_support" member, which means that older
> versions of the firmware will fail to decode the incoming request
> message.
> 
> There is no way to detect this breakage from Linux and there's no way to
> recover from sending the wrong message (i.e. we can't just try one
> format and then fallback to the other), so a quirk is introduced in
> DeviceTree to indicate to the driver that the firmware requires the 8bit
> version of this message.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 768ec4c012ac ("ath10k: update HOST capability qmi message")
> Signed-off-by: Bjorn Andersson 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt |  6 +

Acked-by: Rob Herring 

>  drivers/net/wireless/ath/ath10k/qmi.c | 13 ---
>  .../net/wireless/ath/ath10k/qmi_wlfw_v01.c| 22 +++
>  .../net/wireless/ath/ath10k/qmi_wlfw_v01.h|  1 +
>  drivers/net/wireless/ath/ath10k/snoc.c| 11 ++
>  drivers/net/wireless/ath/ath10k/snoc.h|  1 +
>  6 files changed, 51 insertions(+), 3 deletions(-)

Re: [PATCH v3 1/2] dt: bindings: add dt entry for XO calibration support

[Rob Herring]

On Mon,  1 Apr 2019 14:49:25 +0530, Govind Singh wrote:
> Add dt binding to get xo calibration data support for wifi rf clock.
> 
> Signed-off-by: Govind Singh 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt: bindings: add dt entry for XO calibration support

[Rob Herring]

On Sat, Mar 02, 2019 at 10:36:34AM +0530, Govind Singh wrote:
> Add dt binding to get xo calibration data support for wifi rf clock.
> 
> Signed-off-by: Govind Singh 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index ae661e65354e..ab8042866e83 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -81,6 +81,7 @@ Optional properties:
>   Definition: Name of external front end module used. Some valid FEM names
>   for example: "microsemi-lx5586", "sky85703-11"
>   and "sky85803" etc.
> +- xo-cal-data: xo cal offset to be configured in xo trim register.

Should have a vendor prefix.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v4 1/3] dt-bindings: net: ath10k: fix node name and device type in qcom ath10k example

[Rob Herring]

On Tue, 11 Dec 2018 21:43:22 +0530, Bhagavathi Perumal S wrote:
> In qcom,ath10k documentation, ath10k is used as node name in the example of
> pci based device. Normally, node name should be class of device and not the
> model name, so fix it to node name "wifi". And remove the property device_type
> pci since only pci bridges should have this property.
> 
> Signed-off-by: Bhagavathi Perumal S 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v4 2/3] dt-bindings: net: ath10k: add new dt entry to identify external FEM

[Rob Herring]

On Tue, Dec 11, 2018 at 09:43:23PM +0530, Bhagavathi Perumal S wrote:
> This adds new dt entry ext-fem-name, it is used by ath10k driver
> to select correct timing parameters and configure it in target wifi hardware.
> The Front End Module(FEM) normally includes tx power amplifier(PA) and
> rx low noise amplifier(LNA). The default timing parameters like tx end to
> PA off timing values were fine tuned for internal FEM used in reference
> design. And these timing values can not be same if ODM modifies hardware
> design with different external FEM. This DT entry helps to choose correct
> timing values in driver if different external FEM hardware used.
> 
> Signed-off-by: Bhagavathi Perumal S 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Please add acks/reviewed-bys when posting new versions.

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3 2/3] dt-bindings: net: ath10k: add new dt entry to identify external FEM

[Rob Herring]

On Tue, 11 Dec 2018 00:01:30 +0530, Bhagavathi Perumal S wrote:
> This adds new dt entry ext-fem-name, it is used by ath10k driver
> to select correct timing parameters and configure it in target wifi hardware.
> The Front End Module(FEM) normally includes tx power amplifier(PA) and
> rx low noise amplifier(LNA). The default timing parameters like tx end to
> PA off timing values were fine tuned for internal FEM used in reference
> design. And these timing values can not be same if ODM modifies hardware
> design with different external FEM. This DT entry helps to choose correct
> timing values in driver if different external FEM hardware used.
> 
> Signed-off-by: Bhagavathi Perumal S 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3 1/3] dt-bindings: net: ath10k: fix node name and device type in qcom ath10k example

[Rob Herring]

On Tue, Dec 11, 2018 at 12:01:29AM +0530, Bhagavathi Perumal S wrote:
> In qcom,ath10k documentation, ath10k is used as node name in the example of
> pci based device. Normally, node name shoud be class of device and not the 
> model

s/shoud/should/

> name, so fix it to node name "wifi". And remove the property device_type pci
> since only pci bridges should have this property.
> 
> Signed-off-by: Bhagavathi Perumal S 
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 2196d1a..ef60f25 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -74,9 +74,8 @@ pci {
>   #address-cells = <3>;
>   device_type = "pci";
>  
> - ath10k@0,0 {
> + wifi@0,0 {
>   reg = <0 0 0 0 0>;
> - device_type = "pci";
>   qcom,ath10k-calibration-data = [ 01 02 03 ... ];
>   };
>   };
> -- 
> 1.9.1
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt: bindings: add new dt entry to indentify external FEM

[Rob Herring]

On Tue, Oct 30, 2018 at 3:41 AM  wrote:
>
> On 2018-10-16 00:54, Rob Herring wrote:
> > On Thu, Oct 04, 2018 at 05:12:43PM +0530, Bhagavathi Perumal S wrote:
> >> This adds new dt entry ext-fem-name, it is used by ath10k driver
> >> to select correct timing parameters and configure it in target wifi
> >> hardware.
> >> The Front End Module(FEM) normally includes tx power amplifier(PA) and
> >> rx low noise amplifier(LNA). The default timing parameters like tx end
> >> to
> >> PA off timing values were fine tuned for internal FEM used in
> >> reference
> >> design. And these timing values can not be same if ODM modifies
> >> hardware
> >> design with different external FEM. This DT entry helps to choose
> >> correct
> >> timing values in driver if different external FEM hardware used.
> >
> > 'dt-bindings: net: ath10k: ...' for the subject please.
> Sure, I will change and send v2 patch.
>
> >
> >>
> >> Signed-off-by: Bhagavathi Perumal S 
> >> ---
> >>  .../bindings/net/wireless/qcom,ath10k.txt  | 22
> >> ++
> >>  1 file changed, 22 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> index 7fd4e8c..fbaf309 100644
> >> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> @@ -56,6 +56,7 @@ Optional properties:
> >>   the length can vary between hw versions.
> >>  - -supply: handle to the regulator device tree node
> >> optional "supply-name" is "vdd-0.8-cx-mx".
> >> +- ext-fem-name: name of external front end module used.
> >
> > What are valid names? What if the OS doesn't recognize the name?
> > Perhaps
> Some valid FEM devices are "microsemi-lx5586", "sky85703-11" and
> "sky85803" etc.
> Currently driver accepts only "microsemi-lx5586", Since this FEM
> requires different timing settings,

Assuming you keep this, then you need to enumerate what are valid
values in the binding. Otherwise, 'ext-fem-name = "rob"' is valid.

> And it can be extended for other FEM devices in future.
> If OS doesn't recognize the name, it uses predefined default timing
> settings.
>
> > this should be a compatible string for the particular module instead?
> > Then it could cover any differences, not just the FEM.
> >
> No, it is specific to FEM device.

You will be better off having either a specific compatible string or
using VID/PID as this is a PCI device. Then you can handle other
differences you may find between h/w versions without a DT change.

> >>
> >>  Example (to supply the calibration data alone):
> >>
> >> @@ -150,3 +151,24 @@ wifi@1800 {
> >> <0 141 0 /* CE11 */ >;
> >>  vdd-0.8-cx-mx-supply = <_l5>;
> >>  };
> >> +
> >> +Example (to supply the external front end module name):
> >> +
> >> +In this example, the front end module is defined as a property of the
> >> ath10k
> >> +device node.
> >
> > Really need a whole new example for 1 property?
> Will add this property in existing example.
>
> >
> >> +
> >> +pci {
> >> +pcie@0 {
> >> +reg = <0 0 0 0 0>;
> >> +#interrupt-cells = <1>;
> >> +#size-cells = <2>;
> >> +#address-cells = <3>;
> >> +device_type = "pci";
> >> +
> >> +ath10k@0,0 {
> >
> > wifi@0,0
> Added in ath10k@0,0 to make consistent with existing property
> "qcom,ath10k-calibration-data" below,
> "

I don't see how that matters.

> pci {
>  pcie@0 {
>  reg = <0 0 0 0 0>;
>  #interrupt-cells = <1>;
>  #size-cells = <2>;
>  #address-cells = <3>;
>  device_type = "pci";
>
>  ath10k@0,0 {
>  reg = <0 0 0 0 0>;
>  device_type = "pci";
>  qcom,ath10k-calibration-data = [ 01 02 03 ... ];
>  };
>  };
> };
> "
>
> If wifi@0,0 is preferable, then I will add new entry "wifi@0,0" and add
> ext-fem-name into it.

Node names are supposed to reflect the class of device, not the model.
See the DT spec for a list.

>
> >
> >> +reg = <0 0 0 0 0>;
> >> +device_type = "pci";

Also, this is wrong. Only PCI bridges should have this property. dtc
will give you a warning on this.

> >> +ext-fem-name = "microsemi-lx5586";
> >> +};
> >> +};
> >> +};
> >> --
> >> 1.9.1
> >>
>
> Thanks, Sorry for the delayed response,
> Bhagavathi Perumal S.

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt: bindings: add new dt entry to indentify external FEM

[Rob Herring]

On Thu, Oct 04, 2018 at 05:12:43PM +0530, Bhagavathi Perumal S wrote:
> This adds new dt entry ext-fem-name, it is used by ath10k driver
> to select correct timing parameters and configure it in target wifi hardware.
> The Front End Module(FEM) normally includes tx power amplifier(PA) and
> rx low noise amplifier(LNA). The default timing parameters like tx end to
> PA off timing values were fine tuned for internal FEM used in reference
> design. And these timing values can not be same if ODM modifies hardware
> design with different external FEM. This DT entry helps to choose correct
> timing values in driver if different external FEM hardware used.

'dt-bindings: net: ath10k: ...' for the subject please.

> 
> Signed-off-by: Bhagavathi Perumal S 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 22 
> ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 7fd4e8c..fbaf309 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -56,6 +56,7 @@ Optional properties:
>the length can vary between hw versions.
>  - -supply: handle to the regulator device tree node
>  optional "supply-name" is "vdd-0.8-cx-mx".
> +- ext-fem-name: name of external front end module used.

What are valid names? What if the OS doesn't recognize the name? Perhaps 
this should be a compatible string for the particular module instead? 
Then it could cover any differences, not just the FEM.

>  
>  Example (to supply the calibration data alone):
>  
> @@ -150,3 +151,24 @@ wifi@1800 {
>  <0 141 0 /* CE11 */ >;
>   vdd-0.8-cx-mx-supply = <_l5>;
>  };
> +
> +Example (to supply the external front end module name):
> +
> +In this example, the front end module is defined as a property of the ath10k
> +device node.

Really need a whole new example for 1 property?

> +
> +pci {
> + pcie@0 {
> + reg = <0 0 0 0 0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> +
> + ath10k@0,0 {

wifi@0,0

> + reg = <0 0 0 0 0>;
> + device_type = "pci";
> + ext-fem-name = "microsemi-lx5586";
> + };
> + };
> +};
> -- 
> 1.9.1
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3 1/3] dt: bindings: add missing dt properties for WCN3990 wifi node

[Rob Herring]

On Wed, 10 Oct 2018 17:22:54 +0530, Govind Singh wrote:
> Add missing optional properties in WCN3990 wifi node.
> 
> Signed-off-by: Govind Singh 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 28 
> --
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 

Reviewed-by: Rob Herring 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 3/4] dt: bindings: add bindings for wifi iommu node

[Rob Herring]

On Fri, Sep 21, 2018 at 02:39:06PM +0530, Govind Singh wrote:
> WCN3990 wifi module can optionally make use of the IOMMU.

Can the other compatibles use IOMMU too?

> Add binding documentation for phandle to the IOMMU and
> the stream id of wifi iommu block.
> 
> Signed-off-by: Govind Singh 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 22dea7d83ee8..07e58008c665 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -59,6 +59,10 @@ Optional properties:
>  - -supply: handle to the regulator device tree node
>  optional "supply-name" are "vdd-0.8-cx-mx",
>  "vdd-1.8-xo", "vdd-1.3-rfa" and "vdd-3.3-ch0".
> +- iommus:
> + Usage: optional
> + Value type: 
> + Definition: A list of phandle and IOMMU specifier pairs.
>  
>  Example (to supply the calibration data alone):
>  
> @@ -157,4 +161,5 @@ wifi@1800 {
>   vdd-1.8-xo-supply = <_l7a_1p8>;
>   vdd-1.3-rfa-supply = <_l17a_1p3>;
>   vdd-3.3-ch0-supply = <_l25a_3p3>;
> + iommus = <_smmu 0x0040 0x1>;
>  };
> -- 
> 2.17.0
> 


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/4] dt: bindings: add missing dt properties for WCN3990 wifi node

[Rob Herring]

On Fri, Sep 21, 2018 at 02:39:04PM +0530, Govind Singh wrote:
> Add missing optional properties in WCN3990 wifi node.
> 
> Signed-off-by: Govind Singh 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt | 22 +--
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 7fd4e8ce4149..22dea7d83ee8 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -37,12 +37,14 @@ Optional properties:
>  - clocks: List of clock specifiers, must contain an entry for each required
>entry in clock-names.
>  - clock-names: Should contain the clock names "wifi_wcss_cmd", 
> "wifi_wcss_ref",
> -   "wifi_wcss_rtc".
> -- interrupts: List of interrupt lines. Must contain an entry
> -   for each entry in the interrupt-names property.
> +   "wifi_wcss_rtc", "cxo_ref_clk_pin", "smmu_aggre2_noc_clk".
> +- interrupts: List of interrupt lines. Must contain interrupt-names property
> +   per entry for "qcom,ath10k", "qcom,ipq4019-wifi" compatible
> +   targets.

It would be clearer to list how many interrupts for each set of 
compatibles.

>  - interrupt-names: Must include the entries for MSI interrupt
>  names ("msi0" to "msi15") and legacy interrupt
> -name ("legacy"),
> +name ("legacy") for "qcom,ath10k", "qcom,ipq4019-wifi"
> +compatible targets.

So no legacy interrupt for wcn3990?

>  - qcom,msi_addr: MSI interrupt address.
>  - qcom,msi_base: Base value to add before writing MSI data into
>   MSI address register.
> @@ -55,7 +57,8 @@ Optional properties:
>  - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
>  - -supply: handle to the regulator device tree node
> -optional "supply-name" is "vdd-0.8-cx-mx".
> +optional "supply-name" are "vdd-0.8-cx-mx",
> +"vdd-1.8-xo", "vdd-1.3-rfa" and "vdd-3.3-ch0".
>  
>  Example (to supply the calibration data alone):
>  
> @@ -133,8 +136,10 @@ wifi@1800 {
>   compatible = "qcom,wcn3990-wifi";
>   reg = <0x1880 0x80>;
>   reg-names = "membase";
> - clocks = <_gcc clk_aggre2_noc_clk>;
> - clock-names = "smmu_aggre2_noc_clk"
> + clocks = <_gcc clk_aggre2_noc_clk>,
> +  <_gcc clk_rf_clk2_pin>;
> + clock-names = "smmu_aggre2_noc_clk",
> +   "cxo_ref_clk_pin";

The binding now says there should be 5 clocks...

>   interrupts =
>  <0 130 0 /* CE0 */ >,
>  <0 131 0 /* CE1 */ >,
> @@ -149,4 +154,7 @@ wifi@1800 {
>  <0 140 0 /* CE10 */ >,
>  <0 141 0 /* CE11 */ >;
>   vdd-0.8-cx-mx-supply = <_l5>;
> + vdd-1.8-xo-supply = <_l7a_1p8>;
> + vdd-1.3-rfa-supply = <_l17a_1p3>;
> + vdd-3.3-ch0-supply = <_l25a_3p3>;
>  };
> -- 
> 2.17.0
> 


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v5 3/6] dt: bindings: add bindings for msa memory region

[Rob Herring]

On Wed, Aug 15, 2018 at 02:56:34PM +0530, Govind Singh wrote:
> Add device tree binding documentation details of msa
> memory region for ath10k qmi client for SDM845/APQ8098
> SoC into "qcom,ath10k.txt".
> 
> Signed-off-by: Govind Singh 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt| 6 ++
>  1 file changed, 6 insertions(+)

Please add acks/reviewed-bys when posting new versions.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v4 3/6] dt: bindings: add bindings for msa memory region

[Rob Herring]

On Mon, Jul 23, 2018 at 06:04:25PM +0530, Govind Singh wrote:
> Add device tree binding documentation details of msa
> memory region for ath10k qmi client for SDM845/APQ8098
> SoC into "qcom,ath10k.txt".
> 
> Signed-off-by: Govind Singh 
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath10k.txt| 6 ++
>  1 file changed, 6 insertions(+)

Reviewed-by: Rob Herring 


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3 3/6] dt: bindings: add bindings for msa memory region

[Rob Herring]

On Fri, Jul 06, 2018 at 02:30:43PM +0530, Govind Singh wrote:
> Add device tree binding documentation details of msa
> memory region for ath10k qmi client for SDM845/APQ8098
> SoC into "qcom,ath10k.txt".
> 
> Signed-off-by: Govind Singh 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt   | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 7fd4e8ce4149..87489054aea5 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -57,6 +57,16 @@ Optional properties:
>  - -supply: handle to the regulator device tree node
>  optional "supply-name" is "vdd-0.8-cx-mx".
>  
> += SUBNODES:
> +wcn3990-wifi node may contain one subnode, named "msa" representing
> +the fixed msa memory regions used by the wifi firmware running in Q6.
> +This sub-node must contain:

Why do you need a sub-node? Just add memory-region property.

> +
> +- memory-region:
> + Usage: required
> + Value type: 
> + Definition: reference to the reserved-memory for the region
> +
>  Example (to supply the calibration data alone):
>  
>  In this example, the node is defined as child node of the PCI controller.
> @@ -149,4 +159,7 @@ wifi@1800 {
>  <0 140 0 /* CE10 */ >,
>  <0 141 0 /* CE11 */ >;
>   vdd-0.8-cx-mx-supply = <_l5>;
> + msa {
> + memory-region = <_msa_mem>;
> + };
>  };
> -- 
> 2.17.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 13/13] dt: bindings: add bindings for wcn3990 wifi block

[Rob Herring]

On Tue, Apr 10, 2018 at 10:19:46PM +0530, Govind Singh wrote:
> Add device tree binding documentation details for wcn3990
> wifi block present in Qualcomm SDM845/APQ8098 SoC into
> "qcom,ath10k.txt".
> 
> Signed-off-by: Govind Singh <govi...@codeaurora.org>
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)

One nit, otherwise:

Reviewed-by: Rob Herring <r...@kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 3d2a031..34e4f98 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - compatible: Should be one of the following:
>   * "qcom,ath10k"
>   * "qcom,ipq4019-wifi"
> + * "qcom,wcn3990-wifi"
>  
>  PCI based devices uses compatible string "qcom,ath10k" and takes calibration
>  data along with board specific data via "qcom,ath10k-calibration-data".
> @@ -18,8 +19,12 @@ In general, entry "qcom,ath10k-pre-calibration-data" and
>  "qcom,ath10k-calibration-data" conflict with each other and only one
>  can be provided per device.
>  
> +SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
> +
>  Optional properties:
>  - reg: Address and length of the register set for the device.
> +- reg-names: Must include the list of following reg names,
> +  "membase"
>  - resets: Must contain an entry for each entry in reset-names.
>See ../reset/reseti.txt for details.
>  - reset-names: Must include the list of following reset names,
> @@ -49,6 +54,8 @@ Optional properties:
>hw versions.
>  - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- -supply: handle to the regulator device tree node
> +optional "supply-name" is "vdd-0.8-cx-mx".
>  
>  Example (to supply the calibration data alone):
>  
> @@ -119,3 +126,27 @@ wifi0: wifi@a00 {
>   qcom,msi_base = <0x40>;
>   qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
>  };
> +
> +Example (to supply wcn3990 SoC wifi block details):
> +
> +qcom,wifi@1800 {

wifi@...

> + compatible = "qcom,wcn3990-wifi";
> + reg = <0x1880 0x80>;
> + reg-names = "membase";
> + clocks = <_gcc clk_aggre2_noc_clk>;
> + clock-names = "smmu_aggre2_noc_clk"
> + interrupts =
> +<0 130 0 /* CE0 */ >,
> +<0 131 0 /* CE1 */ >,
> +<0 132 0 /* CE2 */ >,
> +<0 133 0 /* CE3 */ >,
> +<0 134 0 /* CE4 */ >,
> +<0 135 0 /* CE5 */ >,
> +<0 136 0 /* CE6 */ >,
> +<0 137 0 /* CE7 */ >,
> +<0 138 0 /* CE8 */ >,
> +<0 139 0 /* CE9 */ >,
> +<0 140 0 /* CE10 */ >,
> +<0 141 0 /* CE11 */ >;
> + vdd-0.8-cx-mx-supply = <_l5>;
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] dt: bindings: add bindings for wcn3990 wifi block

[Rob Herring]

On Fri, Feb 16, 2018 at 10:13:48AM +0530, Govind Singh wrote:
> Add device tree binding documentation details for wcn3990
> wifi block present in Qualcomm SDM845/APQ8098 SoC into
> "qcom,ath10k.txt".
> 
> Signed-off-by: Govind Singh 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 35 
> ++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 3d2a031..e34d8f8 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - compatible: Should be one of the following:
>   * "qcom,ath10k"
>   * "qcom,ipq4019-wifi"
> + * "qcom,wcn3990-wifi"
>  
>  PCI based devices uses compatible string "qcom,ath10k" and takes calibration
>  data along with board specific data via "qcom,ath10k-calibration-data".
> @@ -18,8 +19,11 @@ In general, entry "qcom,ath10k-pre-calibration-data" and
>  "qcom,ath10k-calibration-data" conflict with each other and only one
>  can be provided per device.
>  
> +SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
> +
>  Optional properties:
>  - reg: Address and length of the register set for the device.
> +- reg-names: Names of the memory regions defined in reg entry.

You must define what the names are and how many (so reg needs updating 
too if there is more than 1).

Though with only 1 -names, it is kind of pointless.


>  - resets: Must contain an entry for each entry in reset-names.
>See ../reset/reseti.txt for details.
>  - reset-names: Must include the list of following reset names,
> @@ -49,6 +53,12 @@ Optional properties:
>hw versions.
>  - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- qcom,-supply: handle to the regulator device tree node
> +optional "supply-name" is "vdd-0.8-cx-mx".

You can drop the qcom prefix. Just name this "vdd-0.8-cx-mx-supply".

> +- qcom,-config: Specifies voltage levels for supply. Should be
> +   specified in pairs (min, max), units uV.  There can
> +be optional load in uA and Regulator settle delay in
> +uS.

We have standard regulator properties for this I think.

>  
>  Example (to supply the calibration data alone):
>  
> @@ -119,3 +129,28 @@ wifi0: wifi@a00 {
>   qcom,msi_base = <0x40>;
>   qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
>  };
> +
> +Example (to supply wcn3990 SoC wifi block details):
> +
> +qcom,msm_ath10k@1800 {

wifi@...

> + compatible = "qcom,wcn3990-wifi";
> + reg = <0x1880 0x80>;
> + reg-names = "membase";
> + clocks = <_gcc clk_aggre2_noc_clk>;
> + clock-names = "smmu_aggre2_noc_clk"
> + interrupts =
> +<0 130 0 /* CE0 */ >,
> +<0 131 0 /* CE1 */ >,
> +<0 132 0 /* CE2 */ >,
> +<0 133 0 /* CE3 */ >,
> +<0 134 0 /* CE4 */ >,
> +<0 135 0 /* CE5 */ >,
> +<0 136 0 /* CE6 */ >,
> +<0 137 0 /* CE7 */ >,
> +<0 138 0 /* CE8 */ >,
> +<0 139 0 /* CE9 */ >,
> +<0 140 0 /* CE10 */ >,
> +<0 141 0 /* CE11 */ >;
> + qcom,vdd-0.8-cx-mx-supply = <_l5>;
> + qcom,vdd-0.8-cx-mx-config = <80 80 2400 1000>;
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2 1/2] dt: bindings: add new dt entry for ath10k calibration variant

[Rob Herring]

On Fri, Dec 08, 2017 at 11:37:41AM +0100, Sven Eckelmann wrote:
> The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
> board data file on QCA4019 based devices. Multiple different boards share
> the same values. Only the original reference designs can currently be
> identified and loaded from the board-2.bin. But these will not result in
> the correct calibration data when combined with the pre-calibration data
> from the device.
> 
> An additional "variant" information has to be provided (via SMBIOS or DT)
> to select the correct board data for a design which was modified by an ODM.
> 
> Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring <r...@kernel.org>  

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

[Rob Herring]

On Tue, Mar 21, 2017 at 9:33 AM, Sven Eckelmann
<sven.eckelm...@openmesh.com> wrote:
> On Dienstag, 21. März 2017 08:00:34 CET Rob Herring wrote:
> [...]
>> > It would then up with something like this as compatibility string:
>> >
>> >  * qcom,ipq4019-wifi-asus-rt-ac58u
>> >  * qcom,ipq4019-wifi-fritzbox-4040
>> >  * qcom,ipq4019-wifi-netgear-whatever
>> >  * qcom,ipq4019-wifi-openmesh-i-have-no-idea
>> >  * ...
>>
>> Are these all the same board design or variations? In the latter case,
>> you should have specific compatibles anyway. Now if the variants are
>> the same hardware, but different configurations say for different
>> regions or something, then I'd say a separate property is fine.
>>
>> We already have a "firmware-name" property. Would that work for you?
>
> Hm, maybe we should specify some names better:
>
> "qcom,ipq4019-wifi" == compatibility string for WiFi hardware inside the SoC.
> It is the one which ath10k supports on the Atheros Host Bus (ahb) of the
> QCA4019.
>
> The ath10k driver will use the information from these nodes to initialize the
> device. It will basically:
>
> 1. load a firmware(-5).bin from /lib/firmware/ath10k/QCA4019/hw1.0/
> 2. load the pre-cal (aka first part of calibration) data from
>/lib/firmware/ath10k/pre-cal-*
> 3. do some firmware magic to identify the reference design
> 4. load board data "files" (BDF) for this reference design from
> /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
> 5. send the BDF data to the firmware to let it compute the final calibration
>data
> 6. start the actual wifi stuff
>
> The IPQ4018/4019 SoC doesn't contain the actual RF parts. There are a couple
> of reference designs (SoC+RF parts) from QCA which got official numbers. These
> numbers identify the BDFs inside the board-2.bin. And the board-2.bin is not
> the firmware - it is a container for multiple BDFs.
>
>
> To summarize:
>
>  * pre-cal is some data stored in a special partition of the devices and will
>not be overwritten on updates
>  * board-2.bin are multiple BDF files containing the second part of the
>calibration data
>  * pre-cal + BDF (+ some OTP stuff) are getting combined to form the complete
>calibration data
>
> Asus RT-AC58U, Fritzbox 4040 and ZyXEL NBG6617 are products based on the same
> reference design. But of course, some (all?) fiddled around with the RF parts
> and therefore require special BDFs. They still use the same SoC and require
> that the closed source ath10k firmware behaves like on the official reference
> designs. Only the BDFs have to be different.

Is this always the case? There's never some variation beyond the
reference design that a BDF difference can't handle?

> So you could say that the wifi-chip hardware (part of the QCA4018/4019 SoC) is
> the same between these different products. But the hardware around the SoC is
> different and therefore requires a different "configuration"/calibration for
> the surrounding RF hardware. It is not a perfect match for your "separate
> property is fine" compromise. Maybe you still meant this - I let you decide.
>
>
> This is not only a problem on QCA4019 but also for other devices supported by
> ath10k. Waldemar Rymarkiewicz introduced the concept of BDF variants for
> this [1] and implemented the support for SMBIOS. The variant string (generated
> from the SMBIOS data) is then used by ath10k when it searches for the correct
> BDFs in the board-2.bin. Kalle Valo suggested to use the same mechanism for
> QCA401X based boards (which don't use SMBIOS).
>
> The "qcom,ath10k-calibration-variant" is now the (more or less) equivalent of
> the SMBIOS entry - but for device tree users. Let us assume that the variant
> string would be "RT-AC58U" for the Asus RT-AC58U and the first wifi device
> (bmi-board-id=16) gets initialized [2]. Then the step 4 would get splitted in
> following steps:
>
> 4.1. Get the the qcom,ath10k-calibration-variant content
> 4.2. jump to 4.5. when there is no qcom,ath10k-calibration-variant
> 4.3. calculate BDF search name with variant string
>  "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U"
> 4.4. load BDF and when found, jump to 5.
> 4.5. calculate BDF search name without variant string
>  "bus=ahb,bmi-chip-id=0,bmi-board-id=16"
> 4.6. load the BDF
>
>
> There would be no changes in ath10k when adding a new BDF calibration variant
> using qcom,ath10k-calibration-variant. Only the device tree node would have to
> be updated:
>
>  * device tree (simplified):
> / {
>   model = &qu

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

[Rob Herring]

On Mon, Mar 20, 2017 at 11:28 AM, Sven Eckelmann
<sven.eckelm...@openmesh.com> wrote:
> On Montag, 20. März 2017 10:07:33 CET Rob Herring wrote:
>> On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote:
>> > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
>> > board data file on QCA4019 based devices. Multiple different boards share
>> > the same values. Only the original reference designs can currently be
>> > identified and loaded from the board-2.bin. But these will not result in
>> > the correct calibration data when combined with the pre-calibration data
>> > from the device.
>> >
>> > An additional "variant" information has to be provided (via SMBIOS or DT)
>> > to select the correct board data for a design which was modified by an ODM.
>> >
>> > Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
>> > ---
>> > Since RFC:
>> >
>> >  - Split patch in DT doc and ath10k part (thanks Christian Lamparter)
>> >  - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with
>> >more generic "device specific ids"
>> > ---
>> >  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
>> > b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> > index 74d7f0af209c..3d2a031217da 100644
>> > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>> > @@ -41,6 +41,9 @@ Optional properties:
>> >  - qcom,msi_addr: MSI interrupt address.
>> >  - qcom,msi_base: Base value to add before writing MSI data into
>> > MSI address register.
>> > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
>> > +  variant list with the same bus and device
>> > +  specific ids
>>
>> Sounds like you should use a more specific compatible string.
>
> Hm, this would require that each calibration data has an own compatibility
> string - which then has to be supported by ath10k, right? Doesn't sound like
> it would work well when each vendor (with an own calibration variant) would
> have to modify ath10k to get it working. This sounds especially odd because
> nothing else in ath10k has to be changed. Only the board data files which will
> be selected by ath10k are different on these devices.
>
> It would then up with something like this as compatibility string:
>
>  * qcom,ipq4019-wifi-asus-rt-ac58u
>  * qcom,ipq4019-wifi-fritzbox-4040
>  * qcom,ipq4019-wifi-netgear-whatever
>  * qcom,ipq4019-wifi-openmesh-i-have-no-idea
>  * ...

Are these all the same board design or variations? In the latter case,
you should have specific compatibles anyway. Now if the variants are
the same hardware, but different configurations say for different
regions or something, then I'd say a separate property is fine.

We already have a "firmware-name" property. Would that work for you?

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

[Rob Herring]

On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote:
> The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
> board data file on QCA4019 based devices. Multiple different boards share
> the same values. Only the original reference designs can currently be
> identified and loaded from the board-2.bin. But these will not result in
> the correct calibration data when combined with the pre-calibration data
> from the device.
> 
> An additional "variant" information has to be provided (via SMBIOS or DT)
> to select the correct board data for a design which was modified by an ODM.
> 
> Signed-off-by: Sven Eckelmann 
> ---
> Since RFC:
> 
>  - Split patch in DT doc and ath10k part (thanks Christian Lamparter)
>  - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with
>more generic "device specific ids"
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 74d7f0af209c..3d2a031217da 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -41,6 +41,9 @@ Optional properties:
>  - qcom,msi_addr: MSI interrupt address.
>  - qcom,msi_base: Base value to add before writing MSI data into
>   MSI address register.
> +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
> +variant list with the same bus and device
> +specific ids

Sounds like you should use a more specific compatible string.

>  - qcom,ath10k-calibration-data : calibration data + board specific data
>as an array, the length can vary between
>hw versions.
> -- 
> 2.11.0
> 

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCHv2 3/4] dt: bindings: add new dt entry for BTCOEX feature in qcom,ath10k.txt

[Rob Herring]

On Thu, Nov 17, 2016 at 05:14:23PM +0530, c_tr...@qti.qualcomm.com wrote:
> From: Tamizh chelvam 
> 
> There two things done in this patch.
> 
> 1) 'btcoex_support' flag for BTCOEX feature support by the hardware.
> 2) 'wlan_btcoex_gpio' is used to fill wlan priority pin number for
>BTCOEX priority feature support.
> 
> Signed-off-by: Tamizh chelvam 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 74d7f0a..08150e2d 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -46,6 +46,10 @@ Optional properties:
>hw versions.
>  - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- btcoex_support  : should contain eithr "0" or "1" to indicate btcoex
> + support by the hardware.

This is BT coexistence? Make this boolean and n

> +- btcoex_gpio_pin :  btcoex gpio pin number for the device which
> +  supports BTCOEX.

This is a pin number on the chip, not any pin number Linux GPIO subsys 
cares about, right? Is there a connection to the host too, or this is 
internal between BT and WiFi?

Do you really need 2 properties? Does supporting this feature require 
the GPIO? If so, then the first property is redundant.

Needs vendor prefix and don't use '_'. Should be something like 
'qcom,bt-coexist-gpio-pin'.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt

[Rob Herring]

On Thu, Mar 10, 2016 at 03:42:04PM +0530, Raja Mani wrote:
> There two things done in this patch,
> 
> 1) Existing device tree entry 'qcom,ath10k-calibration-data' carries
>not only calibration data, it carries board specific data too.
>So, make appropriate update in doc.
> 
> 2) ipq4019 wifi needs new devie tree entry to carry calibration
>data alone (called pre cal data, it doesn't include any other info).
>Using 'qcom,ath10k-calibration-data' for ipq4019 would alter
>the purpose of it. Hence, add new device tree entry called
>'qcom,ath10k-pre-calibration-data' to carry only pre calibration data.
> 
> Signed-off-by: Raja Mani <rm...@qti.qualcomm.com>
> ---
> 
> Below patches covers the corresponding changes in the ath10k driver.
> It's posted separately to ath10k and linux-wireless mailing list.

Generally the series should be posted together. The rest should not be 
merged until this patch is accepted.

> 
>   1) ath10k: pass cal data location as an argument to 
> ath10k_download_cal_{file|dt}
>   2) ath10k: move cal data len to hw_params
>   3) ath10k: incorporate qca4019 cal data download sequence
> 
>  .../bindings/net/wireless/qcom,ath10k.txt  | 23 
> +++++++---
>  1 file changed, 16 insertions(+), 7 deletions(-)

Acked-by: Rob Herring <r...@kernel.org>

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v3] dt: bindings: add bindings for ipq4019 wifi block

[Rob Herring]

On Wed, Jan 13, 2016 at 11:26:44AM +0530, Raja Mani wrote:
> Add device tree binding documentation details for wifi block present
> in Qualcomm IPQ4019 SoC into "qcom,ath10k.txt".
> 
> Right now, ath10k wireless driver has support for PCI based wlan devices.
> There is a plan to extend ath10k driver to support wifi devices which are
> connected over AHB as well (enumeration will happen via device tree node).
> For AHB based devices (ie, ipq4019), all wifi properties are supplied via
> device tree (including irq, reg addr, cal data,etc).
> 
> Signed-off-by: Raja Mani <rm...@qti.qualcomm.com>
> ---
> v3 changes:
>   - Removed core-id - [Rob]
>   - Documented which compatible string corresponds to pci devices
> and which corresponds to ahb devices. - [Rob]
> 
> v2 changes:
>  - Improved "core-id" description - [Rob]
>  - Removed "status" documentation - [Rob]
>  - Added description which properties are applicable
>for ahb and which are applicable for pci devices - [Rob]
>  - Improved commit msg to explain the context.
>  - Renamed "qca,msi_addr" to "qcom,msi_addr" and
>"qca,msi_base" to "qcom,msi_base" to follow uniformity.
> 
>  .../bindings/net/wireless/qcom,ath10k.txt  | 89 
> --
>  1 file changed, 84 insertions(+), 5 deletions(-)

A few typos, otherwise:

Acked-by: Rob Herring <r...@kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index edefc26..bf8c0f8c 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -1,17 +1,46 @@
>  * Qualcomm Atheros ath10k wireless devices
>  
> -For ath10k devices the calibration data can be provided through Device
> -Tree. The node is a child node of the PCI controller.
> -
>  Required properties:
> --compatible : Should be "qcom,ath10k"
> +- compatible: Should be one of the following:
> + * "qcom,ath10k"
> + * "qcom,ipq4019-wifi"
> +
> +PCI based devices uses compatible string "qcom,ath10k" and takes only
> +calibration data via "qcom,ath10k-calibration-data". Reset of the properties

s/Reset/Rest/

> +are not applicable for PCI based devices.
> +
> +AHB based devices (ie, ipq4019) uses compatible string "qcom,ipq4019-wifi"

s/ie,/i.e./

> +and also uses most of the properties defined in this doc.

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] dt: bindings: add bindings for ipq4019 wifi block

[Rob Herring]

On Wed, Dec 30, 2015 at 11:41 PM, Raja Mani <rm...@qti.qualcomm.com> wrote:
>
> On Wednesday 30 December 2015 10:05 PM, Rob Herring wrote:
>>
>> On Wed, Dec 23, 2015 at 11:05:15AM +0530, Raja Mani wrote:
>>>
>>> Add device tree binding documentation details for wifi block present
>>> in Qualcomm IPQ4019 SoC into qcom,ath10k.txt.
>>>
>>> Signed-off-by: Raja Mani <rm...@qti.qualcomm.com>
>>> ---
>>>   .../bindings/net/wireless/qcom,ath10k.txt  | 87
>>> --
>>>   1 file changed, 82 insertions(+), 5 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>>> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>>> index edefc26..ffd0742 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
>>> @@ -1,17 +1,42 @@
>>>   * Qualcomm Atheros ath10k wireless devices
>>>
>>> -For ath10k devices the calibration data can be provided through Device
>>> -Tree. The node is a child node of the PCI controller.
>>
>>
>> So it is now not a PCI device?
>
>
> Right now, ath10k wireless driver has support for PCI devices. There is
> a plan to extend ath10k driver to support wifi devices which are connected
> over AHB as well (enumeration will happen via device tree node).
>
> Qualcomm IPQ4019 SoC has two inbuilt wifi block which are connected over AHB
> bus (not connected over PCI bus) and also has one external PCI
> slot where we can connect standalone wifi PCI devices.
>
> In future, ath10k would support both PCI and AHB. For PCI based
> devices, only calibration data is supplied via device tree. For AHB
> based devices (ie, ipq4019), all wifi properties are supplied
> via device tree (including irq, reg addr, cal data,etc).

Put this information in the binding. It is not clear and you seem to
be removing PCI information.

>>> -
>>>   Required properties:
>>> --compatible : Should be "qcom,ath10k"
>>> +- compatible: Should be one of the following:
>>> +   * "qcom,ath10k"
>>> +   * "qcom,ipq4019-wifi"
>>
>>
>> One is a standalone PCI device and one is embedded block in an SOC?
>
>
> Yes, it's possible to have this combination (one in SoC + one in
> standalone PCI device in the same platform).
>
>> These should be more separated as all these new properties would only
>> apply in the latter case.
>
>
> Sorry, i didn't get this point. I mentioned it under optional
> properties. Whichever properties applies to particular wifi, only
> those parameters are needed. For example, for PCI based devices,
> only calibration data is needed, for AHB based devices most the
> properties are needed.
>
> Is it fine if add below text some thing like this ?
>
> "only "qcom,ath10k-calibration-data" is applicable for PCI based
> devices, rest of the members are applicable only for AHB based
> devices"

Yes, but you need to explain in terms of compatible strings. Which
compatible strings correspond to PCI devices.

>>>   Optional properties:
>>> +- reg: Address and length of the register set for the device.
>>> +- core-id: Core number associated to the device.
>>
>>
>> This needs a better explanation.
>
>
> Sure, Let me add below text in next version.
>
> "core-id is numeric number associated to the wifi block.
>  For example, 0 means first block, 1 means second wifi block,etc."

Are the blocks the same? If not, then use different compatible
strings. Otherwise doesn't the reg property identify which block is
which? Or some other property? Different freq bands? We generally
don't allow indexes like this in the DT, so I need to understand how
you use this.

Rob

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k