[RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[RFT PATCH v3] 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.

Signed-off-by: Bartosz Golaszewski <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

This is a follow up to the following discussion[1]. I don't have the
hardware for testing so only build-tested it.

[1] https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/

 arch/arm/mach-omap1/board-nokia770.c | 30 +++++-----------------------
 arch/arm/mach-omap1/common.h         |  3 +++
 arch/arm/mach-omap1/gpio16xx.c       | 29 ++++++++++++++++++++++++++-
 3 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index a5bf5554800fe..46f817f6316b7 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 7a7c3d9eb84a0..c0f6e231fdb44 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 55acec22fef4e..177621cb47844 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,14 @@ 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: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Arnd Bergmann]

On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> 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.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > 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.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Aaro, Janusz: Can you please pick it up for v7.1?

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Kevin Hilman]

Bartosz Golaszewski <brgl@kernel.org> writes:

> On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
>>
>> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
>> > 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.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Aaro, Janusz: Can you please pick it up for v7.1?

I can take this via the OMAP tree once I have confirmation from
Aaro/Janusz that they've tested.

Kevin

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
>
> Bartosz Golaszewski <brgl@kernel.org> writes:
>
> > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >>
> >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> >> > 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.
> >> >
> >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >>
> >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Aaro, Janusz: Can you please pick it up for v7.1?
>
> I can take this via the OMAP tree once I have confirmation from
> Aaro/Janusz that they've tested.
>
> Kevin

Gentle ping.

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Mon, Mar 16, 2026 at 9:50 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
> >
> > Bartosz Golaszewski <brgl@kernel.org> writes:
> >
> > > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >>
> > >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > >> > 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.
> > >> >
> > >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >>
> > >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Aaro, Janusz: Can you please pick it up for v7.1?
> >
> > I can take this via the OMAP tree once I have confirmation from
> > Aaro/Janusz that they've tested.
> >
> > Kevin
>
> Gentle ping.
>
> Bart

Hi again! Any chance we could get this queued? Janusz, Aaro: any objections?

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Janusz Krzysztofik]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

Hi Bart,

On Thursday, 26 March 2026 09:57:31 CET Bartosz Golaszewski wrote:
> On Mon, Mar 16, 2026 at 9:50 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >
> > On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
> > >
> > > Bartosz Golaszewski <brgl@kernel.org> writes:
> > >
> > > > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > >>
> > > >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > > >> > 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.
> > > >> >
> > > >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > >>
> > > >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > >
> > > > Aaro, Janusz: Can you please pick it up for v7.1?
> > >
> > > I can take this via the OMAP tree once I have confirmation from
> > > Aaro/Janusz that they've tested.
> > >
> > > Kevin
> >
> > Gentle ping.
> >
> > Bart
> 
> Hi again! Any chance we could get this queued? Janusz, Aaro: any objections?

I'm not able to restore my test environment right now, sorry.
However, the change looks harmless to me.

Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>

Thanks,
Janusz

> 
> Bart
> 


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Aaro Koskinen]

Hi,

On Thu, Mar 26, 2026 at 09:57:31AM +0100, Bartosz Golaszewski wrote:
> On Mon, Mar 16, 2026 at 9:50 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
> > > Bartosz Golaszewski <brgl@kernel.org> writes:
> > > > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > > >> > 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.
> > > >> >
> > > >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > >>
> > > >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > >
> > > > Aaro, Janusz: Can you please pick it up for v7.1?
> > >
> > > I can take this via the OMAP tree once I have confirmation from
> > > Aaro/Janusz that they've tested.
> 
> Hi again! Any chance we could get this queued? Janusz, Aaro: any objections?

Unfortunately the patch doesn't work - 770 just dies silently. This
means that e.g. CBUS GPIOs are not working as those are needed to keep
the device powered. I'll try to figure out how to debug this...

A.

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Fri, Mar 27, 2026 at 3:05 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> Hi,
>
> On Thu, Mar 26, 2026 at 09:57:31AM +0100, Bartosz Golaszewski wrote:
> > On Mon, Mar 16, 2026 at 9:50 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
> > > > Bartosz Golaszewski <brgl@kernel.org> writes:
> > > > > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > > > >> > 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.
> > > > >> >
> > > > >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > >>
> > > > >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > > >
> > > > > Aaro, Janusz: Can you please pick it up for v7.1?
> > > >
> > > > I can take this via the OMAP tree once I have confirmation from
> > > > Aaro/Janusz that they've tested.
> >
> > Hi again! Any chance we could get this queued? Janusz, Aaro: any objections?
>
> Unfortunately the patch doesn't work - 770 just dies silently. This
> means that e.g. CBUS GPIOs are not working as those are needed to keep
> the device powered. I'll try to figure out how to debug this...
>
> A.

Hmm, I'm wondering if there's a race with consumers already requesting
the GPIOs after the controller device is registered but before the
software node is added. I'll send a version with software nodes being
registered first, then passes as firmware nodes to the platform device
API before the device is registered.

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Aaro Koskinen]

Hi,

On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> Hmm, I'm wondering if there's a race with consumers already requesting
> the GPIOs after the controller device is registered but before the
> software node is added. I'll send a version with software nodes being
> registered first, then passes as firmware nodes to the platform device
> API before the device is registered.

It crashes early, I was able to get an UART log from OSK (another
16xx board):

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 7.0.0-rc5-osk-00010-g9a0a87d27dc0 (aakoskin@lonestar) (arm-linux-gnueabi-gcc (GCC) 13.4.0, GNU ld (GNU Binutils) 2.45) #1 2026-03-26
[    0.000000] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: TI-OSK
[    0.000000] Ignoring tag cmdline (using the default kernel command line)
[    0.000000] printk: legacy bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writeback
[    0.000000] OMAP1611b revision 2 handled as 16xx id: 8d058f7948920905
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000010000000-0x0000000011ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000010000000-0x0000000011ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x0000000011ffffff]
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Kernel command line: mem=32M console=ttyS0,115200 earlyprintk initcall_debug loglevel=9
[    0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[    0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8192
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] Total of 128 interrupts in 4 interrupt banks
[    0.000000] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000
[    0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/96.0/96.0 MHz
[    0.000000] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000030] sched_clock: 32 bits at 33kHz, resolution 30517ns, wraps every 65535999984741ns
[    0.008880] OMAP clocksource: 32k_counter at 32768 Hz
[    0.015106] Calibrating delay loop... 47.51 BogoMIPS (lpj=237568)
[    0.130798] CPU: Testing write buffer coherency: ok
[    0.137451] pid_max: default: 32768 minimum: 301
[    0.144683] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.152648] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.166381] VFS: Finished mounting rootfs on nullfs
[    0.197753] entering initcall level: early
[    0.202270] calling  allocate_overflow_stacks+0x0/0x50 @ 1
[    0.209045] initcall allocate_overflow_stacks+0x0/0x50 returned 0 after 0 usecs
[    0.217315] calling  init_static_idmap+0x0/0x118 @ 1
[    0.223144] Setting up static identity map for 0x10008400 - 0x1000843c
[    0.230438] initcall init_static_idmap+0x0/0x118 returned 0 after 10000 usecs
[    0.238555] calling  spawn_ksoftirqd+0x0/0x70 @ 1
[    0.246643] initcall spawn_ksoftirqd+0x0/0x70 returned 0 after 10000 usecs
[    0.254516] calling  init_signal_sysctls+0x0/0x4c @ 1
[    0.260589] initcall init_signal_sysctls+0x0/0x4c returned 0 after 0 usecs
[    0.268432] calling  init_umh_sysctls+0x0/0x2c @ 1
[    0.274139] initcall init_umh_sysctls+0x0/0x2c returned 0 after 10000 usecs
[    0.281799] calling  kthreads_init+0x0/0x34 @ 1
[    0.287139] initcall kthreads_init+0x0/0x34 returned 0 after 0 usecs
[    0.294372] calling  migration_init+0x0/0x2c @ 1
[    0.299560] initcall migration_init+0x0/0x2c returned 0 after 0 usecs
[    0.306823] calling  printk_set_kthreads_ready+0x0/0x34 @ 1
[    0.312957] initcall printk_set_kthreads_ready+0x0/0x34 returned 0 after 0 usecs
[    0.321105] calling  irq_work_init_threads+0x0/0x8 @ 1
[    0.326995] initcall irq_work_init_threads+0x0/0x8 returned 0 after 0 usecs
[    0.334777] calling  init_zero_pfn+0x0/0x2c @ 1
[    0.339813] initcall init_zero_pfn+0x0/0x2c returned 0 after 0 usecs
[    0.346954] calling  init_fs_inode_sysctls+0x0/0x2c @ 1
[    0.352874] initcall init_fs_inode_sysctls+0x0/0x2c returned 0 after 0 usecs
[    0.360809] calling  init_fs_locks_sysctls+0x0/0x2c @ 1
[    0.366943] initcall init_fs_locks_sysctls+0x0/0x2c returned 0 after 0 usecs
[    0.374938] calling  init_fs_sysctls+0x0/0x2c @ 1
[    0.380310] initcall init_fs_sysctls+0x0/0x2c returned 0 after 0 usecs
[    0.389282] Memory: 24296K/32768K available (4054K kernel code, 525K rwdata, 888K rodata, 1688K init, 197K bss, 7868K reserved, 0K cma-reserved)
[    0.408447] devtmpfs: initialized
[    0.428741] entering initcall level: pure
[    0.433135] calling  ipc_ns_init+0x0/0x40 @ 1
[    0.438537] initcall ipc_ns_init+0x0/0x40 returned 0 after 0 usecs
[    0.445617] calling  mmap_min_addr_init+0x0/0x44 @ 1
[    0.451202] initcall mmap_min_addr_init+0x0/0x44 returned 0 after 0 usecs
[    0.458801] calling  pci_realloc_setup_params+0x0/0x48 @ 1
[    0.465057] initcall pci_realloc_setup_params+0x0/0x48 returned 0 after 0 usecs
[    0.472991] calling  inet_frag_wq_init+0x0/0x4c @ 1
[    0.480957] initcall inet_frag_wq_init+0x0/0x4c returned 0 after 0 usecs
[    0.489318] entering initcall level: core
[    0.493927] calling  ptrace_break_init+0x0/0x2c @ 1
[    0.499328] initcall ptrace_break_init+0x0/0x2c returned 0 after 0 usecs
[    0.506805] calling  omap1_pm_runtime_init+0x0/0x20 @ 1
[    0.513122] initcall omap1_pm_runtime_init+0x0/0x20 returned 0 after 0 usecs
[    0.521118] calling  wq_sysfs_init+0x0/0x14 @ 1
[    0.527404] initcall wq_sysfs_init+0x0/0x14 returned 0 after 0 usecs
[    0.534698] calling  ksysfs_init+0x0/0x9c @ 1
[    0.540008] initcall ksysfs_init+0x0/0x9c returned 0 after 0 usecs
[    0.547088] calling  init_jiffies_clocksource+0x0/0x14 @ 1
[    0.553131] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.564086] initcall init_jiffies_clocksource+0x0/0x14 returned 0 after 20000 usecs
[    0.572387] calling  posixtimer_init+0x0/0xd4 @ 1
[    0.578155] posixtimers hash table entries: 512 (order: 0, 2048 bytes, linear)
[    0.586212] initcall posixtimer_init+0x0/0xd4 returned 0 after 10000 usecs
[    0.593994] calling  futex_init+0x0/0xa0 @ 1
[    0.598876] futex hash table entries: 256 (4096 bytes on 1 NUMA nodes, total 4 KiB, linear).
[    0.608123] initcall futex_init+0x0/0xa0 returned 0 after 10000 usecs
[    0.615386] calling  cgroup_wq_init+0x0/0x78 @ 1
[    0.620819] initcall cgroup_wq_init+0x0/0x78 returned 0 after 0 usecs
[    0.628112] calling  cgroup1_wq_init+0x0/0x38 @ 1
[    0.633758] initcall cgroup1_wq_init+0x0/0x38 returned 0 after 0 usecs
[    0.640899] calling  fsnotify_init+0x0/0x30 @ 1
[    0.646606] initcall fsnotify_init+0x0/0x30 returned 0 after 0 usecs
[    0.653961] calling  filelock_init+0x0/0xf8 @ 1
[    0.659484] initcall filelock_init+0x0/0xf8 returned 0 after 0 usecs
[    0.666839] calling  init_script_binfmt+0x0/0x1c @ 1
[    0.672393] initcall init_script_binfmt+0x0/0x1c returned 0 after 0 usecs
[    0.680114] calling  init_elf_binfmt+0x0/0x1c @ 1
[    0.685699] initcall init_elf_binfmt+0x0/0x1c returned 0 after 0 usecs
[    0.692901] calling  gpiolib_dev_init+0x0/0x110 @ 1
[    0.699584] initcall gpiolib_dev_init+0x0/0x110 returned 0 after 0 usecs
[    0.707244] calling  sock_init+0x0/0x108 @ 1
[    0.714630] initcall sock_init+0x0/0x108 returned 0 after 10000 usecs
[    0.721862] calling  sock_struct_check+0x0/0x8 @ 1
[    0.727539] initcall sock_struct_check+0x0/0x8 returned 0 after 0 usecs
[    0.735107] calling  net_inuse_init+0x0/0x24 @ 1
[    0.740417] initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs
[    0.747802] calling  init_default_flow_dissectors+0x0/0x4c @ 1
[    0.754577] initcall init_default_flow_dissectors+0x0/0x4c returned 0 after 0 usecs
[    0.763244] calling  netlink_proto_init+0x0/0xf8 @ 1
[    0.774932] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.781799] initcall netlink_proto_init+0x0/0xf8 returned 0 after 10000 usecs
[    0.789947] calling  genl_init+0x0/0x38 @ 1
[    0.795166] initcall genl_init+0x0/0x38 returned 0 after 0 usecs
[    0.802490] entering initcall level: postcore
[    0.807495] calling  atomic_pool_init+0x0/0x134 @ 1
[    0.816711] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.824401] initcall atomic_pool_init+0x0/0x134 returned 0 after 10000 usecs
[    0.832092] calling  omap16xx_gpio_init+0x0/0xe4 @ 1
[    0.838867] 8<--- cut here ---
[    0.842224] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[    0.851989] [00000000] *pgd=00000000
[    0.856262] Internal error: Oops: 5 [#1] ARM
[    0.860931] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5-osk-00010-g9a0a87d27dc0 #1 VOLUNTARY 
[    0.871368] Hardware name: TI-OSK
[    0.874938] PC is at software_node_to_swnode+0x10/0x48
[    0.880554] LR is at device_add_software_node+0x20/0x80
[    0.886230] pc : [<c0273f10>]    lr : [<c0274f20>]    psr: a0000053
[    0.892883] sp : c2809ed0  ip : c2809d94  fp : c052e6ec
[    0.898437] r10: 00000000  r9 : 00000014  r8 : c052bae8
[    0.903991] r7 : 00000005  r6 : c03fe9d4  r5 : c06b3ab0  r4 : c072d000
[    0.910919] r3 : c0759b10  r2 : 00000000  r1 : c03fe9d4  r0 : c03fe9d4
[    0.917846] Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
[    0.925506] Control: 0005317f  Table: 10004000  DAC: 00000053
[    0.931579] Register r0 information: non-slab/vmalloc memory
[    0.937713] Register r1 information: non-slab/vmalloc memory
[    0.943786] Register r2 information: NULL pointer
[    0.948883] Register r3 information: non-slab/vmalloc memory
[    0.954956] Register r4 information: non-slab/vmalloc memory
[    0.961029] Register r5 information: non-slab/vmalloc memory
[    0.967132] Register r6 information: non-slab/vmalloc memory
[    0.973205] Register r7 information: non-paged memory
[    0.978637] Register r8 information: non-slab/vmalloc memory
[    0.984710] Register r9 information: non-paged memory
[    0.990173] Register r10 information: NULL pointer
[    0.995330] Register r11 information: non-slab/vmalloc memory
[    1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
[    1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
[    1.019500] Stack: (0xc2809ed0 to 0xc280a000)
[    1.024230] 9ec0:                                     c072d000 c0529474 c06b3aa0 c050a3cc
[    1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
[    1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
[    1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
[    1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
[    1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
[    1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
[    1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
[    1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    1.111206] Call trace: 
[    1.111328]  software_node_to_swnode from device_add_software_node+0x20/0x80
[    1.121704]  device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
[    1.128997]  omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
[    1.135620]  do_one_initcall from kernel_init_freeable+0x1ec/0x240
[    1.142517]  kernel_init_freeable from kernel_init+0x10/0x108
[    1.148864]  kernel_init from ret_from_fork+0x14/0x28
[    1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
[    1.159820] 9fa0:                                     00000000 00000000 00000000 00000000
[    1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000) 
[    1.191040] ---[ end trace 0000000000000000 ]---
[    1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

A.

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> Hi,
>
> On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> > Hmm, I'm wondering if there's a race with consumers already requesting
> > the GPIOs after the controller device is registered but before the
> > software node is added. I'll send a version with software nodes being
> > registered first, then passes as firmware nodes to the platform device
> > API before the device is registered.
>
> It crashes early, I was able to get an UART log from OSK (another
> 16xx board):
>
> [    1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
> [    1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> [    1.019500] Stack: (0xc2809ed0 to 0xc280a000)
> [    1.024230] 9ec0:                                     c072d000 c0529474 c06b3aa0 c050a3cc
> [    1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
> [    1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
> [    1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
> [    1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
> [    1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
> [    1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
> [    1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
> [    1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [    1.111206] Call trace:
> [    1.111328]  software_node_to_swnode from device_add_software_node+0x20/0x80
> [    1.121704]  device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
> [    1.128997]  omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
> [    1.135620]  do_one_initcall from kernel_init_freeable+0x1ec/0x240
> [    1.142517]  kernel_init_freeable from kernel_init+0x10/0x108
> [    1.148864]  kernel_init from ret_from_fork+0x14/0x28
> [    1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
> [    1.159820] 9fa0:                                     00000000 00000000 00000000 00000000
> [    1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
> [    1.191040] ---[ end trace 0000000000000000 ]---
> [    1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>

Thanks. This makes sense. Both omap16xx_gpio_init() and
software_node_init() run as postcore_initcall() so if the order is not
right, it will fail.

Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
reason to run software_node_init() as a postcore initcall? It only
allocates the kset, can we move it to core_initcall() by any chance?

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Fri, 27 Mar 2026 18:23:29 +0100, Bartosz Golaszewski <brgl@kernel.org> said:
> On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>>
>> Hi,
>>
>> On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
>> > Hmm, I'm wondering if there's a race with consumers already requesting
>> > the GPIOs after the controller device is registered but before the
>> > software node is added. I'll send a version with software nodes being
>> > registered first, then passes as firmware nodes to the platform device
>> > API before the device is registered.
>>
>> It crashes early, I was able to get an UART log from OSK (another
>> 16xx board):
>>
>> [    1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
>> [    1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>> [    1.019500] Stack: (0xc2809ed0 to 0xc280a000)
>> [    1.024230] 9ec0:                                     c072d000 c0529474 c06b3aa0 c050a3cc
>> [    1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
>> [    1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
>> [    1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
>> [    1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
>> [    1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
>> [    1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
>> [    1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
>> [    1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [    1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
>> [    1.111206] Call trace:
>> [    1.111328]  software_node_to_swnode from device_add_software_node+0x20/0x80
>> [    1.121704]  device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
>> [    1.128997]  omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
>> [    1.135620]  do_one_initcall from kernel_init_freeable+0x1ec/0x240
>> [    1.142517]  kernel_init_freeable from kernel_init+0x10/0x108
>> [    1.148864]  kernel_init from ret_from_fork+0x14/0x28
>> [    1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
>> [    1.159820] 9fa0:                                     00000000 00000000 00000000 00000000
>> [    1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [    1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> [    1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
>> [    1.191040] ---[ end trace 0000000000000000 ]---
>> [    1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> [    1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>
>
> Thanks. This makes sense. Both omap16xx_gpio_init() and
> software_node_init() run as postcore_initcall() so if the order is not
> right, it will fail.
>
> Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> reason to run software_node_init() as a postcore initcall? It only
> allocates the kset, can we move it to core_initcall() by any chance?
>
> Bart
>

In any case, Aaro: the following should theoretically fix it:

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9..5ba904f8a08a 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -1134,7 +1134,7 @@ static int __init software_node_init(void)
 		return -ENOMEM;
 	return 0;
 }
-postcore_initcall(software_node_init);
+core_initcall(software_node_init);

 static void __exit software_node_exit(void)
 {

If you could give it a spin and let me know if it does, it would be awesome.

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Dmitry Torokhov]

On Fri, Mar 27, 2026 at 10:27:07AM -0700, Bartosz Golaszewski wrote:
> On Fri, 27 Mar 2026 18:23:29 +0100, Bartosz Golaszewski <brgl@kernel.org> said:
> > On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> >> > Hmm, I'm wondering if there's a race with consumers already requesting
> >> > the GPIOs after the controller device is registered but before the
> >> > software node is added. I'll send a version with software nodes being
> >> > registered first, then passes as firmware nodes to the platform device
> >> > API before the device is registered.
> >>
> >> It crashes early, I was able to get an UART log from OSK (another
> >> 16xx board):
> >>
> >> [    1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
> >> [    1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> >> [    1.019500] Stack: (0xc2809ed0 to 0xc280a000)
> >> [    1.024230] 9ec0:                                     c072d000 c0529474 c06b3aa0 c050a3cc
> >> [    1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
> >> [    1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
> >> [    1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
> >> [    1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
> >> [    1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
> >> [    1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
> >> [    1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
> >> [    1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> >> [    1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> >> [    1.111206] Call trace:
> >> [    1.111328]  software_node_to_swnode from device_add_software_node+0x20/0x80
> >> [    1.121704]  device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
> >> [    1.128997]  omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
> >> [    1.135620]  do_one_initcall from kernel_init_freeable+0x1ec/0x240
> >> [    1.142517]  kernel_init_freeable from kernel_init+0x10/0x108
> >> [    1.148864]  kernel_init from ret_from_fork+0x14/0x28
> >> [    1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
> >> [    1.159820] 9fa0:                                     00000000 00000000 00000000 00000000
> >> [    1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> >> [    1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> >> [    1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
> >> [    1.191040] ---[ end trace 0000000000000000 ]---
> >> [    1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >> [    1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> >>
> >
> > Thanks. This makes sense. Both omap16xx_gpio_init() and
> > software_node_init() run as postcore_initcall() so if the order is not
> > right, it will fail.
> >
> > Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> > reason to run software_node_init() as a postcore initcall? It only
> > allocates the kset, can we move it to core_initcall() by any chance?
> >
> > Bart
> >
> 
> In any case, Aaro: the following should theoretically fix it:
> 
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 51320837f3a9..5ba904f8a08a 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -1134,7 +1134,7 @@ static int __init software_node_init(void)
>  		return -ENOMEM;
>  	return 0;
>  }
> -postcore_initcall(software_node_init);
> +core_initcall(software_node_init);

This is wrong direction IMO. The matching by label is working now, so
there is no reason to rush this change into the kernel, it is simply a
cleanup.

Wait until the resolution of my pact allowing using node names, or your
proposal that installs and attaches nodes dynamically based on bus
notifiers (or both) and then make the conversion. Then you will not need
to move init order around, add new dependencies between drivers, and so
on.

Thanks.

-- 
Dmitry

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Bartosz Golaszewski]

On Fri, 27 Mar 2026 19:16:41 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> On Fri, Mar 27, 2026 at 10:27:07AM -0700, Bartosz Golaszewski wrote:
>> On Fri, 27 Mar 2026 18:23:29 +0100, Bartosz Golaszewski <brgl@kernel.org> said:
>> > On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
>> >> > Hmm, I'm wondering if there's a race with consumers already requesting
>> >> > the GPIOs after the controller device is registered but before the
>> >> > software node is added. I'll send a version with software nodes being
>> >> > registered first, then passes as firmware nodes to the platform device
>> >> > API before the device is registered.
>> >>
>> >> It crashes early, I was able to get an UART log from OSK (another
>> >> 16xx board):
>> >>
>> >> [    1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
>> >> [    1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>> >> [    1.019500] Stack: (0xc2809ed0 to 0xc280a000)
>> >> [    1.024230] 9ec0:                                     c072d000 c0529474 c06b3aa0 c050a3cc
>> >> [    1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
>> >> [    1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
>> >> [    1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
>> >> [    1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
>> >> [    1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
>> >> [    1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
>> >> [    1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
>> >> [    1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >> [    1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
>> >> [    1.111206] Call trace:
>> >> [    1.111328]  software_node_to_swnode from device_add_software_node+0x20/0x80
>> >> [    1.121704]  device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
>> >> [    1.128997]  omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
>> >> [    1.135620]  do_one_initcall from kernel_init_freeable+0x1ec/0x240
>> >> [    1.142517]  kernel_init_freeable from kernel_init+0x10/0x108
>> >> [    1.148864]  kernel_init from ret_from_fork+0x14/0x28
>> >> [    1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
>> >> [    1.159820] 9fa0:                                     00000000 00000000 00000000 00000000
>> >> [    1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >> [    1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> >> [    1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
>> >> [    1.191040] ---[ end trace 0000000000000000 ]---
>> >> [    1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> >> [    1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>> >>
>> >
>> > Thanks. This makes sense. Both omap16xx_gpio_init() and
>> > software_node_init() run as postcore_initcall() so if the order is not
>> > right, it will fail.
>> >
>> > Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
>> > reason to run software_node_init() as a postcore initcall? It only
>> > allocates the kset, can we move it to core_initcall() by any chance?
>> >
>> > Bart
>> >
>>
>> In any case, Aaro: the following should theoretically fix it:
>>
>> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
>> index 51320837f3a9..5ba904f8a08a 100644
>> --- a/drivers/base/swnode.c
>> +++ b/drivers/base/swnode.c
>> @@ -1134,7 +1134,7 @@ static int __init software_node_init(void)
>>  		return -ENOMEM;
>>  	return 0;
>>  }
>> -postcore_initcall(software_node_init);
>> +core_initcall(software_node_init);
>
> This is wrong direction IMO. The matching by label is working now, so
> there is no reason to rush this change into the kernel, it is simply a
> cleanup.
>
> Wait until the resolution of my pact allowing using node names, or your
> proposal that installs and attaches nodes dynamically based on bus
> notifiers (or both) and then make the conversion. Then you will not need
> to move init order around, add new dependencies between drivers, and so
> on.
>

Hi Dmitry,

I'm not rushing anything. It's fine to delay this for now. But the new solution
you're mentioning (whatever it will end up to be) is something we should use
when there's only a lose link between the supplier and consumer. Here both the
GPIO controller and the consumer are instantiated from a board file and are
built-in so there's no link-order problem and we can directly reference one
software node from another. It's a different kind of problem.

I'd like to figure out whether software nodes are not made available too late
into the boot process for no reason and if maybe it makes sense to initialize
them earlier.

Bart

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Aaro Koskinen]

Hi,

On Fri, Mar 27, 2026 at 10:27:07AM -0700, Bartosz Golaszewski wrote:
> > Thanks. This makes sense. Both omap16xx_gpio_init() and
> > software_node_init() run as postcore_initcall() so if the order is not
> > right, it will fail.
> >
> > Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> > reason to run software_node_init() as a postcore initcall? It only
> > allocates the kset, can we move it to core_initcall() by any chance?
> 
> In any case, Aaro: the following should theoretically fix it:
> 
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 51320837f3a9..5ba904f8a08a 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -1134,7 +1134,7 @@ static int __init software_node_init(void)
>  		return -ENOMEM;
>  	return 0;
>  }
> -postcore_initcall(software_node_init);
> +core_initcall(software_node_init);
> 
>  static void __exit software_node_exit(void)
>  {
> 
> If you could give it a spin and let me know if it does, it would be awesome.

Yeah it helps. With that change, both OSK and 770 work with your patch.

A.

Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770

[Dmitry Torokhov]

On Fri, Mar 27, 2026 at 11:26:02AM -0700, Bartosz Golaszewski wrote:
> On Fri, 27 Mar 2026 19:16:41 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> said:
> > On Fri, Mar 27, 2026 at 10:27:07AM -0700, Bartosz Golaszewski wrote:
> >> On Fri, 27 Mar 2026 18:23:29 +0100, Bartosz Golaszewski <brgl@kernel.org> said:
> >> > On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> >> >> > Hmm, I'm wondering if there's a race with consumers already requesting
> >> >> > the GPIOs after the controller device is registered but before the
> >> >> > software node is added. I'll send a version with software nodes being
> >> >> > registered first, then passes as firmware nodes to the platform device
> >> >> > API before the device is registered.
> >> >>
> >> >> It crashes early, I was able to get an UART log from OSK (another
> >> >> 16xx board):
> >> >>
> >> >> [    1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
> >> >> [    1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> >> >> [    1.019500] Stack: (0xc2809ed0 to 0xc280a000)
> >> >> [    1.024230] 9ec0:                                     c072d000 c0529474 c06b3aa0 c050a3cc
> >> >> [    1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
> >> >> [    1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
> >> >> [    1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
> >> >> [    1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
> >> >> [    1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
> >> >> [    1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
> >> >> [    1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
> >> >> [    1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> >> >> [    1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> >> >> [    1.111206] Call trace:
> >> >> [    1.111328]  software_node_to_swnode from device_add_software_node+0x20/0x80
> >> >> [    1.121704]  device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
> >> >> [    1.128997]  omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
> >> >> [    1.135620]  do_one_initcall from kernel_init_freeable+0x1ec/0x240
> >> >> [    1.142517]  kernel_init_freeable from kernel_init+0x10/0x108
> >> >> [    1.148864]  kernel_init from ret_from_fork+0x14/0x28
> >> >> [    1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
> >> >> [    1.159820] 9fa0:                                     00000000 00000000 00000000 00000000
> >> >> [    1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> >> >> [    1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> >> >> [    1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
> >> >> [    1.191040] ---[ end trace 0000000000000000 ]---
> >> >> [    1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >> >> [    1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> >> >>
> >> >
> >> > Thanks. This makes sense. Both omap16xx_gpio_init() and
> >> > software_node_init() run as postcore_initcall() so if the order is not
> >> > right, it will fail.
> >> >
> >> > Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> >> > reason to run software_node_init() as a postcore initcall? It only
> >> > allocates the kset, can we move it to core_initcall() by any chance?
> >> >
> >> > Bart
> >> >
> >>
> >> In any case, Aaro: the following should theoretically fix it:
> >>
> >> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> >> index 51320837f3a9..5ba904f8a08a 100644
> >> --- a/drivers/base/swnode.c
> >> +++ b/drivers/base/swnode.c
> >> @@ -1134,7 +1134,7 @@ static int __init software_node_init(void)
> >>  		return -ENOMEM;
> >>  	return 0;
> >>  }
> >> -postcore_initcall(software_node_init);
> >> +core_initcall(software_node_init);
> >
> > This is wrong direction IMO. The matching by label is working now, so
> > there is no reason to rush this change into the kernel, it is simply a
> > cleanup.
> >
> > Wait until the resolution of my pact allowing using node names, or your
> > proposal that installs and attaches nodes dynamically based on bus
> > notifiers (or both) and then make the conversion. Then you will not need
> > to move init order around, add new dependencies between drivers, and so
> > on.
> >
> 
> Hi Dmitry,
> 
> I'm not rushing anything. It's fine to delay this for now. But the new solution
> you're mentioning (whatever it will end up to be) is something we should use
> when there's only a lose link between the supplier and consumer. Here both the
> GPIO controller and the consumer are instantiated from a board file and are
> built-in so there's no link-order problem and we can directly reference one
> software node from another. It's a different kind of problem.
> 
> I'd like to figure out whether software nodes are not made available too late
> into the boot process for no reason and if maybe it makes sense to initialize
> them earlier.

Actually you are right. I wonder if we should not stuff the call to
initialize software nodes into the same place we are calling
of_core_init(): drivers/base/init.c:driver_init().

Thanks.

-- 
Dmitry