[PATCH v4 2/3] driver core: make software nodes available earlier

Andy Shevchenko andriy.shevchenko at linux.intel.com
Tue Mar 31 01:55:43 PDT 2026


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 at 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





More information about the linux-arm-kernel mailing list