On Mon, Jul 20, 2020 at 05:24:07PM +0200, Greg Kroah-Hartman wrote: > On Mon, Jul 20, 2020 at 05:04:57PM +0200, Arnd Bergmann wrote: > > On Mon, Jul 20, 2020 at 4:46 PM Naresh Kamboju > > <naresh.kamboju@xxxxxxxxxx> wrote: > > > > > > arm build failed on stable-rc 5.4 branch. > > > > > > make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j32 ARCH=arm > > > CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache > > > arm-linux-gnueabihf-gcc" O=build zImage > > > # > > > ../drivers/firmware/efi/arm-init.c: In function ‘efifb_add_links’: > > > ../drivers/firmware/efi/arm-init.c:327:12: error: implicit declaration > > > of function ‘get_dev_from_fwnode’ > > > [-Werror=implicit-function-declaration] > > > 327 | sup_dev = get_dev_from_fwnode(&sup_np->fwnode); > > > | ^~~~~~~~~~~~~~~~~~~ > > > ../drivers/firmware/efi/arm-init.c:327:10: warning: assignment to > > > ‘struct device *’ from ‘int’ makes pointer from integer without a cast > > > [-Wint-conversion] > > > 327 | sup_dev = get_dev_from_fwnode(&sup_np->fwnode); > > > | ^ > > > ../drivers/firmware/efi/arm-init.c: At top level: > > > ../drivers/firmware/efi/arm-init.c:352:3: error: ‘const struct > > > fwnode_operations’ has no member named ‘add_links’ > > > 352 | .add_links = efifb_add_links, > > > | ^~~~~~~~~ > > > ../drivers/firmware/efi/arm-init.c:352:15: error: initialization of > > > ‘struct fwnode_handle * (*)(struct fwnode_handle *)’ from incompatible > > > pointer type ‘int (*)(const struct fwnode_handle *, struct device *)’ > > > [-Werror=incompatible-pointer-types] > > > 352 | .add_links = efifb_add_links, > > > | ^~~~~~~~~~~~~~~ > > > ../drivers/firmware/efi/arm-init.c:352:15: note: (near initialization > > > for ‘efifb_fwnode_ops.get’) > > > > > > > > > seems like this is coming from the below patch > > > -- > > > efi/arm: Defer probe of PCIe backed efifb on DT systems > > > [ Upstream commit 64c8a0cd0a535891d5905c3a1651150f0f141439 ] > > > > > > The new of_devlink support breaks PCIe probing on ARM platforms booting > > > via UEFI if the firmware exposes a EFI framebuffer that is backed by a > > > PCI device. The reason is that the probing order gets reversed, > > > resulting in a resource conflict on the framebuffer memory window when > > > the PCIe probes last, causing it to give up entirely. > > > > > > Given that we rely on PCI quirks to deal with EFI framebuffers that get > > > moved around in memory, we cannot simply drop the memory reservation, so > > > instead, let's use the device link infrastructure to register this > > > dependency, and force the probing to occur in the expected order. > > > > > > Co-developed-by: Saravana Kannan <saravanak@xxxxxxxxxx> > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx> > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx> > > > Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@xxxxxxxxxx > > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > > > It seems that the stable kernels need a backport of commit 372a67c0c5ef > > ("driver core: Add fwnode_to_dev() to look up device from fwnode") as well. > > Ick, really? > > I think we should just drop the efi patch as if it relying on device > link, that is only in newer kernels. > > I'll go do that now, thanks. Yeah, that's why it wasn't backported to 5.4 in the first place, it went into 5.5.6 when it got merged into 5.6-rc. thanks, greg k-h
