[PATCH] net: dsa: rtl8366rb: Fix compilation problem

[PATCH] net: dsa: rtl8366rb: Fix compilation problem

[Linus Walleij]

When the kernel is compiled without LED framework support the
rtl8366rb fails to build like this:

rtl8366rb.o: in function `rtl8366rb_setup_led':
rtl8366rb.c:953:(.text.unlikely.rtl8366rb_setup_led+0xe8):
  undefined reference to `led_init_default_state_get'
rtl8366rb.c:980:(.text.unlikely.rtl8366rb_setup_led+0x240):
  undefined reference to `devm_led_classdev_register_ext'

As this is constantly coming up in different randconfig builds,
bite the bullet and add some nasty ifdefs to rid this issue.

Fixes: 32d617005475 ("net: dsa: realtek: add LED drivers for rtl8366rb")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202502070525.xMUImayb-lkp@intel.com/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/net/dsa/realtek/rtl8366rb.c | 53 +++++++++++++++++++++++--------------
 1 file changed, 33 insertions(+), 20 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl8366rb.c b/drivers/net/dsa/realtek/rtl8366rb.c
index 4c4a95d4380ce2a8a88a6d564cc16eab5a82dbc8..b914bb288f864ed211ff0b799d4f1938474199a7 100644
--- a/drivers/net/dsa/realtek/rtl8366rb.c
+++ b/drivers/net/dsa/realtek/rtl8366rb.c
@@ -372,12 +372,14 @@ enum rtl8366_ledgroup_mode {
 	__RTL8366RB_LEDGROUP_MODE_MAX
 };
 
+#if IS_ENABLED(CONFIG_LEDS_CLASS)
 struct rtl8366rb_led {
 	u8 port_num;
 	u8 led_group;
 	struct realtek_priv *priv;
 	struct led_classdev cdev;
 };
+#endif
 
 /**
  * struct rtl8366rb - RTL8366RB-specific data
@@ -388,7 +390,9 @@ struct rtl8366rb_led {
 struct rtl8366rb {
 	unsigned int max_mtu[RTL8366RB_NUM_PORTS];
 	bool pvid_enabled[RTL8366RB_NUM_PORTS];
+#if IS_ENABLED(CONFIG_LEDS_CLASS)
 	struct rtl8366rb_led leds[RTL8366RB_NUM_PORTS][RTL8366RB_NUM_LEDGROUPS];
+#endif
 };
 
 static struct rtl8366_mib_counter rtl8366rb_mib_counters[] = {
@@ -831,6 +835,7 @@ static int rtl8366rb_jam_table(const struct rtl8366rb_jam_tbl_entry *jam_table,
 	return 0;
 }
 
+/* This code is used also with LEDs disabled */
 static int rb8366rb_set_ledgroup_mode(struct realtek_priv *priv,
 				      u8 led_group,
 				      enum rtl8366_ledgroup_mode mode)
@@ -850,6 +855,7 @@ static int rb8366rb_set_ledgroup_mode(struct realtek_priv *priv,
 	return 0;
 }
 
+#if IS_ENABLED(CONFIG_LEDS_CLASS)
 static inline u32 rtl8366rb_led_group_port_mask(u8 led_group, u8 port)
 {
 	switch (led_group) {
@@ -988,26 +994,6 @@ static int rtl8366rb_setup_led(struct realtek_priv *priv, struct dsa_port *dp,
 	return 0;
 }
 
-static int rtl8366rb_setup_all_leds_off(struct realtek_priv *priv)
-{
-	int ret = 0;
-	int i;
-
-	regmap_update_bits(priv->map,
-			   RTL8366RB_INTERRUPT_CONTROL_REG,
-			   RTL8366RB_P4_RGMII_LED,
-			   0);
-
-	for (i = 0; i < RTL8366RB_NUM_LEDGROUPS; i++) {
-		ret = rb8366rb_set_ledgroup_mode(priv, i,
-						 RTL8366RB_LEDGROUP_OFF);
-		if (ret)
-			return ret;
-	}
-
-	return ret;
-}
-
 static int rtl8366rb_setup_leds(struct realtek_priv *priv)
 {
 	struct dsa_switch *ds = &priv->ds;
@@ -1039,6 +1025,33 @@ static int rtl8366rb_setup_leds(struct realtek_priv *priv)
 	}
 	return 0;
 }
+#else
+static int rtl8366rb_setup_leds(struct realtek_priv *priv)
+{
+	return 0;
+}
+#endif
+
+/* This code is used also with LEDs disabled */
+static int rtl8366rb_setup_all_leds_off(struct realtek_priv *priv)
+{
+	int ret = 0;
+	int i;
+
+	regmap_update_bits(priv->map,
+			   RTL8366RB_INTERRUPT_CONTROL_REG,
+			   RTL8366RB_P4_RGMII_LED,
+			   0);
+
+	for (i = 0; i < RTL8366RB_NUM_LEDGROUPS; i++) {
+		ret = rb8366rb_set_ledgroup_mode(priv, i,
+						 RTL8366RB_LEDGROUP_OFF);
+		if (ret)
+			return ret;
+	}
+
+	return ret;
+}
 
 static int rtl8366rb_setup(struct dsa_switch *ds)
 {

---
base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
change-id: 20250213-rtl8366rb-leds-compile-issue-dcd2c3c50fef

Best regards,
-- 
Linus Walleij <linus.walleij@linaro.org>

Re: [PATCH] net: dsa: rtl8366rb: Fix compilation problem

[Subbaraya Sundeep]

On 2025-02-14 at 08:59:57, Linus Walleij (linus.walleij@linaro.org) wrote:
> When the kernel is compiled without LED framework support the
> rtl8366rb fails to build like this:
> 
> rtl8366rb.o: in function `rtl8366rb_setup_led':
> rtl8366rb.c:953:(.text.unlikely.rtl8366rb_setup_led+0xe8):
>   undefined reference to `led_init_default_state_get'
> rtl8366rb.c:980:(.text.unlikely.rtl8366rb_setup_led+0x240):
>   undefined reference to `devm_led_classdev_register_ext'
> 
> As this is constantly coming up in different randconfig builds,
> bite the bullet and add some nasty ifdefs to rid this issue.
>
to get rid of this issue

Rest looks good to me.

Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>

> Fixes: 32d617005475 ("net: dsa: realtek: add LED drivers for rtl8366rb")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202502070525.xMUImayb-lkp@intel.com/
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  drivers/net/dsa/realtek/rtl8366rb.c | 53 +++++++++++++++++++++++--------------
>  1 file changed, 33 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/net/dsa/realtek/rtl8366rb.c b/drivers/net/dsa/realtek/rtl8366rb.c
> index 4c4a95d4380ce2a8a88a6d564cc16eab5a82dbc8..b914bb288f864ed211ff0b799d4f1938474199a7 100644
> --- a/drivers/net/dsa/realtek/rtl8366rb.c
> +++ b/drivers/net/dsa/realtek/rtl8366rb.c
> @@ -372,12 +372,14 @@ enum rtl8366_ledgroup_mode {
>  	__RTL8366RB_LEDGROUP_MODE_MAX
>  };
>  
> +#if IS_ENABLED(CONFIG_LEDS_CLASS)
>  struct rtl8366rb_led {
>  	u8 port_num;
>  	u8 led_group;
>  	struct realtek_priv *priv;
>  	struct led_classdev cdev;
>  };
> +#endif
>  
>  /**
>   * struct rtl8366rb - RTL8366RB-specific data
> @@ -388,7 +390,9 @@ struct rtl8366rb_led {
>  struct rtl8366rb {
>  	unsigned int max_mtu[RTL8366RB_NUM_PORTS];
>  	bool pvid_enabled[RTL8366RB_NUM_PORTS];
> +#if IS_ENABLED(CONFIG_LEDS_CLASS)
>  	struct rtl8366rb_led leds[RTL8366RB_NUM_PORTS][RTL8366RB_NUM_LEDGROUPS];
> +#endif
>  };
>  
>  static struct rtl8366_mib_counter rtl8366rb_mib_counters[] = {
> @@ -831,6 +835,7 @@ static int rtl8366rb_jam_table(const struct rtl8366rb_jam_tbl_entry *jam_table,
>  	return 0;
>  }
>  
> +/* This code is used also with LEDs disabled */
>  static int rb8366rb_set_ledgroup_mode(struct realtek_priv *priv,
>  				      u8 led_group,
>  				      enum rtl8366_ledgroup_mode mode)
> @@ -850,6 +855,7 @@ static int rb8366rb_set_ledgroup_mode(struct realtek_priv *priv,
>  	return 0;
>  }
>  
> +#if IS_ENABLED(CONFIG_LEDS_CLASS)
>  static inline u32 rtl8366rb_led_group_port_mask(u8 led_group, u8 port)
>  {
>  	switch (led_group) {
> @@ -988,26 +994,6 @@ static int rtl8366rb_setup_led(struct realtek_priv *priv, struct dsa_port *dp,
>  	return 0;
>  }
>  
> -static int rtl8366rb_setup_all_leds_off(struct realtek_priv *priv)
> -{
> -	int ret = 0;
> -	int i;
> -
> -	regmap_update_bits(priv->map,
> -			   RTL8366RB_INTERRUPT_CONTROL_REG,
> -			   RTL8366RB_P4_RGMII_LED,
> -			   0);
> -
> -	for (i = 0; i < RTL8366RB_NUM_LEDGROUPS; i++) {
> -		ret = rb8366rb_set_ledgroup_mode(priv, i,
> -						 RTL8366RB_LEDGROUP_OFF);
> -		if (ret)
> -			return ret;
> -	}
> -
> -	return ret;
> -}
> -
>  static int rtl8366rb_setup_leds(struct realtek_priv *priv)
>  {
>  	struct dsa_switch *ds = &priv->ds;
> @@ -1039,6 +1025,33 @@ static int rtl8366rb_setup_leds(struct realtek_priv *priv)
>  	}
>  	return 0;
>  }
> +#else
> +static int rtl8366rb_setup_leds(struct realtek_priv *priv)
> +{
> +	return 0;
> +}
> +#endif
> +
> +/* This code is used also with LEDs disabled */
> +static int rtl8366rb_setup_all_leds_off(struct realtek_priv *priv)
> +{
> +	int ret = 0;
> +	int i;
> +
> +	regmap_update_bits(priv->map,
> +			   RTL8366RB_INTERRUPT_CONTROL_REG,
> +			   RTL8366RB_P4_RGMII_LED,
> +			   0);
> +
> +	for (i = 0; i < RTL8366RB_NUM_LEDGROUPS; i++) {
> +		ret = rb8366rb_set_ledgroup_mode(priv, i,
> +						 RTL8366RB_LEDGROUP_OFF);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return ret;
> +}
>  
>  static int rtl8366rb_setup(struct dsa_switch *ds)
>  {
> 
> ---
> base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
> change-id: 20250213-rtl8366rb-leds-compile-issue-dcd2c3c50fef
> 
> Best regards,
> -- 
> Linus Walleij <linus.walleij@linaro.org>
> 

Re: [PATCH] net: dsa: rtl8366rb: Fix compilation problem

[Andrew Lunn]

On Fri, Feb 14, 2025 at 09:59:57AM +0100, Linus Walleij wrote:
> When the kernel is compiled without LED framework support the
> rtl8366rb fails to build like this:
> 
> rtl8366rb.o: in function `rtl8366rb_setup_led':
> rtl8366rb.c:953:(.text.unlikely.rtl8366rb_setup_led+0xe8):
>   undefined reference to `led_init_default_state_get'
> rtl8366rb.c:980:(.text.unlikely.rtl8366rb_setup_led+0x240):
>   undefined reference to `devm_led_classdev_register_ext'
> 
> As this is constantly coming up in different randconfig builds,
> bite the bullet and add some nasty ifdefs to rid this issue.

At least for DSA drivers, it is more normal to put the LED code into a
separate compilation unit and provide stubs for when it is not
used. That avoids a lot of nasty #ifdefs. Could you do the same here?

Thanks
	Andrew

Re: [PATCH] net: dsa: rtl8366rb: Fix compilation problem

[Linus Walleij]

On Fri, Feb 14, 2025 at 3:06 PM Andrew Lunn <andrew@lunn.ch> wrote:
> On Fri, Feb 14, 2025 at 09:59:57AM +0100, Linus Walleij wrote:
> > When the kernel is compiled without LED framework support the
> > rtl8366rb fails to build like this:
> >
> > rtl8366rb.o: in function `rtl8366rb_setup_led':
> > rtl8366rb.c:953:(.text.unlikely.rtl8366rb_setup_led+0xe8):
> >   undefined reference to `led_init_default_state_get'
> > rtl8366rb.c:980:(.text.unlikely.rtl8366rb_setup_led+0x240):
> >   undefined reference to `devm_led_classdev_register_ext'
> >
> > As this is constantly coming up in different randconfig builds,
> > bite the bullet and add some nasty ifdefs to rid this issue.
>
> At least for DSA drivers, it is more normal to put the LED code into a
> separate compilation unit and provide stubs for when it is not
> used. That avoids a lot of nasty #ifdefs. Could you do the same here?

I can pull out *some* code to a separate file like that, but
some LED-related registers are also accessed when the LED
framework is disabled, so it would lead to a bit of unnatural
split between the two files with some always-available
LED code staying in the main file.

But if that's cool, I can do it.

Yours,
Linus Walleij

Re: [PATCH] net: dsa: rtl8366rb: Fix compilation problem

[Andrew Lunn]

On Sat, Feb 15, 2025 at 01:07:32AM +0100, Linus Walleij wrote:
> On Fri, Feb 14, 2025 at 3:06 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > On Fri, Feb 14, 2025 at 09:59:57AM +0100, Linus Walleij wrote:
> > > When the kernel is compiled without LED framework support the
> > > rtl8366rb fails to build like this:
> > >
> > > rtl8366rb.o: in function `rtl8366rb_setup_led':
> > > rtl8366rb.c:953:(.text.unlikely.rtl8366rb_setup_led+0xe8):
> > >   undefined reference to `led_init_default_state_get'
> > > rtl8366rb.c:980:(.text.unlikely.rtl8366rb_setup_led+0x240):
> > >   undefined reference to `devm_led_classdev_register_ext'
> > >
> > > As this is constantly coming up in different randconfig builds,
> > > bite the bullet and add some nasty ifdefs to rid this issue.
> >
> > At least for DSA drivers, it is more normal to put the LED code into a
> > separate compilation unit and provide stubs for when it is not
> > used. That avoids a lot of nasty #ifdefs. Could you do the same here?
> 
> I can pull out *some* code to a separate file like that, but
> some LED-related registers are also accessed when the LED
> framework is disabled, so it would lead to a bit of unnatural
> split between the two files with some always-available
> LED code staying in the main file.

So there is some low level code for basic LED register access which
you need to keep in rtl8366rb.c, and then a layer on top of that for
led_classdev which goes into a file of its own. At first glance, it
does not look too bad, but the devil is in the details.

In the end, you need to make a style call. Is #ifdef better than an
unnatural splitting.

Hummm..

In the example above, you are getting linker errors. So the code at
least compiles, in this example. Rather than #ifdef, can you use

	if (IS_ENABLED(CONFIG_LEDS_CLASS)) {
	....
	}
	
That looks less ugly, and allows compile testing, which is what we
don't like about #ifdef.

	Andrew