On Thu, Nov 17, 2016 at 05:14:23PM +0530, c_traja@xxxxxxxxxxxxxxxx wrote:From: Tamizh chelvam <tamizhchelvam@xxxxxxxxxxxxxx>
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 <tamizhchelvam@xxxxxxxxxxxxxx>
---
.../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?
Target/driver can hard copy this gpio pin for some chipsets and there we will need btcoex_support flag to find the btcoex support.
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 likeSure I'll update this and send in v3 patch
'qcom,bt-coexist-gpio-pin'.