Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
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>
In-Reply-To: <CA+ASDXPXCLjSL+mKKn-vh0fx0jdGBN-HOSDh4Dvy+93HSdRfBg@mail.gmail.com>
From:   Jupiter <jupiter.hce@gmail.com>
Date:   Thu, 7 Apr 2022 17:07:56 +1000
Message-ID: <CAA=hcWS7w+EGZUnTJhLFEoOa78abBXLbGRHDz+BFYvR0n9c+sA@mail.gmail.com>
Subject: Re: Support for bcm43364 wireless chipset in brcm80211/brcmfmac
To:     Brian Norris <briannorris@chromium.org>
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 Brian,

Thanks for your response and comments.

> Despite what corporations tell you, mainline Linux shouldn't be
> dropping support for things just because the corporation moved on. If
> you can track down the mwifiex regression (e.g., with bisection),
> there's a chance we can fix it. I still see
> SDIO_DEVICE_ID_MARVELL_8801 listed in the upstream driver, FWIW.

As an open source advocate, I am keen to debug and to track it down,
but to be honest, we have a very small embedded development team here,
no one has deep knowledge and skill for kernel work, nor is anyone
familiar with git bisect for debugging an embedded device. We can run
our embedded board on console to debug the issue, but we do need
experienced kernel developers to guide us to run git bisect, we tried
last time, it did not work, if you are willing to help and if you are
patient, we can start a new debug thread to work it out.

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 by Ganapathi Bhat <gbhat@marvell.com> who moved to NXP
but soon resigned from NXP we could not contact to Ganapathi. We don't
believe Ganapathi tested the new version firmware with kernel 5.10
driver well, we don't know if it is a driver issue or firmware issue,
it is very hard to debug two moving targets broken in protocol,
especially we could not see the source of firmware. We did test
5.10.81 mwifiex driver with different versions of sd8801_uapsta.bin,
then just found out that different versions of firmware have different
communication issues, so we had no choice but to give up the debug
efforts. In that sense, we don't know if the git bisect would be
effective to resolve this problem.

> Unfortunately, without anyone paying attention (Marvell, NXP, ... or
> you) that has the hardware, it can be hard to guarantee things stay
> working. Hint: while I have (and care about) several Marvell chips, I
> don't have that one.

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.

Thank you very much.

Kind regards,

Jupiter