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

Bjorn Andersson [off-list ref] writes:

On Tue 03 Nov 01:48 CST 2020, Amit Pundir wrote:

quoted

Hi Rob, Bjorn, Kalle,

On Thu, 29 Oct 2020 at 19:10, Bjorn Andersson
[off-list ref] wrote:

quoted

On Tue 29 Sep 14:08 CDT 2020, Rob Herring wrote:

quoted

On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote:

quoted

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.

Yes and that's not good. But I looked at somehow derive this from
firmware version numbers etc and it's not working out, so I'm out of
ideas for alternatives.

quoted

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.

Unfortunately the firmware versions I've hit this problem on has gone
belly up when receiving this request, that's why I asked Amit to add a
flag to skip it.

So what is next for this DT quirk?

Rob, we still have this problem and we've not come up with any way to
determine in runtime that we need to skip this part of the
initialization.

This is firmware version specific, right? There's also enum
ath10k_fw_features which is embedded within firmware-N.bin, we could add
a new flag there. But that means that a correct firmware-N.bin is needed
for each firmware version, not sure if that would work out. Just
throwing out ideas here.

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

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

Hi Kalle,

On Mon, 7 Dec 2020 at 22:25, Kalle Valo [off-list ref] wrote:

This is firmware version specific, right? There's also enum
ath10k_fw_features which is embedded within firmware-N.bin, we could add
a new flag there. But that means that a correct firmware-N.bin is needed
for each firmware version, not sure if that would work out. Just
throwing out ideas here.

Apologies for this late reply. I was out for a while.

If by that (the firmware version) you mean "QC_IMAGE_VERSION_STRING",
then that may be a bit tricky. Pocophone F1 use the same firmware
family version (WLAN.HL.2.0.XXX), used by Dragonboard 845c (which has
Wi-Fi working upstream).

Regards,
Amit Pundir

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

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