Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAA=hcWQFNOeycXFPhrtHcQG3V8fWSShNRuAi49jtv8h1fPVUuQ@mail.gmail.com>
 <8ef5d73a-6293-a6c5-6bbb-b130266a8f0b@broadcom.com> <CAA=hcWQ_FVTVfRe91z1yHXMBLkkhi0eTq-9Lw3Tg=X6OS5Ku-Q@mail.gmail.com>
 <CA+ASDXPXCLjSL+mKKn-vh0fx0jdGBN-HOSDh4Dvy+93HSdRfBg@mail.gmail.com> <CAA=hcWS7w+EGZUnTJhLFEoOa78abBXLbGRHDz+BFYvR0n9c+sA@mail.gmail.com>
In-Reply-To: <CAA=hcWS7w+EGZUnTJhLFEoOa78abBXLbGRHDz+BFYvR0n9c+sA@mail.gmail.com>
From:   Brian Norris <briannorris@chromium.org>
Date:   Tue, 19 Apr 2022 11:13:50 -0700
Message-ID: <CA+ASDXMXoubRcc-R7NBfJ25x07+3um3TNcGg6VCzxYgC=zHCkA@mail.gmail.com>
Subject: Re: Support for bcm43364 wireless chipset in brcm80211/brcmfmac
To:     Jupiter <jupiter.hce@gmail.com>
Cc:     Arend van Spriel <arend.vanspriel@broadcom.com>,
        "David S. Miller" <davem@davemloft.net>,
        Sean Lanigan <sean@lano.id.au>,
        Kalle Valo <kvalo@codeaurora.org>,
        linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Jupiter,

On Thu, Apr 7, 2022 at 12:08 AM Jupiter <jupiter.hce@gmail.com> wrote:
> Another issue, it is not just kernel 5.10 mwifiex driver has been
> changed, the version of sd8801_uapsta.bin was also updated to
> W14.68.36.p204 [...]

I wouldn't be surprised if Marvell/NXP provided "updated" firmware (to
fix some CVE) but didn't actually test it with mainline Linux, or at
least not very well. If you're interested in bisecting, I'd stick to
the old firmware if I were you. But it sounds like maybe you aren't
well-equipped to do useful bisecting, so maybe that won't go anywhere.

> We did spend a large amount of resources and time debugging and we
> raised mwifiex issues many times to this list, unfortunately we did
> not get any response until now. If anyone is interested in debugging
> it, I'll devote myself to working it out, we are in downunder in
> different time zones.

I see several conversations where you did eventually get *some* responses:

Re: mwifiex reset buggy
https://lore.kernel.org/linux-wireless/20200206131455.knx2nsitunrfo4nu@beryllium.lan/

Re: Failed to can wifi Invalid Sched_scan parameters
https://lore.kernel.org/linux-wireless/CAD=FV=XMR33LONcyuvfLzJNd7vKB7vmiE1VSC_QArXA+Hy4Nsw@mail.gmail.com/

It seems like in those cases, people (rightfully, for this forum)
expected you to be able to do a bit more heavy lifting on
understanding what precisely is going on (e.g., what kind of
supplicant configuration is involved? did this particular environment
(AP, etc.) work previously?).

Unfortunately, it's not easy to remotely debug for you, and in some
cases, we really can't answer your questions for you. For instance,
some questions probably can't be answered without either:
(a) bisection or
(b) source code or documentation for firmware (most of us don't have this).

If you're looking for a higher level support than the limited free
support you get from random people on linux-wireless, then mwifiex
might not be right for you, and you should indeed look for different
hardware.

All I was saying is that if it previously worked well (with a given
firmware, mainline kernel, hardware, and RF environment), then it
should be _possible_ to get it working again. I didn't say it would be
easy.

Regards,
Brian