Re: [Buildroot] [PATCH] package/wilc-driver: fix build failure up to Linux 6.1

[Kris Bahnsen via buildroot <buildroot@buildroot.org>]

Giulio,

On Tue, 2023-01-03 at 00:05 +0100, Giulio Benetti wrote:
> Hi Kris, Thomas, All,
> 
> On 02/01/23 20:24, Kris Bahnsen wrote:
> > On Wed, 2022-12-28 at 21:53 +0100, Giulio Benetti wrote:
> > > Add patches pending upstream[0] to handle various data types and api
> > > changes up to Linux 6.1.
> > > 
> > > [0]: https://github.com/embeddedTS/wilc3000-external-module/pull/2
> > > 
> > > Fixes:
> > > http://autobuild.buildroot.net/results/6aa7475a21a6060e9fce3552f73e6e7100a8b2aa
> > > 
> > > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> > > ---
> > >   ...missing-prandom_u32-with-Linux-6.1.0.patch |  34 +++
> > >   ...fix-build-failure-on-remove-callback.patch |  44 ++++
> > >   ...uild-failure-with-Linux-5.19-and-6.1.patch |  98 ++++++++
> > >   ...on_parameters-Linux-6.1-build-failur.patch | 216 ++++++++++++++++++
> > >   4 files changed, 392 insertions(+)
> > >   create mode 100644 package/wilc-driver/0001-cfg80211.c-fix-missing-prandom_u32-with-Linux-6.1.0.patch
> > >   create mode 100644 package/wilc-driver/0002-spi.c-fix-build-failure-on-remove-callback.patch
> > >   create mode 100644 package/wilc-driver/0003-cfg80211.c-fix-build-failure-with-Linux-5.19-and-6.1.patch
> > >   create mode 100644 package/wilc-driver/0004-Fix-struct-station_parameters-Linux-6.1-build-failur.patch
> > > 
> > 
> > Giulio, all,
> > 
> > I figure this is the most appropriate place to have a discussion on
> > this topic as these patches were also pushed to our github repo:
> > https://github.com/embeddedTS/wilc3000-external-module/
> > 
> > I want to note that we are not intending on doing any maintenance
> > or patch work on this driver, except to keep this driver functional
> > on our platforms. 
> 
> Oh, I thought the goal was to keep the module successfully building
> through all Linux versions like we usually have in Buildroot for other
> packages. For example all the Wi-Fi modules(i.e. rtlxxx packages) and
> gpu(mali-driver, sunxi-mali-utgard, kernel-module-imx-gpu-viv etc.) or 
> other out of tree drivers.

Not quite. We decided to carve the tree from Microchip and make it
externally buildable. We submitted it to Buildroot because it had
appeared that the WILC support was neglected by Microchip. We took
that opportunity to at least keep the firmware up to date while also
giving any supported platforms a more up-to-date access to a driver.

We've been mostly relying on upstream from Microchip (and have an
outstanding driver bug open with them for the WILC3000 that has
been in process for the better part of 4 months) and touching bits
that make sense to touch that do not impact function.

> 
> > It is maintained as a buildable external module
> > of this folder tree:
> > https://github.com/linux4sam/linux-at91/tree/master/drivers/net/wireless/microchip
> 
> The problem is that with that we can't build for older Linux versions
> and this is one of our goals. Someone can be interested in having it
> running on Linux 4.x or earlier.

Which is why we havn't pulled in their latest round of changes
and any feature updates from them we now have to carefully navigate.

> 
> > We did this because during the Microchip takeover they abandoned
> > their maintained external tree as well as halted any plans to
> > bring WILC3000 support to the kernel upstream. Our fork gives us
> > easy access to building the modules without having to keep pulling
> > changes in to all of our kernels.
> > 
> > I'm not sure the best way to go about handling these patches as
> > Microchip is currently only maintaining support for 5.15 it
> > appears. I also don't want to pollute our external module tree
> > with fixes that arn't in the upstream we're pulling in.
> > 
> > Giulio, would you be willing to attempt pushing these changes
> > to the Microchip repo?
> 
> Yes, this is the idea once they create the 6.1 branch, at least I
> expect they will do it soon since it's the new Linux LTS version.
> Then for sure I will open a PR without all the #ifdef's I've created
> in the PR I've opened to your Repo. Of course those patches will be
> usable only for Linux 6.1 and that's it.

If we pull future patches in from linux4wilc tree, we will be careful
not to upset the existing #ifdef madness to keep backward compatible
support. But we do want to avoid getting ahead of linux4wilc if we
can so if those changes do come in eventually, we can avoid an
excessive amount of conflicts.

> 
> > Does it make more sense to just leave these as patches to the
> > driver in Buildroot?
> 
> Not very much, because they must be reworked over the time and they
> will continue to increase along with Linux versions. For sure we hope
> WILC1000/3000 will be totally upstreamed at a certain point. But anyway
> we will need your repository(or a fork of it) to keep all the #ifdef's
> for LINUX_VERSION to support it on old Linux versions.

Unfortunately, while WILC1000 support is upstream, WILC3000 will not be
upstreamed (according to a conversation with Microchip a few months
back). This means unless they have a change of heart, someone else takes
ownership, or we take ownership of the driver, it will likely remain
locked to Microchip's kernel and this external module will continue
to exist as needed.

> 
> > Would it make sense to instead apply some limits to the package
> > or external module to only build on already compatible kernel
> > versions?
> 
> I'd like to support the driver for any possible Linux version like we
> do for the other drivers in Buildroot.
> 
> I understand that there is an effort on your side to test the changes
> you pull, but this will keep your repository aligned with the latest
> Linux versions and it will be build-tested a lot with our autobuilders.
> 
> This is my 2 cents. I leave the last answers to the maintainers, Thomas
> is one of them.

We're not opposed to the idea, just hesitant to taking on that kind
of ownership.

We're doing some porting work at the moment, to get our LTS platforms
all up to kernel 5.10. From there, we may start pushing basic support
for various platforms to upstream kernel. I think once we get there
we would be more receptive to ownership of the WILC3000 driver to
keep our platforms running.

> 
> Best regards!
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot