lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: 
 <170441642573.24287.3221322138085351593.git-patchwork-notify@kernel.org>
Date: Fri, 05 Jan 2024 01:00:25 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: nic_swsd@...ltek.com, pabeni@...hat.com, kuba@...nel.org,
 davem@...emloft.net, edumazet@...gle.com, netdev@...r.kernel.org,
 arnd@...db.de
Subject: Re: [PATCH net-next] r8169: fix building with CONFIG_LEDS_CLASS=m

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@...nel.org>:

On Wed, 3 Jan 2024 16:52:04 +0100 you wrote:
> When r8169 is built-in but LED support is a loadable module, the new
> code to drive the LED causes a link failure:
> 
> ld: drivers/net/ethernet/realtek/r8169_leds.o: in function `rtl8168_init_leds':
> r8169_leds.c:(.text+0x36c): undefined reference to `devm_led_classdev_register_ext'
> 
> LED support is an optional feature, so fix this issue by adding a Kconfig
> symbol R8169_LEDS that is guaranteed to be false if r8169 is built-in
> and LED core support is a module. As a positive side effect of this change
> r8169_leds.o no longer is built under this configuration.
> 
> [...]

Here is the summary with links:
  - [net-next] r8169: fix building with CONFIG_LEDS_CLASS=m
    https://git.kernel.org/netdev/net-next/c/a2634a5ffcaf

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ