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: <2025091918-glancing-uptown-7d63@gregkh>
Date: Fri, 19 Sep 2025 17:13:35 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: David Lechner <dlechner@...libre.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
	Uwe Kleine-König <u.kleine-koenig@...libre.com>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	sboyd@...nel.org, jic23@...nel.org, nuno.sa@...log.com,
	andy@...nel.org, arnd@...db.de, 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 Fri, Sep 19, 2025 at 10:05:28AM -0500, David Lechner wrote:
> On 9/19/25 8:59 AM, Greg KH wrote:
> > On Thu, Sep 18, 2025 at 10:00:29PM +0300, Andy Shevchenko wrote:
> >> I,o.w. I principally disagree on putting MODULE_IMPORT_NS() into the header
> >> file.
> > 
> > Yes, please never do that, it defeats the purpose of module namespaces
> > completly.  If you don't want to have module namespaces, don't use them
> > for your subsytem.  Don't use them and then make them moot by putting
> > MODULE_IMPORT_NS() in the .h file for the symbols as that's pointless.
> > 
> > thanks,
> > 
> > greg k-h
> 
> 
> Could someone suggest some additional explanation to add to
> Documentation/core-api/symbol-namespaces.rst to explain the
> reasoning behind this?
> 
> Right now, the only part of that document that say _why_ we have
> module namespces says:
> 
> 	That is useful for documentation purposes (think of the
> 	SUBSYSTEM_DEBUG namespace) as well as for limiting the
> 	availability of a set of symbols for use in other parts
> 	of the kernel.
> 
> So I don't see the connection between this explanation and and:
> 
> 	[Putting MODULE_IMPORT_NS() into the header] defeats
> 	the purpose of module namespaces completely.
> 
> I am guilty of putting it in a header, so if I need to fix that
> I would like to actually understand why first. Andy has mentioned
> something about potential abuses, but without any example, I haven't
> been able to understand what this would actually actually look like.
> Or maybe there is some other reason that Greg is thinking of that
> hasn't been mentioned yet?

Let me turn it around, _why_ would you want your exports in a namespace
at all if you just are putting a MODULE_IMPORT_NS() in the .h file at
the same time?  What is this giving you at all compared to just a normal
MODULE_EXPORT() marking for your exports?

I know what it gives me when I don't put it in a .h file, but I think
that might be different from what you are thinking here :)

thanks,

greg k-h