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;
Date:   Tue, 7 Jun 2022 15:06:14 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Max Staudt <max@enpas.org>
Cc:     Vincent MAILHOL <mailhol.vincent@wanadoo.fr>,
        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>
Subject: Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD
Message-ID: <20220607150614.6248c504@kernel.org>
In-Reply-To: <20220607182216.5fb1084e.max@enpas.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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?