[PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770

[PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770

[Bartosz Golaszewski]

This converts Nokia 770 to using real firmware node lookup for GPIOs by
attaching the software nodes describing GPIO controllers to their target
devices.

As determined by Aaro's testing, both omap16xx_gpio_init() and
software_node_init() run in postcore_initcall() so we need to make
software nodes available earlier hence the new patches in v4.

Please note that while the goal of this series is to allow Nokia 770 to
use software nodes earlier, we're not modifying core kernel code just to
accomodate an old ARM platform - more such conversions are coming up so
the change will be useful to more consumers of the software node API.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v4:
- Add patches making software nodes available earlier
- Remove stray newline
- Link to v3: https://lore.kernel.org/all/20260212112508.73500-1-bartosz.golaszewski@oss.qualcomm.com/

Changes in v3:
- fix references to the MPU node

Changes in v2:
- fix build with CONFIG_I2C_CBUS_GPIO
- only export the two symbols that are actually required by the nokia
  board file

---
Bartosz Golaszewski (3):
      kernel: ksysfs: initialize kernel_kobj earlier
      driver core: make software nodes available earlier
      ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

 arch/arm/mach-omap1/board-nokia770.c | 30 +++++-------------------------
 arch/arm/mach-omap1/common.h         |  3 +++
 arch/arm/mach-omap1/gpio16xx.c       | 28 +++++++++++++++++++++++++++-
 drivers/base/base.h                  |  1 +
 drivers/base/init.c                  |  1 +
 drivers/base/swnode.c                | 13 ++-----------
 include/linux/kobject.h              |  2 ++
 init/main.c                          |  1 +
 kernel/ksysfs.c                      |  8 +++-----
 9 files changed, 45 insertions(+), 42 deletions(-)
---
base-commit: e80f5dcc54bf5d494b725e2932571488daac33b8
change-id: 20260330-nokia770-gpio-swnodes-5da8ba35946e

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

[PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier

[Bartosz Golaszewski]

Software nodes depend on kernel_kobj which is initialized pretty late
into the boot process - as a core_initcall(). Ahead of moving the
software node initialization to driver_init() we must first make
kernel_kobj available before it.

Make ksysfs_init() visible in the kobject.h header and call it in
do_basic_setup() right before driver_init().

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 include/linux/kobject.h | 2 ++
 init/main.c             | 1 +
 kernel/ksysfs.c         | 8 +++-----
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
 __printf(2, 3)
 int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
 
+void ksysfs_init(void);
+
 #endif /* _KOBJECT_H_ */
diff --git a/init/main.c b/init/main.c
index 8b7633b7ab720b9c13a231d64291d35d3852602c..1a9046b563e469057cca72ce39a0701c9c4d49e1 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1482,6 +1482,7 @@ static void __init do_initcalls(void)
 static void __init do_basic_setup(void)
 {
 	cpuset_init_smp();
+	ksysfs_init();
 	driver_init();
 	init_irq_proc();
 	do_ctors();
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index a9e6354d9e2579317d3b1bcb54223432d3ce0950..ac546562a6a1202a752de2d36719c6a193520a79 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -213,7 +213,7 @@ static const struct attribute_group kernel_attr_group = {
 	.attrs = kernel_attrs,
 };
 
-static int __init ksysfs_init(void)
+void __init ksysfs_init(void)
 {
 	int error;
 
@@ -234,14 +234,12 @@ static int __init ksysfs_init(void)
 			goto group_exit;
 	}
 
-	return 0;
+	return;
 
 group_exit:
 	sysfs_remove_group(kernel_kobj, &kernel_attr_group);
 kset_exit:
 	kobject_put(kernel_kobj);
 exit:
-	return error;
+	pr_err("failed to initialize the kernel kobject: %d\n", error);
 }
-
-core_initcall(ksysfs_init);

-- 
2.47.3

Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier

[Danilo Krummrich]

On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
>  __printf(2, 3)
>  int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
>  
> +void ksysfs_init(void);

NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
but maybe a separate header would be a better fit.

Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier

[Bartosz Golaszewski]

On Mon, Mar 30, 2026 at 3:47 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> > index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
> > --- a/include/linux/kobject.h
> > +++ b/include/linux/kobject.h
> > @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
> >  __printf(2, 3)
> >  int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
> >
> > +void ksysfs_init(void);
>
> NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
> but maybe a separate header would be a better fit.

Do you mean moving all the top-level kobject declarations
(kernel_kobj, firmware_kobj, etc.) out of kobject.h into this new
header (ksysfs.h?) along with their init functions?

Bart

Re: [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier

[Danilo Krummrich]

On Mon Mar 30, 2026 at 4:19 PM CEST, Bartosz Golaszewski wrote:
> On Mon, Mar 30, 2026 at 3:47 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
>> > diff --git a/include/linux/kobject.h b/include/linux/kobject.h
>> > index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
>> > --- a/include/linux/kobject.h
>> > +++ b/include/linux/kobject.h
>> > @@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
>> >  __printf(2, 3)
>> >  int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
>> >
>> > +void ksysfs_init(void);
>>
>> NIT: I'm aware there's also all the core kobjects in include/linux/kobject.h,
>> but maybe a separate header would be a better fit.
>
> Do you mean moving all the top-level kobject declarations
> (kernel_kobj, firmware_kobj, etc.) out of kobject.h into this new
> header (ksysfs.h?) along with their init functions?

I think the top-level kobjects are fine; it's just ksysfs_init() that somehow
feels odd to me being placed in kobject.h.

The top-level kobject do make sense as they are the base for a lot of other
kobjects being created by other core code.

Whereas ksysfs_init() is a ksysfs specific thing that is only ever used by
init/main.c, i.e. other than the top-level kobjects, it has nothing to do with
the kobject API itself.

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

[Bartosz Golaszewski]

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.3

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

[Andy Shevchenko]

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?

-- 
With Best Regards,
Andy Shevchenko

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

[Dmitry Torokhov]

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

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

[Andy Shevchenko]

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

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

[Dmitry Torokhov]

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

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

[Andy Shevchenko]

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

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

[Bartosz Golaszewski]

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

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

[Arnd Bergmann]

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

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

[Andy Shevchenko]

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

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

[Arnd Bergmann]

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

[PATCH v4 3/3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

Currently the board file for Nokia 770 creates dummy software nodes not
attached in any way to the actual GPIO controller devices and uses the
fact that GPIOLIB matching swnode's name to the GPIO chip's label during
software node lookup. This behavior is wrong and we want to remove it.
To that end, we need to first convert all existing users to creating
actual fwnode links.

Create real software nodes for GPIO controllers on OMAP16xx and
reference them from the software nodes in the nokia board file.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 arch/arm/mach-omap1/board-nokia770.c | 30 +++++-------------------------
 arch/arm/mach-omap1/common.h         |  3 +++
 arch/arm/mach-omap1/gpio16xx.c       | 28 +++++++++++++++++++++++++++-
 3 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index a5bf5554800fe17b430e84ae421ffa8da2bb11a0..46f817f6316b70ff37bb9dfde86c675fd692999b 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -36,25 +36,6 @@
 #include "clock.h"
 #include "mmc.h"
 
-static const struct software_node nokia770_mpuio_gpiochip_node = {
-	.name = "mpuio",
-};
-
-static const struct software_node nokia770_gpiochip1_node = {
-	.name = "gpio-0-15",
-};
-
-static const struct software_node nokia770_gpiochip2_node = {
-	.name = "gpio-16-31",
-};
-
-static const struct software_node *nokia770_gpiochip_nodes[] = {
-	&nokia770_mpuio_gpiochip_node,
-	&nokia770_gpiochip1_node,
-	&nokia770_gpiochip2_node,
-	NULL
-};
-
 #define ADS7846_PENDOWN_GPIO	15
 
 static const unsigned int nokia770_keymap[] = {
@@ -112,7 +93,7 @@ static const struct omap_lcd_config nokia770_lcd_config __initconst = {
 };
 
 static const struct property_entry nokia770_mipid_props[] = {
-	PROPERTY_ENTRY_GPIO("reset-gpios", &nokia770_gpiochip1_node,
+	PROPERTY_ENTRY_GPIO("reset-gpios", &omap16xx_gpio1_swnode,
 			    13, GPIO_ACTIVE_LOW),
 	{ }
 };
@@ -138,7 +119,7 @@ static const struct property_entry nokia770_ads7846_props[] = {
 	PROPERTY_ENTRY_U16("ti,x-plate-ohms", 180),
 	PROPERTY_ENTRY_U16("ti,debounce-tol", 3),
 	PROPERTY_ENTRY_U16("ti,debounce-rep", 1),
-	PROPERTY_ENTRY_GPIO("pendown-gpios", &nokia770_gpiochip1_node,
+	PROPERTY_ENTRY_GPIO("pendown-gpios", &omap16xx_gpio1_swnode,
 			    ADS7846_PENDOWN_GPIO, GPIO_ACTIVE_LOW),
 	{ }
 };
@@ -225,9 +206,9 @@ static inline void nokia770_mmc_init(void)
 #if IS_ENABLED(CONFIG_I2C_CBUS_GPIO)
 
 static const struct software_node_ref_args nokia770_cbus_gpio_refs[] = {
-	SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 9, 0),
-	SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 10, 0),
-	SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 11, 0),
+	SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 9, 0),
+	SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 10, 0),
+	SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 11, 0),
 };
 
 static const struct property_entry nokia770_cbus_props[] = {
@@ -318,7 +299,6 @@ static void __init omap_nokia770_init(void)
 	/* Unmask SleepX signal */
 	omap_writew((omap_readw(0xfffb5004) & ~2), 0xfffb5004);
 
-	software_node_register_node_group(nokia770_gpiochip_nodes);
 	platform_add_devices(nokia770_devices, ARRAY_SIZE(nokia770_devices));
 
 	gpiod_add_lookup_table(&nokia770_irq_gpio_table);
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 7a7c3d9eb84a06c18fbc70e7c94a161b487cd002..c0f6e231fdb4422c5d2c1aa3e33dd6dd99d2710e 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -35,6 +35,9 @@
 #include "soc.h"
 #include "i2c.h"
 
+extern const struct software_node omap16xx_mpu_gpio_swnode;
+extern const struct software_node omap16xx_gpio1_swnode;
+
 #ifdef CONFIG_OMAP_SERIAL_WAKE
 int omap_serial_wakeup_init(void);
 #else
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 55acec22fef4e73f20935473602ef6cb2f4f379c..e371183e0213912ebfa7edd34ca7e7683869ab12 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/platform_data/gpio-omap.h>
+#include <linux/property.h>
 #include <linux/soc/ti/omap1-io.h>
 
 #include "hardware.h"
@@ -55,6 +56,8 @@ static struct omap_gpio_platform_data omap16xx_mpu_gpio_config = {
 	.regs                   = &omap16xx_mpuio_regs,
 };
 
+const struct software_node omap16xx_mpu_gpio_swnode = { };
+
 static struct platform_device omap16xx_mpu_gpio = {
 	.name           = "omap_gpio",
 	.id             = 0,
@@ -99,6 +102,8 @@ static struct omap_gpio_platform_data omap16xx_gpio1_config = {
 	.regs                   = &omap16xx_gpio_regs,
 };
 
+const struct software_node omap16xx_gpio1_swnode = { };
+
 static struct platform_device omap16xx_gpio1 = {
 	.name           = "omap_gpio",
 	.id             = 1,
@@ -122,6 +127,8 @@ static struct resource omap16xx_gpio2_resources[] = {
 	},
 };
 
+static const struct software_node omap16xx_gpio2_swnode = { };
+
 static struct omap_gpio_platform_data omap16xx_gpio2_config = {
 	.bank_width		= 16,
 	.regs                   = &omap16xx_gpio_regs,
@@ -155,6 +162,8 @@ static struct omap_gpio_platform_data omap16xx_gpio3_config = {
 	.regs                   = &omap16xx_gpio_regs,
 };
 
+static const struct software_node omap16xx_gpio3_swnode = { };
+
 static struct platform_device omap16xx_gpio3 = {
 	.name           = "omap_gpio",
 	.id             = 3,
@@ -183,6 +192,8 @@ static struct omap_gpio_platform_data omap16xx_gpio4_config = {
 	.regs                   = &omap16xx_gpio_regs,
 };
 
+static const struct software_node omap16xx_gpio4_swnode = { };
+
 static struct platform_device omap16xx_gpio4 = {
 	.name           = "omap_gpio",
 	.id             = 4,
@@ -201,6 +212,14 @@ static struct platform_device *omap16xx_gpio_dev[] __initdata = {
 	&omap16xx_gpio4,
 };
 
+static const struct software_node *omap16xx_gpio_swnodes[] __initconst = {
+	&omap16xx_mpu_gpio_swnode,
+	&omap16xx_gpio1_swnode,
+	&omap16xx_gpio2_swnode,
+	&omap16xx_gpio3_swnode,
+	&omap16xx_gpio4_swnode,
+};
+
 /*
  * omap16xx_gpio_init needs to be done before
  * machine_init functions access gpio APIs.
@@ -208,7 +227,7 @@ static struct platform_device *omap16xx_gpio_dev[] __initdata = {
  */
 static int __init omap16xx_gpio_init(void)
 {
-	int i;
+	int i, ret;
 	void __iomem *base;
 	struct resource *res;
 	struct platform_device *pdev;
@@ -244,6 +263,13 @@ static int __init omap16xx_gpio_init(void)
 		iounmap(base);
 
 		platform_device_register(omap16xx_gpio_dev[i]);
+
+		ret = device_add_software_node(&omap16xx_gpio_dev[i]->dev,
+					       omap16xx_gpio_swnodes[i]);
+		if (ret) {
+			dev_err(&pdev->dev, "Failed to add software node.\n");
+			return ret;
+		}
 	}
 
 	return 0;

-- 
2.47.3

Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770

[Danilo Krummrich]

On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> Bartosz Golaszewski (3):
>       kernel: ksysfs: initialize kernel_kobj earlier
>       driver core: make software nodes available earlier
>       ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

Looks good to me overall (one minor nit in the first patch); which tree should
this go through?

Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770

[Bartosz Golaszewski]

On Mon, Mar 30, 2026 at 3:37 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > Bartosz Golaszewski (3):
> >       kernel: ksysfs: initialize kernel_kobj earlier
> >       driver core: make software nodes available earlier
> >       ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
>
> Looks good to me overall (one minor nit in the first patch); which tree should
> this go through?

If the first two patches can make v7.1 then I'm fine with postponing
patch 3 until v7.2. Maybe Dmitry's changes allowing passing
unregistered software nodes to new platform devices (where are we with
this?) would also make it in and patch 3/3 could be smaller as a
result.

Bart

Re: [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770

[Bartosz Golaszewski]

On Mon, Mar 30, 2026 at 3:52 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Mon, Mar 30, 2026 at 3:37 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Mon Mar 30, 2026 at 2:40 PM CEST, Bartosz Golaszewski wrote:
> > > Bartosz Golaszewski (3):
> > >       kernel: ksysfs: initialize kernel_kobj earlier
> > >       driver core: make software nodes available earlier
> > >       ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
> >
> > Looks good to me overall (one minor nit in the first patch); which tree should
> > this go through?
>
> If the first two patches can make v7.1 then I'm fine with postponing
> patch 3 until v7.2. Maybe Dmitry's changes allowing passing
> unregistered software nodes to new platform devices (where are we with
> this?) would also make it in and patch 3/3 could be smaller as a
> result.
>

In other words: patches 1 and 2 can go though the driver core tree
into v7.1 and patch 3/3 will be respun next cycle.

Bart