[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220607150614.6248c504@kernel.org>
Date: Tue, 7 Jun 2022 15:06:14 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Max Staudt <max@...as.org>
Cc: Vincent MAILHOL <mailhol.vincent@...adoo.fr>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Marc Kleine-Budde <mkl@...gutronix.de>,
linux-can@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Oliver Hartkopp <socketcan@...tkopp.net>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD
On Tue, 7 Jun 2022 18:22:16 +0200 Max Staudt wrote:
> > Honestly, I am totally happy to have the "default y" tag, the "if
> > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together.
> >
> > Unless I am violating some kind of best practices, I prefer to keep it
> > as-is. Hope this makes sense.
AFAIU Linus likes for everything that results in code being added to
the kernel to default to n. If the drivers hard-select that Kconfig
why bother user with the question at all? My understanding is that
Linus also likes to keep Kconfig as simple as possible.
> I wholeheartedly agree with Vincent's decision.
>
> One example case would be users of my can327 driver, as long as it is
> not upstream yet. They need to have RX_OFFLOAD built into their
> distribution's can_dev.ko, otherwise they will have no choice but to
> build their own kernel.
Upstream mentioning out-of-tree modules may have the opposite effect
to what you intend :( Forgive my ignorance, what's the reason to keep
the driver out of tree?
Powered by blists - more mailing lists