| Message ID | 20250214-rtl8366rb-leds-compile-issue-v1-1-c4a82ee68588@linaro.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: dsa: rtl8366rb: Fix compilation problem | expand |
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
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
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
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) {
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(-) --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20250213-rtl8366rb-leds-compile-issue-dcd2c3c50fef Best regards,