On Thu, Feb 29, 2024 at 12:19:40PM -0800, Guenter Roeck wrote: > On 2/29/24 11:54, Greg Kroah-Hartman wrote: > > On Tue, Feb 27, 2024 at 12:56:32PM -0600, Daniel Díaz wrote: > > > Hello! > > > > > > On 27/02/24 7:23 a. m., Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 5.15.150 release. > > > > There are 245 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Thu, 29 Feb 2024 13:15:36 +0000. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.150-rc1.gz > > > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y > > > > and the diffstat can be found below. > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > We're seeing build regressions here with RISC-V, with GCC 8, GCC 12, and Clang 17: > > > > > > -----8<----- > > > In file included from /builds/linux/include/linux/list.h:9, > > > from /builds/linux/include/linux/module.h:12, > > > from /builds/linux/drivers/net/ethernet/realtek/r8169_main.c:12: > > > /builds/linux/drivers/net/ethernet/realtek/r8169_main.c:5512:35: error: 'rtl8169_pm_ops' undeclared here (not in a function); did you mean 'rtl8169_poll'? > > > 5512 | .driver.pm = pm_ptr(&rtl8169_pm_ops), > > > | ^~~~~~~~~~~~~~ > > > /builds/linux/include/linux/kernel.h:46:44: note: in definition of macro 'PTR_IF' > > > 46 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL) > > > | ^~~ > > > /builds/linux/drivers/net/ethernet/realtek/r8169_main.c:5512:27: note: in expansion of macro 'pm_ptr' > > > 5512 | .driver.pm = pm_ptr(&rtl8169_pm_ops), > > > | ^~~~~~ > > > make[5]: *** [/builds/linux/scripts/Makefile.build:289: drivers/net/ethernet/realtek/r8169_main.o] Error 1 > > > ----->8----- > > > > > > Bisection points to: > > > > > > commit ac2871f646a8f556203f5b6be875ce406d855ddb > > > Author: Paul Cercueil <paul@xxxxxxxxxxxxxxx> > > > Date: Tue Dec 7 00:20:59 2021 +0000 > > > PM: core: Redefine pm_ptr() macro > > > [ Upstream commit c06ef740d401d0f4ab188882bf6f8d9cf0f75eaf ] > > > > > > A revert could not be done cleanly. > > > > > > Tuxmake reproducer: > > > > > > tuxmake --runtime podman --target-arch riscv --toolchain gcc-12 --kconfig defconfig > > > > > > Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx> > > > > I've been beating on this for a while and I really don't know what is > > happening, sorry. The driver looks fine, something is "odd" with riscv > > No, the driver is not fine. Upstream has commit 8fe6e670640e ("r8169: use new > PM macros") which makes rtl8169_pm_ops unconditional. That commit is missing > in v5.15.y. Applying it makes the problem disappear. > > In other words, the problem is not riscv specific, but will be seen if the > realtek driver is built with CONFIG_PM=n (which happens to be the case with > riscv:defconfig). Ugh, that wasn't obvious, I was thinking that the CONFIG_PM thing would have worked properly there and was digging in riscv code all over the place... Thanks for this, now queued up. greg k-h
