[PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[Dmitry Torokhov]

Using inline compound literals for property entries in software node
initializers causes older compilers (GCC < 14) to fail with "initializer
element is not constant".

Under C11 (6.6/6.7.9), initializers for objects with static storage
duration must be constant expressions. Taking the address of an unnamed
compound literal nested inside an anonymous compound literal array is
not guaranteed by standard C to be a compile-time constant address,
causing older GCC versions to reject it.

Fix this by declaring property entry arrays as named static const
variables, ensuring their symbols evaluate to unambiguous compile-time
address constants.

Fixes: 6905cdac0e51 ("sh: mach-rsk: rsk7203: use static device properties for LEDs and GPIO buttons")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608020345.iCwkQ6oH-lkp@intel.com/
Assisted-by: Antigravity:gemini-3.6-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Fix GCC compilation failure ("initializer element is not constant") on
RSK7203 board by declaring property entry arrays as named static const
variables instead of inline compound literals.
---
 arch/sh/boards/mach-rsk/devices-rsk7203.c | 180 +++++++++++++++++-------------
 1 file changed, 101 insertions(+), 79 deletions(-)

diff --git a/arch/sh/boards/mach-rsk/devices-rsk7203.c b/arch/sh/boards/mach-rsk/devices-rsk7203.c
index e8a8fc1d2ca9..7a2e73bb9645 100644
--- a/arch/sh/boards/mach-rsk/devices-rsk7203.c
+++ b/arch/sh/boards/mach-rsk/devices-rsk7203.c
@@ -42,92 +42,108 @@ static const struct software_node rsk7203_gpio_leds_node = {
 	.name = "rsk7203-gpio-leds",
 };
 
+static const struct property_entry rsk7203_green_led_props[] = {
+	PROPERTY_ENTRY_STRING("label", "green"),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PE10, GPIO_ACTIVE_LOW),
+	{ }
+};
+
 static const struct software_node rsk7203_green_led_node = {
 	.name = "green",
 	.parent = &rsk7203_gpio_leds_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_STRING("label", "green"),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PE10, GPIO_ACTIVE_LOW),
-		{ }
-	},
+	.properties = rsk7203_green_led_props,
+};
+
+static const struct property_entry rsk7203_orange_led_props[] = {
+	PROPERTY_ENTRY_STRING("label", "orange"),
+	PROPERTY_ENTRY_STRING("linux,default-trigger", "nand-disk"),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PE12, GPIO_ACTIVE_LOW),
+	{ }
 };
 
 static const struct software_node rsk7203_orange_led_node = {
 	.name = "orange",
 	.parent = &rsk7203_gpio_leds_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_STRING("label", "orange"),
-		PROPERTY_ENTRY_STRING("linux,default-trigger", "nand-disk"),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PE12, GPIO_ACTIVE_LOW),
-		{ }
-	},
+	.properties = rsk7203_orange_led_props,
+};
+
+static const struct property_entry rsk7203_red1_led_props[] = {
+	PROPERTY_ENTRY_STRING("label", "red:timer"),
+	PROPERTY_ENTRY_STRING("linux,default-trigger", "timer"),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PC14, GPIO_ACTIVE_LOW),
+	{ }
 };
 
 static const struct software_node rsk7203_red1_led_node = {
 	.name = "red:timer",
 	.parent = &rsk7203_gpio_leds_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_STRING("label", "red:timer"),
-		PROPERTY_ENTRY_STRING("linux,default-trigger", "timer"),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PC14, GPIO_ACTIVE_LOW),
-		{ }
-	},
+	.properties = rsk7203_red1_led_props,
+};
+
+static const struct property_entry rsk7203_red2_led_props[] = {
+	PROPERTY_ENTRY_STRING("label", "red:heartbeat"),
+	PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PE11, GPIO_ACTIVE_LOW),
+	{ }
 };
 
 static const struct software_node rsk7203_red2_led_node = {
 	.name = "red:heartbeat",
 	.parent = &rsk7203_gpio_leds_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_STRING("label", "red:heartbeat"),
-		PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PE11, GPIO_ACTIVE_LOW),
-		{ }
-	},
+	.properties = rsk7203_red2_led_props,
+};
+
+static const struct property_entry rsk7203_gpio_keys_props[] = {
+	PROPERTY_ENTRY_U32("poll-interval", 50),
+	{ }
 };
 
 static const struct software_node rsk7203_gpio_keys_node = {
 	.name = "rsk7203-gpio-keys",
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_U32("poll-interval", 50),
-		{ }
-	},
+	.properties = rsk7203_gpio_keys_props,
+};
+
+static const struct property_entry rsk7203_sw1_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", BTN_0),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PB0, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_STRING("label", "SW1"),
+	{ }
 };
 
 static const struct software_node rsk7203_sw1_key_node = {
 	.parent = &rsk7203_gpio_keys_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_U32("linux,code", BTN_0),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PB0, GPIO_ACTIVE_LOW),
-		PROPERTY_ENTRY_STRING("label", "SW1"),
-		{ }
-	},
+	.properties = rsk7203_sw1_key_props,
+};
+
+static const struct property_entry rsk7203_sw2_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", BTN_1),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PB1, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_STRING("label", "SW2"),
+	{ }
 };
 
 static const struct software_node rsk7203_sw2_key_node = {
 	.parent = &rsk7203_gpio_keys_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_U32("linux,code", BTN_1),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PB1, GPIO_ACTIVE_LOW),
-		PROPERTY_ENTRY_STRING("label", "SW2"),
-		{ }
-	},
+	.properties = rsk7203_sw2_key_props,
+};
+
+static const struct property_entry rsk7203_sw3_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", BTN_2),
+	PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
+			    GPIO_PB2, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_STRING("label", "SW3"),
+	{ }
 };
 
 static const struct software_node rsk7203_sw3_key_node = {
 	.parent = &rsk7203_gpio_keys_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_U32("linux,code", BTN_2),
-		PROPERTY_ENTRY_GPIO("gpios", &pfc_gpiochip_node,
-				    GPIO_PB2, GPIO_ACTIVE_LOW),
-		PROPERTY_ENTRY_STRING("label", "SW3"),
-		{ }
-	},
+	.properties = rsk7203_sw3_key_props,
 };
 
 /* The base of the function GPIOs in the flat enum */
@@ -138,46 +154,52 @@ static const struct software_node rsk7203_pfc_functions_node = {
 	.parent = &pfc_gpiochip_node,
 };
 
+static const struct property_entry rsk7203_txd0_hog_props[] = {
+	PROPERTY_ENTRY_BOOL("gpio-hog"),
+	PROPERTY_ENTRY_U32_ARRAY("gpios", ((u32[]){
+		GPIO_FN_TXD0 - SH7203_FN_BASE, GPIO_ACTIVE_HIGH
+	})),
+	PROPERTY_ENTRY_BOOL("input"),
+	PROPERTY_ENTRY_STRING("line-name", "TXD0"),
+	{ }
+};
+
 static const struct software_node rsk7203_txd0_hog_node = {
 	.name = "txd0-hog",
 	.parent = &rsk7203_pfc_functions_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_BOOL("gpio-hog"),
-		PROPERTY_ENTRY_U32_ARRAY("gpios", ((u32[]){
-			GPIO_FN_TXD0 - SH7203_FN_BASE, GPIO_ACTIVE_HIGH
-		})),
-		PROPERTY_ENTRY_BOOL("input"),
-		PROPERTY_ENTRY_STRING("line-name", "TXD0"),
-		{ }
-	},
+	.properties = rsk7203_txd0_hog_props,
+};
+
+static const struct property_entry rsk7203_rxd0_hog_props[] = {
+	PROPERTY_ENTRY_BOOL("gpio-hog"),
+	PROPERTY_ENTRY_U32_ARRAY("gpios", ((u32[]){
+		GPIO_FN_RXD0 - SH7203_FN_BASE, GPIO_ACTIVE_HIGH
+	})),
+	PROPERTY_ENTRY_BOOL("input"),
+	PROPERTY_ENTRY_STRING("line-name", "RXD0"),
+	{ }
 };
 
 static const struct software_node rsk7203_rxd0_hog_node = {
 	.name = "rxd0-hog",
 	.parent = &rsk7203_pfc_functions_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_BOOL("gpio-hog"),
-		PROPERTY_ENTRY_U32_ARRAY("gpios", ((u32[]){
-			GPIO_FN_RXD0 - SH7203_FN_BASE, GPIO_ACTIVE_HIGH
-		})),
-		PROPERTY_ENTRY_BOOL("input"),
-		PROPERTY_ENTRY_STRING("line-name", "RXD0"),
-		{ }
-	},
+	.properties = rsk7203_rxd0_hog_props,
+};
+
+static const struct property_entry rsk7203_irq0_hog_props[] = {
+	PROPERTY_ENTRY_BOOL("gpio-hog"),
+	PROPERTY_ENTRY_U32_ARRAY("gpios", ((u32[]){
+		GPIO_FN_IRQ0_PB - SH7203_FN_BASE, GPIO_ACTIVE_HIGH
+	})),
+	PROPERTY_ENTRY_BOOL("input"),
+	PROPERTY_ENTRY_STRING("line-name", "IRQ0_PB"),
+	{ }
 };
 
 static const struct software_node rsk7203_irq0_hog_node = {
 	.name = "irq0-hog",
 	.parent = &rsk7203_pfc_functions_node,
-	.properties = (const struct property_entry[]) {
-		PROPERTY_ENTRY_BOOL("gpio-hog"),
-		PROPERTY_ENTRY_U32_ARRAY("gpios", ((u32[]){
-			GPIO_FN_IRQ0_PB - SH7203_FN_BASE, GPIO_ACTIVE_HIGH
-		})),
-		PROPERTY_ENTRY_BOOL("input"),
-		PROPERTY_ENTRY_STRING("line-name", "IRQ0_PB"),
-		{ }
-	},
+	.properties = rsk7203_irq0_hog_props,
 };
 
 static const struct software_node * const rsk7203_swnodes[] __initconst = {

---
base-commit: 415606a7be939835db9b0d6b711887586646346d
change-id: 20260802-sh-rsk7203-swnode-props-4365ae1e986d

Thanks.

-- 
Dmitry

Re: [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[John Paul Adrian Glaubitz]

Hello Dmitry,

On Sun, 2026-08-02 at 16:18 -0700, Dmitry Torokhov wrote:
> Using inline compound literals for property entries in software node
> initializers causes older compilers (GCC < 14) to fail with "initializer
> element is not constant".
> 
> Under C11 (6.6/6.7.9), initializers for objects with static storage
> duration must be constant expressions. Taking the address of an unnamed
> compound literal nested inside an anonymous compound literal array is
> not guaranteed by standard C to be a compile-time constant address,
> causing older GCC versions to reject it.
> 
> Fix this by declaring property entry arrays as named static const
> variables, ensuring their symbols evaluate to unambiguous compile-time
> address constants.
> 
> Fixes: 6905cdac0e51 ("sh: mach-rsk: rsk7203: use static device properties for LEDs and GPIO buttons")

Isn't that the patch that was forced into the kernel, overriding me
as the maintainer of arch/sh because Linus Walleij got impatient and
merged the patch into an immutable tree?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[Dmitry Torokhov]

On Mon, Aug 03, 2026 at 07:47:50AM +0200, John Paul Adrian Glaubitz wrote:
> Hello Dmitry,
> 
> On Sun, 2026-08-02 at 16:18 -0700, Dmitry Torokhov wrote:
> > Using inline compound literals for property entries in software node
> > initializers causes older compilers (GCC < 14) to fail with "initializer
> > element is not constant".
> > 
> > Under C11 (6.6/6.7.9), initializers for objects with static storage
> > duration must be constant expressions. Taking the address of an unnamed
> > compound literal nested inside an anonymous compound literal array is
> > not guaranteed by standard C to be a compile-time constant address,
> > causing older GCC versions to reject it.
> > 
> > Fix this by declaring property entry arrays as named static const
> > variables, ensuring their symbols evaluate to unambiguous compile-time
> > address constants.
> > 
> > Fixes: 6905cdac0e51 ("sh: mach-rsk: rsk7203: use static device properties for LEDs and GPIO buttons")
> 
> Isn't that the patch that was forced into the kernel, overriding me
> as the maintainer of arch/sh because Linus Walleij got impatient and
> merged the patch into an immutable tree?

Yes, but incompatibility with older GCCs is not something that you'd
recognize on the spot, would you?

Also, you seem to be hung up on the notion of immutable branch. This is
simply a branch that creator promises not to rewind/rebase so that it
can be easily shared between different subsystems.

While we are at this, there are a few more patch series for SH that I
would like you to take a look at, pretty please...

Thanks.

-- 
Dmitry

Re: [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[John Paul Adrian Glaubitz]

Hi Dmitry,

I apologize for my previous harsh mail, but the way these patches are being
pushed in really puts me under actual stress. There is a second situation like
this now where another kernel maintainer is too impatient.

On Sun, 2026-08-02 at 23:07 -0700, Dmitry Torokhov wrote:
> > Isn't that the patch that was forced into the kernel, overriding me
> > as the maintainer of arch/sh because Linus Walleij got impatient and
> > merged the patch into an immutable tree?
> 
> Yes, but incompatibility with older GCCs is not something that you'd
> recognize on the spot, would you?

No, I wouldn't. But I would have most likely caught it as I'm building the
kernel for my J2 board with a GCC 9.x compiler as I don't have any more
recent GCC version for J2 at the moment.

> Also, you seem to be hung up on the notion of immutable branch. This is
> simply a branch that creator promises not to rewind/rebase so that it
> can be easily shared between different subsystems.

Well, it sounded to me like he wanted to make a point that there isn't going
to be any discussion about this anymore which I really thought was not okay.

> While we are at this, there are a few more patch series for SH that I
> would like you to take a look at, pretty please...

Yes, absolutely. I absolutely appreciate the work, I am just asking for a
little patience. As SuperH maintainer, one of the most important tasks the
past weeks was to get the GCC backend moved to the new register allocator
which is finally done now. GCC upstream is pushing to migrate all backends
to LRA now so it meant that this had highest priority.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[Dmitry Torokhov]

On Mon, Aug 03, 2026 at 08:20:24AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Dmitry,
> 
> I apologize for my previous harsh mail, but the way these patches are being
> pushed in really puts me under actual stress. There is a second situation like
> this now where another kernel maintainer is too impatient.
> 
> On Sun, 2026-08-02 at 23:07 -0700, Dmitry Torokhov wrote:
> > > Isn't that the patch that was forced into the kernel, overriding me
> > > as the maintainer of arch/sh because Linus Walleij got impatient and
> > > merged the patch into an immutable tree?
> > 
> > Yes, but incompatibility with older GCCs is not something that you'd
> > recognize on the spot, would you?
> 
> No, I wouldn't. But I would have most likely caught it as I'm building the
> kernel for my J2 board with a GCC 9.x compiler as I don't have any more
> recent GCC version for J2 at the moment.
> 
> > Also, you seem to be hung up on the notion of immutable branch. This is
> > simply a branch that creator promises not to rewind/rebase so that it
> > can be easily shared between different subsystems.
> 
> Well, it sounded to me like he wanted to make a point that there isn't going
> to be any discussion about this anymore which I really thought was not okay.

No, not at all. Again, it is just for ease of sharing and promise that
git will not generate conflicts if multiple trees pull it in.

> 
> > While we are at this, there are a few more patch series for SH that I
> > would like you to take a look at, pretty please...
> 
> Yes, absolutely. I absolutely appreciate the work, I am just asking for a
> little patience. As SuperH maintainer, one of the most important tasks the
> past weeks was to get the GCC backend moved to the new register allocator
> which is finally done now. GCC upstream is pushing to migrate all backends
> to LRA now so it meant that this had highest priority.

I totally understand, and thank you for your work.

Thanks.

-- 
Dmitry

Re: [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals

[Linus Walleij]

On Mon, Aug 3, 2026 at 8:20 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:

> > Also, you seem to be hung up on the notion of immutable branch. This is
> > simply a branch that creator promises not to rewind/rebase so that it
> > can be easily shared between different subsystems.
>
> Well, it sounded to me like he wanted to make a point that there isn't going
> to be any discussion about this anymore which I really thought was not okay.

Not at all.

If you read my previous mail there are many options, one being for
me to just revert this out, all you need to do is tell me you need
more time and I will do that.

https://lore.kernel.org/lkml/CAD++jLnC0eZbJa4hyTQkeJ214miahcAFhH42X+JkxxTbDo=5TA@mail.gmail.com/

There are 3 practical options:

1. (easiest): tell me to just revert this out of my tree.
 Deal with this whole ordeal later.

2. Pull in the immutable branch into you SH tree and
 apply this patch on top.

3. Ask me to apply the patch to my tree.

Either works for me.

Yours,
Linus Walleij