From: Arnd Bergmann <arnd@arndb.de> To: Jason Gunthorpe <jgg@ziepe.ca> Cc: Saeed Mahameed <saeedm@mellanox.com>, "narmstrong@baylibre.com" <narmstrong@baylibre.com>, "masahiroy@kernel.org" <masahiroy@kernel.org>, "Laurent.pinchart@ideasonboard.com" <Laurent.pinchart@ideasonboard.com>, "davem@davemloft.net" <davem@davemloft.net>, "leon@kernel.org" <leon@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nico@fluxnic.net" <nico@fluxnic.net>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "linux-renesas-soc@vger.kernel.org" <linux-renesas-soc@vger.kernel.org>, "kieran.bingham+renesas@ideasonboard.com" <kieran.bingham+renesas@ideasonboard.com>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>, "a.hajda@samsung.com" <a.hajda@samsung.com>, "jonas@kwiboo.se" <jonas@kwiboo.se>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "airlied@linux.ie" <airlied@linux.ie>, "jernej.skrabec@siol.net" <jernej.skrabec@siol.net> Subject: Re: [RFC 0/6] Regressions for "imply" behavior change Date: Tue, 14 Apr 2020 16:27:41 +0200 [thread overview] Message-ID: <CAK8P3a0aFQ7h4zRDW=QLogXWc88JkJJXEOK0_CpWwsRjq6+T+w@mail.gmail.com> (raw) In-Reply-To: <20200414132900.GD5100@ziepe.ca> On Tue, Apr 14, 2020 at 3:29 PM Jason Gunthorpe <jgg@ziepe.ca> wrote: > On Fri, Apr 10, 2020 at 07:04:27PM +0000, Saeed Mahameed wrote: > > On Fri, 2020-04-10 at 14:13 -0300, Jason Gunthorpe wrote: > > > On Fri, Apr 10, 2020 at 02:40:42AM +0000, Saeed Mahameed wrote: > > > > > > > This assumes that the module using FOO has its own flag > > > > representing > > > > FOO which is not always the case. > > > > > > > > for example in mlx5 we use VXLAN config flag directly to compile > > > > VXLAN related files: > > > > > > > > mlx5/core/Makefile: > > > > > > > > obj-$(CONFIG_MLX5_CORE) += mlx5_core.o > > > > > > > > mlx5_core-y := mlx5_core.o > > > > mlx5_core-$(VXLAN) += mlx5_vxlan.o > > > > > > > > and in mlx5_main.o we do: > > > > > > Does this work if VXLAN = m ? > > > > Yes, if VXLAN IS_REACHABLE to MLX5, mlx5_vxlan.o will be > > compiled/linked. > > So mlx5_core-m does the right thing somehow? What happens with CONFIG_VXLAN=m is that the above turns into mlx5_core-y := mlx5_core.o mlx5_core-m += mlx5_vxlan.o which in turn leads to mlx5_core.ko *not* containing mlx5_vxlan.o, and in turn causing that link error against mlx5_vxlan_create/mlx5_vxlan_destroy, unless the IS_ENABLED() is changed to IS_REACHABLE(). > > > > if (IS_ENABLED(VXLAN)) > > > > mlx5_vxlan_init() > > > > > > > > after the change in imply semantics: > > > > our options are: > > > > > > > > 1) use IS_REACHABLE(VXLAN) instead of IS_ENABLED(VXLAN) > > > > > > > > 2) have MLX5_VXLAN in mlx5 Kconfig and use IS_ENABLED(MLX5_VXLAN) > > > > config MLX5_VXLAN > > > > depends on VXLAN || !VXLAN > > > > bool > > > > > > Does this trick work when vxlan is a bool not a tristate? > > > > > > Why not just put the VXLAN || !VXLAN directly on MLX5_CORE? > > > > > > > so force MLX5_CORE to n if vxlan is not reachable ? > > IIRC that isn't what the expression does, if vxlan is 'n' then > n || !n == true It forces MLX5_CORE to 'm' or 'n' but not 'y' if VXLAN=m, but allows any option if VXLAN=y > The other version of this is (m || VXLAN != m) Right, that should be the same, but is less common. I later found that I also needed this one for the same kind of dependency on PTP: --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig @@ -7,7 +7,7 @@ config MLX5_CORE tristate "Mellanox 5th generation network adapters (ConnectX series) core driver" depends on PCI select NET_DEVLINK - imply PTP_1588_CLOCK + depends on PTP_1588_CLOCK || !PTP_1588_CLOCK depends on VXLAN || !VXLAN imply MLXFW imply PCI_HYPERV_INTERFACE
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: Jason Gunthorpe <jgg@ziepe.ca> Cc: "airlied@linux.ie" <airlied@linux.ie>, "jernej.skrabec@siol.net" <jernej.skrabec@siol.net>, "leon@kernel.org" <leon@kernel.org>, "narmstrong@baylibre.com" <narmstrong@baylibre.com>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "masahiroy@kernel.org" <masahiroy@kernel.org>, "nico@fluxnic.net" <nico@fluxnic.net>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "linux-renesas-soc@vger.kernel.org" <linux-renesas-soc@vger.kernel.org>, Saeed Mahameed <saeedm@mellanox.com>, "jonas@kwiboo.se" <jonas@kwiboo.se>, "kieran.bingham+renesas@ideasonboard.com" <kieran.bingham+renesas@ideasonboard.com>, "Laurent.pinchart@ideasonboard.com" <Laurent.pinchart@ideasonboard.com>, "a.hajda@samsung.com" <a.hajda@samsung.com>, "davem@davemloft.net" <davem@davemloft.net> Subject: Re: [RFC 0/6] Regressions for "imply" behavior change Date: Tue, 14 Apr 2020 16:27:41 +0200 [thread overview] Message-ID: <CAK8P3a0aFQ7h4zRDW=QLogXWc88JkJJXEOK0_CpWwsRjq6+T+w@mail.gmail.com> (raw) In-Reply-To: <20200414132900.GD5100@ziepe.ca> On Tue, Apr 14, 2020 at 3:29 PM Jason Gunthorpe <jgg@ziepe.ca> wrote: > On Fri, Apr 10, 2020 at 07:04:27PM +0000, Saeed Mahameed wrote: > > On Fri, 2020-04-10 at 14:13 -0300, Jason Gunthorpe wrote: > > > On Fri, Apr 10, 2020 at 02:40:42AM +0000, Saeed Mahameed wrote: > > > > > > > This assumes that the module using FOO has its own flag > > > > representing > > > > FOO which is not always the case. > > > > > > > > for example in mlx5 we use VXLAN config flag directly to compile > > > > VXLAN related files: > > > > > > > > mlx5/core/Makefile: > > > > > > > > obj-$(CONFIG_MLX5_CORE) += mlx5_core.o > > > > > > > > mlx5_core-y := mlx5_core.o > > > > mlx5_core-$(VXLAN) += mlx5_vxlan.o > > > > > > > > and in mlx5_main.o we do: > > > > > > Does this work if VXLAN = m ? > > > > Yes, if VXLAN IS_REACHABLE to MLX5, mlx5_vxlan.o will be > > compiled/linked. > > So mlx5_core-m does the right thing somehow? What happens with CONFIG_VXLAN=m is that the above turns into mlx5_core-y := mlx5_core.o mlx5_core-m += mlx5_vxlan.o which in turn leads to mlx5_core.ko *not* containing mlx5_vxlan.o, and in turn causing that link error against mlx5_vxlan_create/mlx5_vxlan_destroy, unless the IS_ENABLED() is changed to IS_REACHABLE(). > > > > if (IS_ENABLED(VXLAN)) > > > > mlx5_vxlan_init() > > > > > > > > after the change in imply semantics: > > > > our options are: > > > > > > > > 1) use IS_REACHABLE(VXLAN) instead of IS_ENABLED(VXLAN) > > > > > > > > 2) have MLX5_VXLAN in mlx5 Kconfig and use IS_ENABLED(MLX5_VXLAN) > > > > config MLX5_VXLAN > > > > depends on VXLAN || !VXLAN > > > > bool > > > > > > Does this trick work when vxlan is a bool not a tristate? > > > > > > Why not just put the VXLAN || !VXLAN directly on MLX5_CORE? > > > > > > > so force MLX5_CORE to n if vxlan is not reachable ? > > IIRC that isn't what the expression does, if vxlan is 'n' then > n || !n == true It forces MLX5_CORE to 'm' or 'n' but not 'y' if VXLAN=m, but allows any option if VXLAN=y > The other version of this is (m || VXLAN != m) Right, that should be the same, but is less common. I later found that I also needed this one for the same kind of dependency on PTP: --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig @@ -7,7 +7,7 @@ config MLX5_CORE tristate "Mellanox 5th generation network adapters (ConnectX series) core driver" depends on PCI select NET_DEVLINK - imply PTP_1588_CLOCK + depends on PTP_1588_CLOCK || !PTP_1588_CLOCK depends on VXLAN || !VXLAN imply MLXFW imply PCI_HYPERV_INTERFACE _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-14 14:28 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-08 20:27 [RFC 0/6] Regressions for "imply" behavior change Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 1/6] thunder: select PTP driver if possible Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 2/6] net/mlx5e: fix VXLAN dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 3/6] LiquidIO VF: add dependency for PTP_1588_CLOCK Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 21:10 ` kbuild test robot 2020-04-08 21:13 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 4/6] drm/bridge/sii8620: fix extcon dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-10 6:56 ` Andrzej Hajda 2020-04-10 6:56 ` Andrzej Hajda 2020-04-14 15:04 ` Arnd Bergmann 2020-04-14 15:04 ` Arnd Bergmann 2020-04-14 15:37 ` Daniel Vetter 2020-04-14 15:37 ` Daniel Vetter 2020-04-15 6:58 ` Jani Nikula 2020-04-15 6:58 ` Jani Nikula 2020-04-08 20:27 ` [RFC 5/6] drm/rcar-du: fix selection of CMM driver Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-14 20:17 ` Laurent Pinchart 2020-04-14 20:17 ` Laurent Pinchart 2020-04-14 20:38 ` Arnd Bergmann 2020-04-14 20:38 ` Arnd Bergmann 2020-04-14 20:51 ` Laurent Pinchart 2020-04-14 20:51 ` Laurent Pinchart 2020-04-14 21:10 ` Arnd Bergmann 2020-04-14 21:10 ` Arnd Bergmann 2020-04-15 14:13 ` Geert Uytterhoeven 2020-04-15 14:13 ` Geert Uytterhoeven 2020-04-15 15:18 ` Arnd Bergmann 2020-04-15 15:18 ` Arnd Bergmann 2020-04-15 19:07 ` Arnd Bergmann 2020-04-15 19:07 ` Arnd Bergmann 2020-04-15 21:12 ` Laurent Pinchart 2020-04-15 21:12 ` Laurent Pinchart 2020-04-15 21:22 ` Arnd Bergmann 2020-04-15 21:22 ` Arnd Bergmann 2020-04-16 6:51 ` Daniel Vetter 2020-04-16 6:51 ` Daniel Vetter 2020-04-16 15:17 ` Laurent Pinchart 2020-04-16 15:17 ` Laurent Pinchart 2020-04-08 20:27 ` [RFC 6/6] drm/rcar-du: fix lvds dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:38 ` [RFC 0/6] Regressions for "imply" behavior change Nicolas Pitre 2020-04-08 20:38 ` Nicolas Pitre 2020-04-08 20:46 ` Saeed Mahameed 2020-04-08 20:46 ` Saeed Mahameed 2020-04-08 20:49 ` Arnd Bergmann 2020-04-08 20:49 ` Arnd Bergmann 2020-04-08 21:17 ` Nicolas Pitre 2020-04-08 21:17 ` Nicolas Pitre 2020-04-08 22:42 ` Jason Gunthorpe 2020-04-08 22:42 ` Jason Gunthorpe 2020-04-09 8:41 ` Jani Nikula 2020-04-09 8:41 ` Jani Nikula 2020-04-10 2:40 ` Saeed Mahameed 2020-04-10 2:40 ` Saeed Mahameed 2020-04-10 7:26 ` Geert Uytterhoeven 2020-04-10 7:26 ` Geert Uytterhoeven 2020-04-10 17:13 ` Jason Gunthorpe 2020-04-10 17:13 ` Jason Gunthorpe 2020-04-10 19:04 ` Saeed Mahameed 2020-04-10 19:04 ` Saeed Mahameed 2020-04-14 13:29 ` Jason Gunthorpe 2020-04-14 13:29 ` Jason Gunthorpe 2020-04-14 14:27 ` Arnd Bergmann [this message] 2020-04-14 14:27 ` Arnd Bergmann 2020-04-14 15:23 ` Jason Gunthorpe 2020-04-14 15:23 ` Jason Gunthorpe 2020-04-14 15:25 ` Arnd Bergmann 2020-04-14 15:25 ` Arnd Bergmann 2020-04-14 17:49 ` Saeed Mahameed 2020-04-14 17:49 ` Saeed Mahameed 2020-04-14 18:47 ` Arnd Bergmann 2020-04-14 18:47 ` Arnd Bergmann 2020-04-16 3:25 ` Saeed Mahameed 2020-04-16 3:25 ` Saeed Mahameed 2020-04-16 7:20 ` Arnd Bergmann 2020-04-16 7:20 ` Arnd Bergmann 2020-04-16 10:17 ` Jani Nikula 2020-04-16 10:17 ` Jani Nikula 2020-04-16 12:38 ` Arnd Bergmann 2020-04-16 12:38 ` Arnd Bergmann 2020-04-16 14:52 ` Jason Gunthorpe 2020-04-16 14:52 ` Jason Gunthorpe 2020-04-16 15:58 ` Arnd Bergmann 2020-04-16 15:58 ` Arnd Bergmann 2020-04-16 18:05 ` Jason Gunthorpe 2020-04-16 18:05 ` Jason Gunthorpe 2020-04-16 18:38 ` Saeed Mahameed 2020-04-16 18:38 ` Saeed Mahameed 2020-04-16 15:12 ` Nicolas Pitre 2020-04-16 15:12 ` Nicolas Pitre 2020-04-16 18:21 ` Jason Gunthorpe 2020-04-16 18:21 ` Jason Gunthorpe 2020-04-16 19:56 ` Andrzej Hajda 2020-04-16 19:56 ` Andrzej Hajda
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAK8P3a0aFQ7h4zRDW=QLogXWc88JkJJXEOK0_CpWwsRjq6+T+w@mail.gmail.com' \ --to=arnd@arndb.de \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=a.hajda@samsung.com \ --cc=airlied@linux.ie \ --cc=davem@davemloft.net \ --cc=dri-devel@lists.freedesktop.org \ --cc=jani.nikula@linux.intel.com \ --cc=jernej.skrabec@siol.net \ --cc=jgg@ziepe.ca \ --cc=jonas@kwiboo.se \ --cc=kieran.bingham+renesas@ideasonboard.com \ --cc=leon@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=masahiroy@kernel.org \ --cc=narmstrong@baylibre.com \ --cc=netdev@vger.kernel.org \ --cc=nico@fluxnic.net \ --cc=saeedm@mellanox.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.