linux-kernel - Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aMxWzTxvMLsVWbDB@smile.fi.intel.com>
Date: Thu, 18 Sep 2025 22:00:29 +0300
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	sboyd@...nel.org, jic23@...nel.org, dlechner@...libre.com,
	nuno.sa@...log.com, andy@...nel.org, arnd@...db.de,
	gregkh@...uxfoundation.org, srini@...nel.org, vkoul@...nel.org,
	kishon@...nel.org, sre@...nel.org, krzysztof.kozlowski@...aro.org,
	linux-arm-msm@...r.kernel.org, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
	linux-pm@...r.kernel.org, kernel@...labora.com, wenst@...omium.org,
	casey.connolly@...aro.org,
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
	Neil Armstrong <neil.armstrong@...aro.org>
Subject: Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to
 devm_spmi_subdevice_alloc_and_add()

On Wed, Sep 17, 2025 at 02:47:22PM +0200, Uwe Kleine-König wrote:
> On Tue, Sep 16, 2025 at 07:20:20PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 16, 2025 at 6:11 PM Uwe Kleine-König
> > <u.kleine-koenig@...libre.com> wrote:
> > > On Tue, Sep 16, 2025 at 04:35:35PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Sep 16, 2025 at 03:24:56PM +0200, Uwe Kleine-König wrote:
> > > > > On Tue, Sep 16, 2025 at 10:44:40AM +0200, AngeloGioacchino Del Regno wrote:

...

> > > > > > +MODULE_IMPORT_NS("SPMI");
> > > > >
> > > > > If it's exactly the files that #include <linux/spmi.h> should have that
> > > > > namespace import, you can put the MODULE_IMPORT_NS into that header.
> > > >
> > > > Which makes anyone to import namespace even if they just want to use some types
> > > > out of the header.
> > >
> > > Notice that I carefully formulated my suggestion to cope for this case.
> > 
> > And I carefully answered.
> 
> I tend to disagree. If that anyone only wants some type from the header
> but not the namespace, the if part of my statement isn't given any more.
> Still your reply felt like objection while logically it's not.

You assumed that in case that the header that is *currently* included in the
users, may be the one that used by the same users that needs an imported
namespace. Okay, *now* (or today) it's not a problem, but *in the future* it
might be *when* one wants to use *just* types from it.
I don't think this is likely to happen, but in general including something
"by default" is not a good idea. That's what I'm objecting to.

> > Your proposal won't prevent _other_ files to
> > use the same header in the future without needing a namespace to be
> > imported.
> 
> Oh yes. But that's true for every change: If you change it further you
> have to cope for what is already there.
> 
> > > > This is not good solution generally speaking. Also this will
> > > > diminish one of the purposes of _NS variants of MODULE*/EXPORT*, i.e. make it
> > > > invisible that some of the code may become an abuser of the API just by someone
> > > > include the header (for a reason or by a mistake).
> > >
> > > Yeah, opinions differ. In my eyes it's quite elegant.
> > 
> > It's not a pure opinion,
> 
> That's your opinion :-)

All we said is just set of opinions. Facts are provided by scientific
experiments.

> > it has a technical background that I
> > explained. The explicit usage of MODULE_IMPORT_NS() is better than
> > some header somewhere that might even be included by another and be
> > proxied to the code that doesn't need / want to have this namespace to
> > be present. Puting MODULE_IMPORT_NS() into a _header_ is a minefield
> > for the future.
> 
> Well, for a deliberate abuser the hurdle to have to add the explicit
> MODULE_IMPORT_NS() isn't that big. And a mistaken abuser won't explode,
> just generate a few bytes overhead that can be fixed when noticed.
> 
> In my opinion that is an ok cost for the added elegance.

I tend to disagree. The practice to include (be lazy) something just in case is
a bad practice. Developer has to know what they are doing. We have already too
much bad code in the kernel and opening new ways for more "vibe:ish" coding is
a road to accumulated issues in the future.

I,o.w. I principally disagree on putting MODULE_IMPORT_NS() into the header
file.

-- 
With Best Regards,
Andy Shevchenko