Re: [PATCH 5/6] qtnfmac: add support for PTA configuration

[Arend van Spriel <arend.vanspriel@broadcom.com>]

On 8/5/2018 5:22 PM, Sergey Matyukevich wrote:
>>>>>> Implement support for PTA (Packet Traffic Arbitration) configuration.
>>>>>> The PTA mechanism is used to coordinate sharing of the medium between
>>>>>> WiFi and other 2.4 wireless networks, e.g. Bluetooth or ZigBee.
>>>>>>
>>>>>> This patch implements core infrastructure and vendor specific commands
>>>>>> to control PTA functionality in firmware.
>>>>>
>>>>> And no description of the actual interface which would have helped with
>>>>> the review.
>>>>>
>>>>> Anyway, the vendor commands are pain and they just make me grumpy. The
>>>>> original idea was that upstream drivers should not support them at all,
>>>>> later we flexed the rules so that low level hardware specific interfaces
>>>>> might be ok, for example we added one in wil6210.
>>>>>
>>>>> If I would even consider applying a patch which adds a vendor command it
>>>>> needs a really good commit log with a proper description of the actual
>>>>> interface and good justifications why a generic nl80211 command won't
>>>>> work. I don't see anything even remotely close here.
>>>>>
>>>>> Sorry for being grumpy, I just hate these vendor commands. Especially
>>>>> when I see that a generic nl80211 command has not even be consired at
>>>>> all.
>>>>
>>>> For what it is worth, looking at part of the patch:
>>>>
>>>> +/**
>>>> + * enum qlink_pta_mode - Packet Traffic Arbiter operating modes
>>>> + *
>>>> + * @QLINK_PTA_MODE_DISABLED: PTA is disabled
>>>> + * @QLINK_PTA_MODE_2_WIRE: enable PTA 2-wire mode
>>>> + */
>>>> +enum qlink_pta_mode {
>>>> +       QLINK_PTA_MODE_DISABLED = 0,
>>>> +       QLINK_PTA_MODE_2_WIRE = 2
>>>> +};
>>>> +
>>>>
>>>> it smells very much like low-level btcoex. The question is whether this
>>>> needs to be conveyed from user-space or should these be device
>>>> configuration, eg. like DT properties.
>>>
>>> Hello Arend,
>>>
>>> Yes, this is some kind of low-level BT coexistence mechanism, when WiFi and
>>> BT cards coordinate access to wireless media in 2.4G using gpio lines.
>>> Those lines connect WiFi and BT cards directly w/o host mediation.
>>
>> Right.
>>
>>> As for DT properties, the qustion still remains the same: how to propagate
>>> those settings to WiFi card. AFAIK there is no 'standard' interface for
>>> this kind of things. So using vendor commands looked like the only option.
>>
>> So DT properties are available to the kernel so it is just between
>> device driver and wifi card. There is no involvement with user-space needed.
>
> Ok, makes sense. But IIUC this approach with DT
> does not cover PCIe/USB wireless cards.

It can cover any device in the system regardless type of host interface. 
For example in the ath10k bindings document [1] you see:

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 ... ];
		};
	};
};

Regards,
Arend

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt?h=linux-4.17.y