Future of mwifiex driver

Future of mwifiex driver

[Sascha Hauer]

I am worried about the future of the mwifiex driver. NXP has an ongoing
effort of forking the driver to support their new chips, but the forked
driver lacks support for the old chips supported by the current mwifiex
driver.

Overall this leaves us and our customers using the mwifiex driver in a
very bad situation.  Johannes made clear that he is not going to merge a
driver that is 70% identical to the existing driver and on the other
hand the existing driver doesn't get forward due to its odd-fixes state
and the potential rise of a new driver which would render work on the
existing driver useless.

I think part of the solution should be that we start cleaning up the
mwifiex driver so that at one point it could

a) be a robust base for a fork, or
b) make the fork unnecessary

This would help people using the mwifiex driver to get a better support
for their hardware.  It would also help NXP by splitting the necessary
changes into easier swallowable parts that are actually reviewable.
Should we really need a fork at some point then much of the review would
have already been done.

I have a series here [1] doing some cleanup work which I'd still like to
get forward.  Johannes made some remarks in [2] and [3] on which parts
of the driver need cleanup. Some more things for cleanup can also be
found in the forked driver code.

I am willing to put more work into the driver in creating and also
reviewing and testing patches, but I would need some path forward for
the driver and I think this needs a commitment from NXP to take the
detour over the mwifiex driver to get their stuff upstream.

Any thoughts?

[1] https://lore.kernel.org/linux-wireless/87ldwyumvq.fsf@kernel.org/
[2] https://lore.kernel.org/lkml/57ff2078632d8f14ca73c8307dc43585b3d09f50.camel@sipsolutions.net/#r
[2] https://lore.kernel.org/lkml/5f5c42585e168e252a5fa3f43325aaa360f6d27a.camel@sipsolutions.net/

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Future of mwifiex driver

[Brian Norris]

Hi Sascha,

On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> I am worried about the future of the mwifiex driver. NXP has an ongoing
> effort of forking the driver to support their new chips, but the forked
> driver lacks support for the old chips supported by the current mwifiex
> driver.
[...] 
> I have a series here [1] doing some cleanup work which I'd still like to
> get forward.
[...]
> [1] https://lore.kernel.org/linux-wireless/87ldwyumvq.fsf@kernel.org/

I'll apologize for that one stalling out a bit. IIRC, 11 of 12 patches
looked great, but I got stuck on the "fix MAC address handling" patch,
because it's a lot tougher to guarantee it doesn't break some use cases
while fixing things. But really, it's probably mostly a bandwidth thing
for me, as I really don't have many cycles to spend on things (and
especially when it gets beyond "obvious cleanup" and requires
substantial testing and/or reasoning).

> Any thoughts?

In no particular order:

1. even if NXP (or you, or anyone) does great work, I'm not going to be
   a super helpful maintainer. I simply don't have time to review and
   test substantial contributions.
2. I get the feeling linux-wireless may have problems like #1 in
   general. Johannes can't fill the entire gap Kalle left, for one.
   (Feel free to correct me if I'm wrong! Or if other excellent people
   have stepped up on review/maintenance.)
3. Other drivers may look somewhat similar, and yet fork for good
   reasons (like, firmware API revisions; or 802.11 generations; or some
   cross-section of both). I'm looking at rtw88/rtw89 (that I was
   involved with quite a bit), or ath10k/ath11k/ath12k/(have we made it
   to 13 yet?). So forking even with quite a bit of similarity isn't
   necessarily inherently wrong.
4. A key difference between #3 and mwifiex is, like you say, that
   mwifiex has a pretty low quality baseline. If I were maintaining it
   from the beginning, I probably wouldn't have accepted it.
5. I'm open to good people stepping up to fill in #1 -- i.e., include
   more maintainers that have a stake in larger contributions. Frankly,
   my only motivation here is to ensure that existing hardware supported
   by mwifiex doesn't get worse.

So all in all, I think I probably agree with you. But speaking openly, I
don't think I can be a large part of the solution here.

Regards,
Brian

Re: Future of mwifiex driver

[Johannes Berg]

Hi all,

Sorry I didn't reply earlier - I was dragging my feet, but also didn't
really know if I can add anything beyond what I already wrote.


On Mon, 2025-03-03 at 17:45 -0800, Brian Norris wrote:
> Hi Sascha,
> 
> On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> > I am worried about the future of the mwifiex driver. NXP has an ongoing
> > effort of forking the driver to support their new chips, but the forked
> > driver lacks support for the old chips supported by the current mwifiex
> > driver.
> [...] 
> > I have a series here [1] doing some cleanup work which I'd still like to
> > get forward.
> [...]
> > [1] https://lore.kernel.org/linux-wireless/87ldwyumvq.fsf@kernel.org/
> 
> I'll apologize for that one stalling out a bit. IIRC, 11 of 12 patches
> looked great, but I got stuck on the "fix MAC address handling" patch,
> because it's a lot tougher to guarantee it doesn't break some use cases
> while fixing things. But really, it's probably mostly a bandwidth thing
> for me, as I really don't have many cycles to spend on things (and
> especially when it gets beyond "obvious cleanup" and requires
> substantial testing and/or reasoning).

I guess that means could also partially resend the series, and get 11 of
the 12 in? I see the MAC address handling is first, but a cursory look
suggests that at least not all of the other would have a hard dependency
on it.

> In no particular order:
> 
> 1. even if NXP (or you, or anyone) does great work, I'm not going to be
>    a super helpful maintainer. I simply don't have time to review and
>    test substantial contributions.
> 2. I get the feeling linux-wireless may have problems like #1 in
>    general. Johannes can't fill the entire gap Kalle left, for one.
>    (Feel free to correct me if I'm wrong! Or if other excellent people
>    have stepped up on review/maintenance.)

Indeed, obviously still an ongoing issue, and I don't expect it to go
away soon. I see that Jeff has been reviewing some things not just
related to their drivers, but that's about it ...

Generally I'd also say that I'm going to give much more leeway to people
who are actually involved in the community, but I get the feeling that
everyone really would prefer to be in their little driver silo. NXP in
particular.

(The last email from @nxp.com on the list not related to these drivers
is from 2018, excluding ones from other business units that just got
accidentally CC'ed to the wireless list. And that was someone there
testing brcmfmac, it's pretty obvious that nobody there ever cared one
bit about looking beyond the driver.)


> 3. Other drivers may look somewhat similar, and yet fork for good
>    reasons (like, firmware API revisions; or 802.11 generations; or some
>    cross-section of both). I'm looking at rtw88/rtw89 (that I was
>    involved with quite a bit), or ath10k/ath11k/ath12k/(have we made it
>    to 13 yet?). So forking even with quite a bit of similarity isn't
>    necessarily inherently wrong.

Agree. We also just sort of forked iwlmvm to iwlmld, but it was actually
a rewrite, and we've thoroughly modernised it, e.g. removing mutexes and
locks where possible to use the wiphy_lock() stuff, integrating with
wiphy_work, taking different approaches on firmware notification
handling to make things more robust etc. The same is true e.g. of ath12k
over ath11k which got locking updates for wiphy locking, a lot of MLO
work, etc.

> 4. A key difference between #3 and mwifiex is, like you say, that
>    mwifiex has a pretty low quality baseline. If I were maintaining it
>    from the beginning, I probably wouldn't have accepted it.

Indeed, the above is _definitely_ not true for mwifiex/nxpwifi. I've
effectively proven in the other thread that it's just a straight up copy
without any modernisation etc. If there had actually been a real reason
to not work with the same code base, then that might have made sense -
perhaps with some library code split out.

But copying an old crappy driver for the sake of "we don't want to
maintain an old crappy driver" is a really bad argument to make?!

johannes

Re: Future of mwifiex driver

[Sascha Hauer]

On Fri, Mar 07, 2025 at 09:48:13AM +0100, Johannes Berg wrote:
> Hi all,
> 
> Sorry I didn't reply earlier - I was dragging my feet, but also didn't
> really know if I can add anything beyond what I already wrote.
> 
> 
> On Mon, 2025-03-03 at 17:45 -0800, Brian Norris wrote:
> > Hi Sascha,
> > 
> > On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> > > I am worried about the future of the mwifiex driver. NXP has an ongoing
> > > effort of forking the driver to support their new chips, but the forked
> > > driver lacks support for the old chips supported by the current mwifiex
> > > driver.
> > [...] 
> > > I have a series here [1] doing some cleanup work which I'd still like to
> > > get forward.
> > [...]
> > > [1] https://lore.kernel.org/linux-wireless/87ldwyumvq.fsf@kernel.org/
> > 
> > I'll apologize for that one stalling out a bit. IIRC, 11 of 12 patches
> > looked great, but I got stuck on the "fix MAC address handling" patch,
> > because it's a lot tougher to guarantee it doesn't break some use cases
> > while fixing things. But really, it's probably mostly a bandwidth thing
> > for me, as I really don't have many cycles to spend on things (and
> > especially when it gets beyond "obvious cleanup" and requires
> > substantial testing and/or reasoning).
> 
> I guess that means could also partially resend the series, and get 11 of
> the 12 in? I see the MAC address handling is first, but a cursory look
> suggests that at least not all of the other would have a hard dependency
> on it.

OK, I'll respin the series without the MAC address patch. Next I'll have
another look at the MAC address patch and see if I can improve it
further and send this as a separate patch.

> > 4. A key difference between #3 and mwifiex is, like you say, that
> >    mwifiex has a pretty low quality baseline. If I were maintaining it
> >    from the beginning, I probably wouldn't have accepted it.
> 
> Indeed, the above is _definitely_ not true for mwifiex/nxpwifi. I've
> effectively proven in the other thread that it's just a straight up copy
> without any modernisation etc. If there had actually been a real reason
> to not work with the same code base, then that might have made sense -
> perhaps with some library code split out.
> 
> But copying an old crappy driver for the sake of "we don't want to
> maintain an old crappy driver" is a really bad argument to make?!

Thanks for your clear words. For me that means that I can put more
effort into the mwifiex driver without risking that it becomes obsolete
soon.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Future of mwifiex driver

[Brian Norris]

On Fri, Mar 07, 2025 at 09:48:13AM +0100, Johannes Berg wrote:
> But copying an old crappy driver for the sake of "we don't want to
> maintain an old crappy driver" is a really bad argument to make?!

Is that the argument? Honest question. It's not really clear to me.

From
https://lore.kernel.org/all/20240930063701.2566520-1-yu-hao.lin@nxp.com/:

> [1] We had considered adding IW61x to mwifiex, however due to FW
>     architecture, host command interface and supported features are
>     significantly different, doing this on mwifiex will carry a lot of
>     burdens. The effort of making sure no regression is also a huge effort.
>     We must create a new driver nxpwifi. Subsequent NXP chipsets will be
>     added and sustained on nxpwifi only.

That sounds like you noted one of their reasons ("making sure no
regression is also a huge effort"), but they also claim the FW
architecture and host command interface is significantly different. I
don't recall seeing a proper discussion of that -- although Sascha seems
to claim [1] it wasn't that hard for him to support iw61x via mwifiex.

Brian

[1] https://lore.kernel.org/all/Z8rGDTjkwKAVaREL@pengutronix.de/

Re: Future of mwifiex driver

[Francesco Dolcini]

+ Jeff Chen <jeff.chen_1@nxp.com>, tsung-hsien.hsieh@nxp.com
+ Stefan Roese <sr@denx.de>

Hello Sascha,

On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> I am worried about the future of the mwifiex driver. NXP has an ongoing
> effort of forking the driver to support their new chips, but the forked
> driver lacks support for the old chips supported by the current mwifiex
> driver.
> 
> Overall this leaves us and our customers using the mwifiex driver in a
> very bad situation.  Johannes made clear that he is not going to merge a
> driver that is 70% identical to the existing driver and on the other
> hand the existing driver doesn't get forward due to its odd-fixes state
> and the potential rise of a new driver which would render work on the
> existing driver useless.

While I agree on the challenging situation, I would not call it "very
bad" ... as you know there are multiple people with stake on this driver
(I added SR in Cc here, that I just discovered has some interested on
this).

In the short term I think that improving mwifiex driver is going to be
beneficial for everybody, currently this is not going as smooth as we'd
like, as you wrote and as already commented by Brian.

And the next step would be to figure out how to enable newer Wi-Fi chip
solution from NXP in mainline, we all have our ideas and we are not
moving forward. NXP keeps pushing for a solution that was already
rejected multiple times and so far it was not successful on explaining
why this is the correct way forward. Here I would agree that the
situation is "very bad" at the moment.


> I think part of the solution should be that we start cleaning up the
> mwifiex driver

Ack. I would suggest that we focus on this. I can help with some
review/test (as partially done in the past), but I cannot commit to
actively work on much more than that as of now.

Francesco

Re: Future of mwifiex driver

[Sascha Hauer]

On Thu, Mar 06, 2025 at 11:17:15AM +0100, Francesco Dolcini wrote:
> + Jeff Chen <jeff.chen_1@nxp.com>, tsung-hsien.hsieh@nxp.com
> + Stefan Roese <sr@denx.de>
> 
> Hello Sascha,
> 
> On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> > I am worried about the future of the mwifiex driver. NXP has an ongoing
> > effort of forking the driver to support their new chips, but the forked
> > driver lacks support for the old chips supported by the current mwifiex
> > driver.
> > 
> > Overall this leaves us and our customers using the mwifiex driver in a
> > very bad situation.  Johannes made clear that he is not going to merge a
> > driver that is 70% identical to the existing driver and on the other
> > hand the existing driver doesn't get forward due to its odd-fixes state
> > and the potential rise of a new driver which would render work on the
> > existing driver useless.
> 
> While I agree on the challenging situation, I would not call it "very
> bad" ... as you know there are multiple people with stake on this driver
> (I added SR in Cc here, that I just discovered has some interested on
> this).
> 
> In the short term I think that improving mwifiex driver is going to be
> beneficial for everybody, currently this is not going as smooth as we'd
> like, as you wrote and as already commented by Brian.
> 
> And the next step would be to figure out how to enable newer Wi-Fi chip
> solution from NXP in mainline, we all have our ideas and we are not
> moving forward. NXP keeps pushing for a solution that was already
> rejected multiple times and so far it was not successful on explaining
> why this is the correct way forward. Here I would agree that the
> situation is "very bad" at the moment.

I have a patch adding iw61x support to the mwifiex driver. Maybe if I
send that for inclusion we can get NXP  to explain to us what's actually
missing in this patch to properly support it.

> 
> 
> > I think part of the solution should be that we start cleaning up the
> > mwifiex driver
> 
> Ack. I would suggest that we focus on this. I can help with some
> review/test (as partially done in the past), but I cannot commit to
> actively work on much more than that as of now.

Ok, I'll continue with my series then and skip the MAC address patch if
that's what blocking it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Future of mwifiex driver

[Francesco Dolcini]

On Fri, Mar 07, 2025 at 11:10:21AM +0100, Sascha Hauer wrote:
> On Thu, Mar 06, 2025 at 11:17:15AM +0100, Francesco Dolcini wrote:
> > + Jeff Chen <jeff.chen_1@nxp.com>, tsung-hsien.hsieh@nxp.com
> > + Stefan Roese <sr@denx.de>
> > 
> > On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> > > I am worried about the future of the mwifiex driver. NXP has an ongoing
> > > effort of forking the driver to support their new chips, but the forked
> > > driver lacks support for the old chips supported by the current mwifiex
> > > driver.
> > > 
> > > Overall this leaves us and our customers using the mwifiex driver in a
> > > very bad situation.  Johannes made clear that he is not going to merge a
> > > driver that is 70% identical to the existing driver and on the other
> > > hand the existing driver doesn't get forward due to its odd-fixes state
> > > and the potential rise of a new driver which would render work on the
> > > existing driver useless.
> > 
> > While I agree on the challenging situation, I would not call it "very
> > bad" ... as you know there are multiple people with stake on this driver
> > (I added SR in Cc here, that I just discovered has some interested on
> > this).
> > 
> > In the short term I think that improving mwifiex driver is going to be
> > beneficial for everybody, currently this is not going as smooth as we'd
> > like, as you wrote and as already commented by Brian.
> > 
> > And the next step would be to figure out how to enable newer Wi-Fi chip
> > solution from NXP in mainline, we all have our ideas and we are not
> > moving forward. NXP keeps pushing for a solution that was already
> > rejected multiple times and so far it was not successful on explaining
> > why this is the correct way forward. Here I would agree that the
> > situation is "very bad" at the moment.
> 
> I have a patch adding iw61x support to the mwifiex driver. Maybe if I
> send that for inclusion we can get NXP  to explain to us what's actually
> missing in this patch to properly support it.

I would have HW available to test it, and not just review the code,
looking forward to it.

Francesco

Re: Future of mwifiex driver

[Sascha Hauer]

On Wed, Mar 19, 2025 at 11:32:40AM +0100, Francesco Dolcini wrote:
> On Fri, Mar 07, 2025 at 11:10:21AM +0100, Sascha Hauer wrote:
> > On Thu, Mar 06, 2025 at 11:17:15AM +0100, Francesco Dolcini wrote:
> > > + Jeff Chen <jeff.chen_1@nxp.com>, tsung-hsien.hsieh@nxp.com
> > > + Stefan Roese <sr@denx.de>
> > > 
> > > On Mon, Mar 03, 2025 at 12:05:26PM +0100, Sascha Hauer wrote:
> > > > I am worried about the future of the mwifiex driver. NXP has an ongoing
> > > > effort of forking the driver to support their new chips, but the forked
> > > > driver lacks support for the old chips supported by the current mwifiex
> > > > driver.
> > > > 
> > > > Overall this leaves us and our customers using the mwifiex driver in a
> > > > very bad situation.  Johannes made clear that he is not going to merge a
> > > > driver that is 70% identical to the existing driver and on the other
> > > > hand the existing driver doesn't get forward due to its odd-fixes state
> > > > and the potential rise of a new driver which would render work on the
> > > > existing driver useless.
> > > 
> > > While I agree on the challenging situation, I would not call it "very
> > > bad" ... as you know there are multiple people with stake on this driver
> > > (I added SR in Cc here, that I just discovered has some interested on
> > > this).
> > > 
> > > In the short term I think that improving mwifiex driver is going to be
> > > beneficial for everybody, currently this is not going as smooth as we'd
> > > like, as you wrote and as already commented by Brian.
> > > 
> > > And the next step would be to figure out how to enable newer Wi-Fi chip
> > > solution from NXP in mainline, we all have our ideas and we are not
> > > moving forward. NXP keeps pushing for a solution that was already
> > > rejected multiple times and so far it was not successful on explaining
> > > why this is the correct way forward. Here I would agree that the
> > > situation is "very bad" at the moment.
> > 
> > I have a patch adding iw61x support to the mwifiex driver. Maybe if I
> > send that for inclusion we can get NXP  to explain to us what's actually
> > missing in this patch to properly support it.
> 
> I would have HW available to test it, and not just review the code,
> looking forward to it.

Great! I just sent the series out, you are on Cc.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |