Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220513142355.250389-1-mailhol.vincent@wanadoo.fr>
 <20220604163000.211077-1-mailhol.vincent@wanadoo.fr> <20220604163000.211077-5-mailhol.vincent@wanadoo.fr>
 <CAMuHMdXkq7+yvD=ju-LY14yOPkiiHwL6H+9G-4KgX=GJjX=h9g@mail.gmail.com>
 <CAMZ6RqLEEHOZjrMH+-GLC--jjfOaWYOPLf+PpefHwy=cLpWTYg@mail.gmail.com>
 <20220607182216.5fb1084e.max@enpas.org> <20220607150614.6248c504@kernel.org>
In-Reply-To: <20220607150614.6248c504@kernel.org>
From:   Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Date:   Wed, 8 Jun 2022 08:40:19 +0900
Message-ID: <CAMZ6Rq+vYNvrTcToqVqqKSPJXAdjs3RkUY_SNuwB7n9FMuqQiQ@mail.gmail.com>
Subject: Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     Max Staudt <max@enpas.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Marc Kleine-Budde <mkl@pengutronix.de>,
        linux-can@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Oliver Hartkopp <socketcan@hartkopp.net>,
        netdev <netdev@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Wed. 8 Jun 2022 à 07:06, Jakub Kicinski <kuba@kernel.org> wrote:
> 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.

A "make defconfig" would not select CONFIG_CAN (on which
CAN_RX_OFFLOAD indirectly depends) and so by default this code is not
added to the kernel.

> 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 do not think that this is so convoluted. What would bother me is
that RX offload is not a new feature. Before this series, RX offload
is built-in the can-dev.o by default. If this new CAN_RX_OFFLOAD does
not default to yes, then the default features built-in can-dev.o would
change before and after this series.
But you being one of the maintainers, if you insist I will go in your
direction. So will removing the "default yes" and the comment "If
unsure, say yes" from the CAN_RX_OFFLOAD satisfy you?

> > 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?

I can answer for Max. The can327 patch is under review with the clear
intent to have it upstream. c.f.:
https://lore.kernel.org/linux-can/20220602213544.68273-1-max@enpas.org/

But until the patch gets accepted, it is defacto an out of tree module.


Yours sincerely,
Vincent Mailhol