All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Kris Bahnsen via buildroot <buildroot@buildroot.org>
Cc: "Giulio Benetti" <giulio.benetti@benettiengineering.com>,
	"Alexis Lothoré" <alexis.lothore@bootlin.com>,
	"Kris Bahnsen" <kris@embeddedTS.com>
Subject: Re: [Buildroot] [PATCH 1/1] package/wilc-driver: bump to linux4microchip-2024.04
Date: Thu, 1 Aug 2024 23:38:18 +0200	[thread overview]
Message-ID: <20240801233818.41e20f0f@windsurf> (raw)
In-Reply-To: <20240731235548.1792330-1-kris@embeddedTS.com>

Hello Kris,

On Wed, 31 Jul 2024 23:55:48 +0000
Kris Bahnsen via buildroot <buildroot@buildroot.org> wrote:

> Latest update from Microchip's kernel.
> 
> Removes Buildroot patches and instead incorporates these directly
> to a community branch of the repo. Also adds a check in wilc-driver.mk
> to use the new linux4microchip-2024.04-community tag when
> BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_4 is true.

Could you clarify why the code in linux4microchip-2024.04-community
doesn't work on older kernels?

> We investigated the potential to use backports to make maintenance
> easier as I mentioned, however it did not work out as we had expected.

Not sure what "backports" you're referring to here. Backporting what
from what, to what?

> I'm not sure if I did the kernel dependency check in the most elegant
> way. If there is a preferred way to handle that, please let me know and
> I'll happily make a revision.

The version dependency check is annoying, which is why I'm asking above
if we could get away with it, which would be the best solution.

> -WILC_DRIVER_VERSION = linux4microchip-2021.10-1
> +# Set up driver version based on kernel headers
> +# See the project's README for more information on this
> +ifeq ($(BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_4),y)
> +WILC_DRIVER_VERSION = linux4microchip-2024.04-community
> +else
> +WILC_DRIVER_VERSION = linux4microchip-2021.10-1-upto-linux-6.6
> +endif

Unfortunately, we cannot use the kernel headers version. Some people
use external toolchains that have possibly a bit old kernel headers,
but they may be running a very up-to-date kernel. So the only option I
believe is to do like AUFS in linux/Config.ext.in, with an explicit
choice.

But that's also going to break badly with autobuilder testing. So
really, if we can use a single version for all kernel versions, it
would be much, much, much better.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2024-08-01 21:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31 23:55 [Buildroot] [PATCH 1/1] package/wilc-driver: bump to linux4microchip-2024.04 Kris Bahnsen via buildroot
2024-08-01 21:38 ` Thomas Petazzoni via buildroot [this message]
2024-08-01 22:27   ` Kris Bahnsen via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240801233818.41e20f0f@windsurf \
    --to=buildroot@buildroot.org \
    --cc=alexis.lothore@bootlin.com \
    --cc=giulio.benetti@benettiengineering.com \
    --cc=kris@embeddedTS.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.