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 18:02, Bjørn Mork wrote:
> Petr Štetiar <ynezz at true.cz> writes:
>
>> No, lets take a look at that PTP_1588_CLOCK_OPTIONAL:
>>
>> 	config PTP_1588_CLOCK_OPTIONAL
>> 		tristate
>> 		default y if PTP_1588_CLOCK=n
>> 		default PTP_1588_CLOCK
>> 		help
>> 		  Drivers that can optionally use the PTP_1588_CLOCK framework
>> 		  should depend on this symbol to prevent them from being built
>> 		  into vmlinux while the PTP support itself is in a loadable
>> 		  module.
>> 		  If PTP support is disabled, this dependency will still be
>> 		  met, and drivers refer to dummy helpers.
>>
>> From help text description it looks to me, that it's not tristate symbol at
>> all, it's boolean symbol and certainly shouldn't have `default PTP_1588_CLOCK`
>> as otherwise it's not doing what it's described on the box.
>
> Yes, that's obfuscated.

I don't understand what problem you see with the logic or the
help text. Obviously this cannot work as a 'bool' symbol, it has
to be 'tristate' for the logic to work.

> But what I mean is that you will hit exactly same problem with the
> common BAR || BAR=n pattern.

It's the same pattern, the only reason we introduced the
PTP_1588_CLOCK_OPTIONAL symbol is that too many people got
confused by the meaning of 'depends on PTP_1588_CLOCK ||
PTP_1588_CLOCK=n', which looks like it has no effect in
boolean logic though it does in tristate symbols.

>  linux-5.15.80$ echo "CONFIG_HSR=m" >>.config
>  linux-5.15.80$ make olddefconfig
>  .config:4543:warning: override: reassigning to symbol HSR
>  #
>  # configuration written to .config
>  #
>  $ grep -E 'CONFIG_(HSR|NET_DSA)[ =]' .config
>  CONFIG_NET_DSA=m
>  CONFIG_HSR=m
>
> We can't unconditionally enable any modules without considering the
> effect on their reverse dependencies.
>
> 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.

      Arnd