LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]

[Jonas Gorski]

On Mon, 5 Dec 2022 at 11:00, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Sat, Dec 3, 2022, at 23:59, Bjørn Mork wrote:
> > "Arnd Bergmann" <arnd at arndb.de> writes:
> >> On Sat, Dec 3, 2022, at 18:02, Bjørn Mork wrote:
> >>
> >>> Yes, I realize that ALL_KMODS only changes a small subset of symbols
> >>> related to kmod packages.  And I'm pretty sure HSR isn't part of that
> >>> set.  But I don't think that changes anything.  This is a bug waiting to
> >>> happen again.
> >>
> >> Do you have any alternative suggestions? Changing the dependency logic
> >> would just cause runtime failures, and turning the dependencies all
> >> into 'bool' symbols would cause a significant increase in kernel size
> >> for distro builds that usually rely on things being in loadable modules.
> >
> > I was referring to the ALL_KMODS feature in OpenWrt, not to the
> > PTP_1588_CLOCK_OPTIONAL symbol.  As noted, there are many similar
> > constructs in the kernel. Personally I think
> > PTP_1588_CLOCK || PTP_1588_CLOCK=n would have been better, but I
> > see your point and am definitely not going to argue about that ;-)
> >
> > Should have made it clearer that I believe the bug is in OpenWrt, not in
> > the kernel. Just didn't notice that you were CC'ed into the discussion.
> > Thought we were having an OpenWrt conversation... Sorry about the
> > confusion.
>
> Ok, got it. Indeed this is a general problem for anyone wanting
> to enable all kernel modules. I don't know how ALL_KMODS works
> in OpenWRT, but there are other related problems that make this
> a hard problem, which means you need a whitelist or blacklist
> of some sort anyway:
>
> - Some modules are only visible depending on some other 'bool'
>   symbol, so you have to know which of those symbols to turn
>   on first
>
> - Some 'tristate' symbols not only control whether a module
>   is built but also impact the rest of the kernel.
>
> - Some modules are related to 'choice' statement or other
>   options that have mutually incompatible settings.

Luckily we already have solutions or workarounds in place for most of
these, like encoding a hash of the kernel configuration in the version
of the kernel (module) packages, and requiring an exact match on
installation.

Coming back to the original issue, I think there are only two viable
(short-term) solutions for mvebu (and any other target affected):

a) Set PTP_1588_CLOCK=y for mvebu, forcing it always on.
b) Disallow PTP_1588_CLOCK for mvebu, preventing it from being enabled.

so essentially treating it like a bool.

Since most mvebu devices are on the beefier side with plenty of RAM
and flash, I think a) is fine and shouldn't hurt too much.

In theory it would also be possible to make the switch driver a module
and let preinit load it (and include the ptp module optionally), but
this would be effectively the same as a) for releases/ALL_KMOD builds,
just more complicated, and less space efficient.


Jonas