[DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte

Brian Norris briannorris at chromium.org
Wed Apr 29 10:15:55 PDT 2026


Hi,

On Wed, Apr 29, 2026 at 12:55:23PM +0200, Karel Balej wrote:
> Francesco Dolcini, 2025-11-28T18:05:37+01:00:
> > On Thu, Nov 27, 2025 at 04:29:12PM +0100, Karel Balej wrote:
> >> To reiterate, the firmware is generally available but is not part of
> >> linux-firmware and the entire process of upstreaming the chipset support is
> >> stuck on that.
> >
> > I'll try to see if any of my contact in NXP Wi-Fi group is able to help. Give
> > me a few days.
> 
> so I was in a long conversation over the past months with Jeff from NXP
> who was very helpful and tried to arrange for the upstreaming of the
> firmware. Unfortunately however, his efforts were ultimately rejected by
> the internal management.

:(

> We were directed to try to reach out to NXP via the customer support
> page which yielded nothing. The current situation is thus the same as a
> few months ago, summarized in my quote above.
> 
> Brian, what are the options here now? Would it be possible to make an
> exception and accept the patches without the firmware being in
> linux-firmware? This is an old device with no mainstream audience so I
> expect everyone who will want to use it will be able to supply the
> firmware themselves

I'm not really in the business of writing rules here nor their
exceptions. I was just pointing you at the existing rules, and how this
seemed to violate them. Since the websites have moved around a bit since
the last time, here's the page I referenced:

https://wireless.docs.kernel.org/en/latest/en/developers/documentation/submittingpatches.html#new-driver

I suppose maybe those rules are there so that we don't get drivers with
*no* legally-usable firmware, since it's about "New Drivers". This is
not a New Driver, so maybe that part doesn't have to apply.

I suppose I'll leave it up to Johannes on this part, and may be willing
to retract my NAK [1].

> and it would be great to not have to keep the
> patches in a fork, especially when trying to build on top of them
> further (such as to fix the driver-firmware incompatibilities discussed
> in one of the patches of this series).

Patch 3 is a different story. At the moment, it's definitely not
acceptable. But I tried to provide hints about how you can write proper
FW compatibility logic. I'm still not optimistic that'll be easy and
maintainable, and we still reserve the right to reject patches if they
make things unmaintainable.

(Marvell clearly didn't do any real work here on maintaining good FW
compatibility.)

Brian

> Francesco, would you perhaps still be able to help in any way?
> 
> Thank you, kind regards,
> K. B.

[1] I think you're referring to this:
    https://lore.kernel.org/all/ZUQN4Ua8byy-Fsy8@google.com/
    Re: [PATCH 0/2] net: mwifiex: add support for the SD8777 chipset



More information about the linux-arm-kernel mailing list