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

[Krzysztof Kozlowski]

On 04/03/2024 21:21, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 22:17, Conor Dooley <conor at kernel.org> wrote:
>>
>> On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
>>> On Mon, 4 Mar 2024 at 21:46, Conor Dooley <conor at kernel.org> wrote:
>>>> On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
>>>>> On Mon, 4 Mar 2024 at 21:34, Conor Dooley <conor at kernel.org> wrote:
>>>>>> On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
>>
>>>>>>> Thus, anyone porting an msm8998 board to mainline would automatically
>>>>>>> get the work-around, without having to hunt down the feature bit,
>>>>>>> and tweak the FW files.
>>>>>>
>>>>>> How come the root node comes into this, don't you have a soc-specific
>>>>>> compatible for the integration on this SoC?
>>>>>
>>>>> No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
>>>>
>>>> Suitability of either fix aside, can you explain this to me? Is the "WiFi
>>>> SoC" accessible from the "main SoC" at a regular MMIO address? The
>>>> "ath10k" compatible says it is SDIO-based & the other two compatibles
>>>> seem to be MMIO.
>>>
>>> Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO.
>>
>> Thanks.
>>
>> A SoC-specific compatible sounds like it would be suitable in that case
>> then, to deal with integration quirks for that specific SoC? I usually
>> leave the ins and outs of these qcom SoCs to Krzysztof, but I can't help
>> but wanna know what the justification is here for not using one.
> 
> We can probably start with "historically established" here. From the
> hardware point of view msm8998, sdm845 and several other chipsets use
> a variant of the same wcn3990 WiFi+BT chip. The actual issue is in the
> DSP firmware, so it can be handled via the firmware-related means.
> 

The WiFi+BT chips are separate products, so they are not usually
considered part of the SoC, even though they can be integrated into the
SoC like here. I guess correct approach would be to add SoC-specific
compatible for them.

Best regards,
Krzysztof