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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200929190817.GA968845@bogus>
Date:   Tue, 29 Sep 2020 14:08:17 -0500
From:   Rob Herring <robh@...nel.org>
To:     Amit Pundir <amit.pundir@...aro.org>
Cc:     Kalle Valo <kvalo@...eaurora.org>,
        David S Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Jeffrey Hugo <jeffrey.l.hugo@...il.com>,
        John Stultz <john.stultz@...aro.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Konrad Dybcio <konradybcio@...il.com>,
        ath10k@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap
 QMI requests

On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote:
> 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.

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.

Rob