Software nodes are currently initialized in a function registered as
a postcore_initcall(). However, some devices may want to register
software nodes earlier than that (or also in a postcore_initcall() where
they're at the merci of the link order). Move the initialization to
driver_init() making swnode available much earlier as well as making
their initialization time deterministic.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/base/base.h | 1 +
drivers/base/init.c | 1 +
drivers/base/swnode.c | 13 ++-----------
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index afeda89fd4710c4c5492b5f19134e2aa8e1e581e..30b416588617bbc3fb433654c999c9b533d73752 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -312,6 +312,7 @@ static inline int devtmpfs_create_node(struct device *dev) { return 0; }
static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
#endif
+void software_node_init(void);
void software_node_notify(struct device *dev);
void software_node_notify_remove(struct device *dev);
diff --git a/drivers/base/init.c b/drivers/base/init.c
index 9d2b06d65dfc6bf8759f6c232e2d3f753da139ac..af8014416c2460fac91b08ce919c082bf961fcce 100644
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -34,6 +34,7 @@ void __init driver_init(void)
*/
faux_bus_init();
of_core_init();
+ software_node_init();
platform_bus_init();
auxiliary_bus_init();
memory_dev_init();
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9f1bf4f65aa161d9b941affc74936..a80575bf598b509eb1469cae8a09c601726ce0c8 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -1127,18 +1127,9 @@ void software_node_notify_remove(struct device *dev)
}
}
-static int __init software_node_init(void)
+void __init software_node_init(void)
{
swnode_kset = kset_create_and_add("software_nodes", NULL, kernel_kobj);
if (!swnode_kset)
- return -ENOMEM;
- return 0;
-}
-postcore_initcall(software_node_init);
-
-static void __exit software_node_exit(void)
-{
- ida_destroy(&swnode_root_ids);
- kset_unregister(swnode_kset);
+ pr_err("failed to register software nodes\n");
}
-__exitcall(software_node_exit);
--
2.47.3On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
> Software nodes are currently initialized in a function registered as
> a postcore_initcall(). However, some devices may want to register
> software nodes earlier than that (or also in a postcore_initcall() where
> they're at the merci of the link order). Move the initialization to
> driver_init() making swnode available much earlier as well as making
> their initialization time deterministic.
...
> -static void __exit software_node_exit(void)
> -{
> - ida_destroy(&swnode_root_ids);
> - kset_unregister(swnode_kset);
> }
> -__exitcall(software_node_exit);
Why? What's wrong with the __exitcall?
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
> > Software nodes are currently initialized in a function registered as
> > a postcore_initcall(). However, some devices may want to register
> > software nodes earlier than that (or also in a postcore_initcall() where
> > they're at the merci of the link order). Move the initialization to
> > driver_init() making swnode available much earlier as well as making
> > their initialization time deterministic.
>
> ...
>
> > -static void __exit software_node_exit(void)
> > -{
> > - ida_destroy(&swnode_root_ids);
> > - kset_unregister(swnode_kset);
> > }
> > -__exitcall(software_node_exit);
>
>
> Why? What's wrong with the __exitcall?
>
It's dead code. Always was, always will be.
Maybe split in a separate patch, but I sometimes feel the idea of "one
change" is taken to extreme and adds to both developer's and maintainers
burden by needing to keep track of extra patches.
Thanks.
--
Dmitry
On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
...
> > > -static void __exit software_node_exit(void)
> > > -{
> > > - ida_destroy(&swnode_root_ids);
> > > - kset_unregister(swnode_kset);
> > > }
> > > -__exitcall(software_node_exit);
> >
> > Why? What's wrong with the __exitcall?
>
> It's dead code. Always was, always will be.
>
> Maybe split in a separate patch, but I sometimes feel the idea of "one
> change" is taken to extreme and adds to both developer's and maintainers
> burden by needing to keep track of extra patches.
Why does __exitcall() exist then? It's also used in other places.
I think it's generally good to have a possibility to clean up
after run.
A bit of archaeology:
The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
Then somehow spread a bit (but not much).
--
With Best Regards,
Andy Shevchenko
On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
>> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
>> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
>
>...
>
>> > > -static void __exit software_node_exit(void)
>> > > -{
>> > > - ida_destroy(&swnode_root_ids);
>> > > - kset_unregister(swnode_kset);
>> > > }
>> > > -__exitcall(software_node_exit);
>> >
>> > Why? What's wrong with the __exitcall?
>>
>> It's dead code. Always was, always will be.
>>
>> Maybe split in a separate patch, but I sometimes feel the idea of "one
>> change" is taken to extreme and adds to both developer's and maintainers
>> burden by needing to keep track of extra patches.
>
>Why does __exitcall() exist then? It's also used in other places.
>I think it's generally good to have a possibility to clean up
>after run.
>
The code section will be discarded when the kernel finishes booting so it only increases image size on disk.
>A bit of archaeology:
>
>The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
>Then somehow spread a bit (but not much).
>
And it shows how useful it is. Maybe it had some purpose a long time ago, but at present time this code will never be executed since it cannot be built as a module.
Thanks.
--
Dmitry
On Mon, Mar 30, 2026 at 11:52:34PM -0700, Dmitry Torokhov wrote:
> On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> >> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> >> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
...
> >> > > -static void __exit software_node_exit(void)
> >> > > -{
> >> > > - ida_destroy(&swnode_root_ids);
> >> > > - kset_unregister(swnode_kset);
> >> > > }
> >> > > -__exitcall(software_node_exit);
> >> >
> >> > Why? What's wrong with the __exitcall?
> >>
> >> It's dead code. Always was, always will be.
> >>
> >> Maybe split in a separate patch, but I sometimes feel the idea of "one
> >> change" is taken to extreme and adds to both developer's and maintainers
> >> burden by needing to keep track of extra patches.
> >
> >Why does __exitcall() exist then? It's also used in other places.
> >I think it's generally good to have a possibility to clean up
> >after run.
>
> The code section will be discarded when the kernel finishes booting so it
> only increases image size on disk.
Almost true. Interesting microblaze case, where it's not discarded.
But I can't find where it's actually used on any architecture.
> >A bit of archaeology:
> >
> >The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
> >Then somehow spread a bit (but not much).
>
> And it shows how useful it is. Maybe it had some purpose a long time ago, but
> at present time this code will never be executed since it cannot be built as
> a module.
Are you sure about definition of __exitcall? As I read init.h the macro
is defined when it's not a MODULE.
Anyways, if we going to drop that, it should be in a separate change
explaining all these.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 31, 2026, at 10:55, Andy Shevchenko wrote:
> On Mon, Mar 30, 2026 at 11:52:34PM -0700, Dmitry Torokhov wrote:
>> On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>> >On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
>>
>> The code section will be discarded when the kernel finishes booting so it
>> only increases image size on disk.
>
> Almost true. Interesting microblaze case, where it's not discarded.
> But I can't find where it's actually used on any architecture.
I'm pretty sure that is just mistake
>> >A bit of archaeology:
>> >
>> >The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
>> >Then somehow spread a bit (but not much).
>>
>> And it shows how useful it is. Maybe it had some purpose a long time ago, but
>> at present time this code will never be executed since it cannot be built as
>> a module.
>
> Are you sure about definition of __exitcall? As I read init.h the macro
> is defined when it's not a MODULE.
I also tried to trace this back now, and from what I found, both
the __init_call and __exit_call annotations gained __attribute_used__
back in lniux-2.6.0 as a way to prevent both gcc-3.3 and gcc-3.4
from warning about unused functions or discarding initcalls that
are actually required.
My best guess is that __exit_call should just use
__attribute__((unused)) instead of __attribute__((used)) and
have the compiler drop it from built-in code instead of the linker:
diff --git a/include/linux/init.h b/include/linux/init.h
index 5db55c660124..ad5c19763034 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -47,7 +47,7 @@
#define __initdata __section(".init.data")
#define __initconst __section(".init.rodata")
#define __exitdata __section(".exit.data")
-#define __exit_call __used __section(".exitcall.exit")
+#define __exit_call __maybe_unused __section(".exitcall.exit")
/*
* modpost check for section mismatches during the kernel build.
Arnd
On Tue, Mar 31, 2026 at 12:45:59PM +0200, Arnd Bergmann wrote:
> On Tue, Mar 31, 2026, at 10:55, Andy Shevchenko wrote:
> > On Mon, Mar 30, 2026 at 11:52:34PM -0700, Dmitry Torokhov wrote:
> >> On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >> >On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> >>
> >> The code section will be discarded when the kernel finishes booting so it
> >> only increases image size on disk.
> >
> > Almost true. Interesting microblaze case, where it's not discarded.
> > But I can't find where it's actually used on any architecture.
>
> I'm pretty sure that is just mistake
>
> >> >A bit of archaeology:
> >> >
> >> >The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
> >> >Then somehow spread a bit (but not much).
> >>
> >> And it shows how useful it is. Maybe it had some purpose a long time ago, but
> >> at present time this code will never be executed since it cannot be built as
> >> a module.
> >
> > Are you sure about definition of __exitcall? As I read init.h the macro
> > is defined when it's not a MODULE.
>
> I also tried to trace this back now, and from what I found, both
> the __init_call and __exit_call annotations gained __attribute_used__
> back in lniux-2.6.0 as a way to prevent both gcc-3.3 and gcc-3.4
> from warning about unused functions or discarding initcalls that
> are actually required.
>
> My best guess is that __exit_call should just use
> __attribute__((unused)) instead of __attribute__((used)) and
> have the compiler drop it from built-in code instead of the linker:
But why do we need that at all? Can we just drop the full section for good.
Or i.o.w. where exactly is it being used in the current kernel?
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 31, 2026, at 13:09, Andy Shevchenko wrote:
> On Tue, Mar 31, 2026 at 12:45:59PM +0200, Arnd Bergmann wrote:
>> On Tue, Mar 31, 2026, at 10:55, Andy Shevchenko wrote:
>>
>> My best guess is that __exit_call should just use
>> __attribute__((unused)) instead of __attribute__((used)) and
>> have the compiler drop it from built-in code instead of the linker:
>
> But why do we need that at all? Can we just drop the full section for good.
> Or i.o.w. where exactly is it being used in the current kernel?
The main use case I see for __exit_call is for device drivers
that can be either loadable modules or built-in: In a loadable module,
you need the cleanup function, but for built-in code you want
it to be dropped at build time.
For the few direct callers of __exitcall, the only explanation I have
is that these could at some point be turned into loadable modules,
and the author wanted to be prepared for changing it later. In theory
we could change those to module_exit(), or just remove them, but
there is little practical benefit either way.
I've tested the __maybe_unused change on randconfig builds now and
found no (build-time) issues with that, so I'm submitting that
now.
Arnd
On Tue, Mar 31, 2026 at 10:55 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2026 at 11:52:34PM -0700, Dmitry Torokhov wrote:
> > On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > >On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
> > >> On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> > >> > On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
>
> ...
>
> > >> > > -static void __exit software_node_exit(void)
> > >> > > -{
> > >> > > - ida_destroy(&swnode_root_ids);
> > >> > > - kset_unregister(swnode_kset);
> > >> > > }
> > >> > > -__exitcall(software_node_exit);
> > >> >
> > >> > Why? What's wrong with the __exitcall?
> > >>
> > >> It's dead code. Always was, always will be.
> > >>
> > >> Maybe split in a separate patch, but I sometimes feel the idea of "one
> > >> change" is taken to extreme and adds to both developer's and maintainers
> > >> burden by needing to keep track of extra patches.
> > >
> > >Why does __exitcall() exist then? It's also used in other places.
> > >I think it's generally good to have a possibility to clean up
> > >after run.
> >
> > The code section will be discarded when the kernel finishes booting so it
> > only increases image size on disk.
>
> Almost true. Interesting microblaze case, where it's not discarded.
> But I can't find where it's actually used on any architecture.
>
> > >A bit of archaeology:
> > >
> > >The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
> > >Then somehow spread a bit (but not much).
> >
> > And it shows how useful it is. Maybe it had some purpose a long time ago, but
> > at present time this code will never be executed since it cannot be built as
> > a module.
>
> Are you sure about definition of __exitcall? As I read init.h the macro
> is defined when it's not a MODULE.
>
> Anyways, if we going to drop that, it should be in a separate change
> explaining all these.
>
Sure. We must drop it too because the initialization no longer happens
in an initcall but is called from elsewhere so - were it not dead code
- we could end up with it being called before the init function.
Bart
© 2016 - 2026 Red Hat, Inc.