On Tue, 2020-03-31 at 09:39 -0700, Randy Dunlap wrote:
> On 3/31/20 2:10 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > The merge window has opened, so please do not add any material for
> > the
> > next release into your linux-next included trees/branches until
> > after
> > the merge window closes.
> >
> > Changes since 20200330:
> >
>
> on x86_64:
>
> ld: drivers/net/ethernet/mellanox/mlx5/core/main.o: in function
> `mlx5_cleanup_once':
> main.c:(.text+0x1ca): undefined reference to `mlx5_vxlan_destroy'
> ld: main.c:(.text+0x1d2): undefined reference to `mlx5_cleanup_clock'
> ld: drivers/net/ethernet/mellanox/mlx5/core/main.o: in function
> `mlx5_load_one':
> main.c:(.text+0xf44): undefined reference to `mlx5_init_clock'
> ld: main.c:(.text+0xf4c): undefined reference to `mlx5_vxlan_create'
> ld: main.c:(.text+0xfe5): undefined reference to `mlx5_vxlan_destroy'
>
>
This due to a change in behavior of imply keyword in kconfig due to
this patch:
def2fbffe62c00c330c7f41584a356001179c59c is the first bad commit
commit def2fbffe62c00c330c7f41584a356001179c59c
Author: Masahiro Yamada <masahiroy@xxxxxxxxxx>
Date: Mon Mar 2 15:23:39 2020 +0900
kconfig: allow symbols implied by y to become m
The 'imply' keyword restricts a symbol to y or n, excluding m
when it is implied by y. This is the original behavior since
commit 237e3ad0f195 ("Kconfig: Introduce the "imply" keyword").
However, the author of this feature, Nicolas Pitre, stated that
the 'imply' keyword should not impose any restrictions.
(https://lkml.org/lkml/2020/2/19/714)
I agree, and want to get rid of this tricky behavior.
Suggested-by: Nicolas Pitre <nico@xxxxxxxxxxx>
Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
Acked-by: Nicolas Pitre <nico@xxxxxxxxxxx>
For example in mlx5 we rely on CONFIG_VXLAN to compile in/out mlx5's
vxlan support, the problem occurs when VXLAN=m and MLX5_CORE=y.. prior
to this patch imply restricted VXLAN to y prior to this commit, and a
user who selected MLX5 and VXLAN, regardless of each module state
(y,m),
VXLAN in mlx5 worked.
but now with the change in behavior - even if we fix MLX5 - mlx5's
vxlan will be compiled-in but will not be actually used as VXLAN is not
reachable .. this change in behavior will introduce regression for
those who choose VXLAN=m MLX5_CORE=y.
To be honest this is a very unlikely configuration, but still i wanted
to raise this problem.
I will prepare a patch for mlx5.. where do we post linux-next fixes ?
since this issue doesn't exist in net-next tree.. or should i just wait
for rc1 ?
Thanks,
Saeed.
