LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Arnd Bergmann
arnd at arndb.de
Sat Dec 3 14:46:48 PST 2022
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
More information about the openwrt-devel
mailing list