Re: [PATCH 2/2] wifi: ath11k: use unique QRTR instance ID

From: Kalle Valo <kvalo@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Robert Marko <robimarko@gmail.com>,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, gregkh@linuxfoundation.org, elder@linaro.org,
	hemantk@codeaurora.org, quic_jhugo@quicinc.com,
	quic_qianyu@quicinc.com, bbhatt@codeaurora.org,
	mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org,
	ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, ansuelsmth@gmail.com
Subject: Re: [PATCH 2/2] wifi: ath11k: use unique QRTR instance ID
Date: Tue, 22 Nov 2022 13:26:24 +0200	[thread overview]
Message-ID: <877czn8c2n.fsf@kernel.org> (raw)
In-Reply-To: <87cz9xcqbd.fsf@kernel.org> (Kalle Valo's message of "Tue, 08 Nov 2022 19:24:22 +0200")

Kalle Valo <kvalo@kernel.org> writes:

> Manivannan Sadhasivam <mani@kernel.org> writes:
>
>> On Sat, Nov 05, 2022 at 08:49:43PM +0100, Robert Marko wrote:
>>> Currently, trying to use AHB + PCI/MHI cards or multiple PCI/MHI cards
>>> will cause a clash in the QRTR instance node ID and prevent the driver
>>> from talking via QMI to the card and thus initializing it with:
>>> [    9.836329] ath11k c000000.wifi: host capability request failed: 1 90
>>> [    9.842047] ath11k c000000.wifi: failed to send qmi host cap: -22
>>> 
>>
>> There is still an outstanding issue where you cannot connect two WLAN modules
>> with same node id.
>>
>>> So, in order to allow for this combination of cards, especially AHB + PCI
>>> cards like IPQ8074 + QCN9074 (Used by me and tested on) set the desired
>>> QRTR instance ID offset by calculating a unique one based on PCI domain
>>> and bus ID-s and writing it to bits 7-0 of BHI_ERRDBG2 MHI register by
>>> using the SBL state callback that is added as part of the series.
>>> We also have to make sure that new QRTR offset is added on top of the
>>> default QRTR instance ID-s that are currently used in the driver.
>>> 
>>
>> Register BHI_ERRDBG2 is listed as Read only from Host as per the BHI spec.
>> So I'm not sure if this solution is going to work on all ath11k supported
>> chipsets.
>>
>> Kalle, can you confirm?
>
> I can't look at this in detail right now, but hopefully in few days.
> I'll get back to you.

The solution we have been thinking internally would not use
MHI_CB_EE_SBL_MODE at all, it's not clear for me yet why the mode was
not needed in our solution. Maybe there are firmware modifications? I
think it's best that we submit our proposal as well, then we can then
compare implementations and see what is the best course of action.

But it looks that not all ath11k hardware and firmware releases support
this feature, we would need meta data information from the firmware to
detect it. I am working on adding firmware meta data support[1] to
ath11k, will post patches for that "soon".

[1] similar to firmware-N.bin support ath10k has

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches