Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()

[Greg KH]

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