netdev - 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] [day] [month] [year] [list]

Message-ID: <CAMi1Hd2g68U8LVng2+RmhD+zFLqW8vcHS54FvaKxNF+BMs_tZg@mail.gmail.com>
Date:   Thu, 20 May 2021 17:17:52 +0530
From:   Amit Pundir <amit.pundir@...aro.org>
To:     Kalle Valo <kvalo@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh@...nel.org>
Cc:     Jeffrey Hugo <jeffrey.l.hugo@...il.com>, netdev@...r.kernel.org,
        linux-wireless@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>,
        ath10k <ath10k@...ts.infradead.org>,
        Konrad Dybcio <konradybcio@...il.com>,
        dt <devicetree@...r.kernel.org>,
        David S Miller <davem@...emloft.net>,
        John Stultz <john.stultz@...aro.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests

Hi,

Reviving this old thread again, to check if there are still any hopes
of landing this patch upstream.

Based on the feedback I have got so far, there are no easy way to skip
this part of the initialization at runtime. Bjorn and Kalle discussed
the possibility of creating device specific firmware-N.bin firmware
file but that would mean firmware-N.bin has to be loaded from the
device-specific directory along with wlanmdsp.bin. And ideally making
ath10k/ath11k in-charge of firmware loading, but there doesn't seem to
be a consensus on this either(?)

Regards,
Amit Pundir


On Tue, 9 Feb 2021 at 13:41, Kalle Valo <kvalo@...eaurora.org> wrote:
>
> Bjorn Andersson <bjorn.andersson@...aro.org> writes:
>
> > On Mon 08 Feb 11:21 CST 2021, Kalle Valo wrote:
> >
> >> Amit Pundir <amit.pundir@...aro.org> writes:
> >>
> >> > Hi Kalle,
> >> >
> >> > On Mon, 7 Dec 2020 at 22:25, Kalle Valo <kvalo@...eaurora.org> 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.
> >>
> >> No worries.
> >>
> >> > 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).
> >>
> >> I'm meaning the ath10k firmware meta data we have in firmware-N.bin
> >> (N=2,3,4...) file. A quick summary:
> >>
> >> Every ath10k firmware release should have firmware-N.bin. The file is
> >> created with this tool:
> >>
> >> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
> >>
> >> firmware-N.bin contains various metadata, one of those being firmware
> >> feature flags:
> >>
> >> enum ath10k_fw_features {
> >>      /* wmi_mgmt_rx_hdr contains extra RSSI information */
> >>      ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX = 0,
> >>
> >>      /* Firmware from 10X branch. Deprecated, don't use in new code. */
> >>      ATH10K_FW_FEATURE_WMI_10X = 1,
> >>
> >>         [...]
> >>
> >> So what you could is add a new flag enum ath10k_fw_features, create a
> >> new firmware-N.bin for your device and enable the flag on the firmware
> >> releases for your device only.
> >>
> >> I don't know if this is usable, but one solution which came to my mind.
> >
> > It sounds quite reasonable to pass this using firmawre-N.bin instead of
> > DT, however that would imply that we need to find firmware-N.bin in the
> > device-specific directory, where we keep the wlanmdsp.mbn as well - and
> > not under /lib/firmware/ath10k
> >
> > For other devices (e.g. ADSP, modem or wlanmdsp.mbn) we're putting these
> > in e.g. /lib/firmware/qcom/LENOVO/81JL/ and specifies the location using
> > a firmware-name property in DT.
>
> Ah, I didn't realise that.
>
> Actually I would like to have ath10k in control[1] of QMI/rproc firmware
> loading as the firmware releases have different constraints, like the
> issue we are now discussing. Ideally firmware-N.bin would contain all
> firmware files, for example wlanmdsp.mbn, and from the meta data
> ath10k/ath11k would know what version of the firmware interface should
> be used.
>
> I remember we discussed this briefly a year or two ago and there was no
> easy solution, but I really wish we could find one. More these kind of
> firmware interface incompatibilities will most likely pop up, also in
> ath11k, so it would be great to find a clean and easily maneagable
> solution.
>
> [1] With control I mean that ath10k/ath11k can choose which firmware
> should be loaded
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches