summaryrefslogtreecommitdiff
path: root/drivers/net/dsa/ocelot
diff options
context:
space:
mode:
authorLinus Walleij <linus.walleij@linaro.org>2025-02-20 19:48:15 +0100
committerDavid S. Miller <davem@davemloft.net>2025-02-24 09:14:42 +0000
commitf15176b8b6e72ac30e14fd273282d2b72562d26b (patch)
tree57bc17cb81fd20bdc895a3c8c917531d00da7122 /drivers/net/dsa/ocelot
parent28b04731a38c80092f47437af6c2770765e0b99f (diff)
net: dsa: rtl8366rb: Fix compilation problem
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 create a separate file for the offending code, split out a header with all stuff needed both in the core driver and the leds code. Add a new bool Kconfig option for the LED compile target, such that it depends on LEDS_CLASS=y || LEDS_CLASS=RTL8366RB which make LED support always available when LEDS_CLASS is compiled into the kernel and enforce that if the LEDS_CLASS is a module, then the RTL8366RB driver needs to be a module as well so that modprobe can resolve the dependencies. 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> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/dsa/ocelot')
0 files changed, 0 insertions, 0 deletions