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

[Arnd Bergmann]

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.

    Arnd