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

Bjørn Mork bjorn at mork.no
Sat Dec 3 09:02:07 PST 2022


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.

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

Practical example:

 linux-5.15.80$ head net/dsa/Kconfig 
 # SPDX-License-Identifier: GPL-2.0-only
 
 menuconfig NET_DSA
         tristate "Distributed Switch Architecture"
         depends on BRIDGE || BRIDGE=n
         depends on HSR || HSR=n
         depends on INET && NETDEVICES
         select GRO_CELLS
         select NET_SWITCHDEV
         select PHYLINK
 linux-5.15.80$ grep -E 'CONFIG_(HSR|NET_DSA)[ =]' .config
 CONFIG_NET_DSA=y
 # CONFIG_HSR is not set
 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.


Bjørn



More information about the openwrt-devel mailing list