Message-ID: <20210711170155.zt5mpig6sgusifs3@pali>
Date:   Sun, 11 Jul 2021 19:01:55 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Jonas Dreßler <verdre@...d.nl>
Cc:     Maximilian Luz <luzmaximilian@...il.com>,
        Amitkumar Karwar <amitkarwar@...il.com>,
        Xinming Hu <huxinming820@...il.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Tsuchiya Yuto <kitakar@...il.com>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v2 2/2] mwifiex: pcie: add reset_d3cold quirk for Surface
 gen4+ devices

On Sunday 11 July 2021 18:53:32 Jonas Dreßler wrote:
> On 7/10/21 3:07 AM, Maximilian Luz wrote:
> > On 7/10/21 2:38 AM, Pali Rohár wrote:
> > > On Saturday 10 July 2021 02:18:12 Maximilian Luz wrote:
> > > > On 7/10/21 2:07 AM, Pali Rohár wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > Interesting, I was not aware of this. IIRC we've been
> > > > > > experimenting with
> > > > > > the mwlwifi driver (which that lrdmwl driver seems to be
> > > > > > based on?), but
> > > > > > couldn't get that to work with the firmware we have.
> > > > > 
> > > > > mwlwifi is that soft-mac driver and uses completely different firmware.
> > > > > For sure it would not work with current full-mac firmware.
> > > > > 
> > > > > > IIRC it also didn't
> > > > > > work with the Windows firmware (which seems to be significantly
> > > > > > different from the one we have for Linux and seems to
> > > > > > use or be modeled
> > > > > > after some special Windows WiFi driver interface).
> > > > > 
> > > > > So... Microsoft has different firmware for this chip? And it is working
> > > > > with mwifiex driver?
> > > > 
> > > > I'm not sure how special that firmware really is (i.e. if it is Surface
> > > > specific or just what Marvell uses on Windows), only that it doesn't
> > > > look like the firmware included in the linux-firmware repo. The Windows
> > > > firmware doesn't work with either mwlwifi or mwifiex drivers (IIRC) and
> > > > on Linux we use the official firmware from the linux-firmware repo.
> > > 
> > > Version available in the linux-firmware repo is also what big companies
> > > (like google) receive for their systems... sometimes just only older
> > > version as Marvell/NXP is slow in updating files in linux-firmware.
> > > Seems that it is also same what receive customers under NDA as more
> > > companies dropped "proprietary" ex-Marvell/NXP driver on internet and it
> > > contained this firmware with some sources of driver which looks like a
> > > fork of mwifiex (or maybe mwifiex is "cleaned fork" of that driver :D)
> > > 
> > > There is old firmware documentation which describe RPC communication
> > > between OS and firmware:
> > > http://wiki.laptop.org/images/f/f3/Firmware-Spec-v5.1-MV-S103752-00.pdf
> > > 
> > > It is really old for very old wifi chips and when I checked it, it still
> > > matches what mwifiex is doing with new chips. Just there are new and
> > > more commands. And documentation is OS-neutral.
> > > 
> > > So if Microsoft has some "incompatible" firmware with this, it could
> > > mean that they got something special which nobody else have? Maybe it
> > > can explain that "connected standby" and maybe also better stability?
> > > 
> > > Or just windows distribute firmware in different format and needs to
> > > "unpack" or "preprocess" prior downloading it to device?
> > 
> > If memory serves me right, Jonas did some reverse engineering on the
> > Windows driver and found that it uses the "new" WDI Miniport API: It
> > seems that originally both Windows and Linux drivers (and firmware)
> > were pretty much the same (he mentioned there were similarities in
> > terminology), but then they switched to that new API on Windows and
> > changed the firmware with it, so that the driver now essentially only
> > forwards the commands from that API to the firmware and the firmware
> > handles the rest.
> > 
> > By reading the Windows docs on that API, that change might have been
> > forced on them as some Windows 10 features apparently only work via
> > that API.
> > 
> > He'll probably know more about that than I do.
> 
> Not much I can add there, it seemed a lot like both mwifiex and the Windows
> 10 WDI miniport driver were both derived from the same codebase originally,
> but in order to be compatible with the WDI miniport API and other stuff
> Windows requires from wifi devices (I recall there was some SAR-value
> control/reporting stuff too), some parts of the firmware had to be
> rewritten.
> 
> In the end, the Windows firmware is updated a lot more often and likely
> includes a bunch of bugfixes the linux firmware doesn't have, but it can't
> be used on linux without a ton of work that would probably include
> rebuilding proprietary APIs from Windows.
> 
> Also, from my testing with custom APs and sniffing packets with Wireshark,
> the functionality, limitations and weird "semi-spec-compliant" behaviors
> were exactly the same with the Windows firmware: It doesn't support WPA3, it
> can't connect to fast transition APs (funnily enough that's opposed to what
> MS claims) and it also can't spawn an AP with WPA-PSK-SHA256 AKM ciphers. So
> not sure there's a lot of sense in spending more time trying to go down that
> path.

New version of firmware files are available on NXP portal, where are
updated more frequently, but only for companies which have NXP accounts
and signed NDA with NXP. Not for end users.

If you want these new firmware files, you need to ask NXP developers as
only they can ask for non-NDA distribution and include new version into
linux-firmware repository. Like in this pull request where is new SDIO
firmware for 88W8897:
https://lore.kernel.org/linux-firmware/DB7PR04MB453855B0D6C41923BCB0922EFC1C9@DB7PR04MB4538.eurprd04.prod.outlook.com/

Powered by blists - more mailing lists