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

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Sep 19, 2025 at 10:20:29AM -0500, David Lechner wrote:
> On 9/19/25 10:13 AM, Greg KH wrote:
> > 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
> 
> Up to now, my (naive) understanding was that the point module namespaces
> is to reduce the number of symbols in the global namespace because having
> too many symbols there was starting to cause problems. So moving symbols
> to another namespace was a "good thing".

Yes, it is a "good thing" overall, but by just making all of your
symbols in a namespace, and then including it in the .h file, that does
the same exact thing as before (i.e. anyone that includes that .h file
puts the symbols into the global namespace with that prefix.)

Ideally, the goal was to be able to easily see in a module, what symbol
namespaces they depend on, which requires them to put MODULE_IMPORT_NS()
in the module to get access to those symbols.  dmabuf has done this very
well, making it obvious to the maintainers of that subsystem that they
should be paying attention to those users.

For other "tiny" subsystems, it just slots away their symbols so that no
one else should ever be using them, and it makes it blindingly obvious
if they do.  For example, the usb-storage symbols, anyone that does:
	MODULE_IMPORT_NS("USB_STORAGE");
had better be living in drivers/usb/storage/ otherwise I need to have a
word with those offenders :)

So it's a way of "tidying" up things, and to make things more explicit
than just having to rely on searching a tree and looking for .h include
usage.  Right now, you are kind of defeating that by just allowing a .h
to be included and you don't get any benifit of being able to watch out
for who is actually using those symbols overall.

Hope this helps,

greg k-h

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy