* stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ @ 2020-07-20 14:46 Naresh Kamboju 2020-07-20 14:52 ` Naresh Kamboju 2020-07-20 15:04 ` Arnd Bergmann 0 siblings, 2 replies; 5+ messages in thread From: Naresh Kamboju @ 2020-07-20 14:46 UTC (permalink / raw) To: linux- stable, Greg Kroah-Hartman; +Cc: Sasha Levin, Arnd Bergmann, saravanak 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@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> -- Linaro LKFT https://lkft.linaro.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ 2020-07-20 14:46 stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ Naresh Kamboju @ 2020-07-20 14:52 ` Naresh Kamboju 2020-07-20 15:04 ` Arnd Bergmann 1 sibling, 0 replies; 5+ messages in thread From: Naresh Kamboju @ 2020-07-20 14:52 UTC (permalink / raw) To: linux- stable, Greg Kroah-Hartman; +Cc: Sasha Levin, Arnd Bergmann, saravanak On Mon, 20 Jul 2020 at 20:16, Naresh Kamboju <naresh.kamboju@linaro.org> 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); > | ^~~~~~~~~~~~~~~~~~~ same build problem occurred on stable -rc 4.9, 4.14 and 4.19 and 5.4 for arm and arm64 architectures. > 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@google.com> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Saravana Kannan <saravanak@google.com> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Ingo Molnar <mingo@kernel.org> > Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org > Signed-off-by: Sasha Levin <sashal@kernel.org> > > > -- > Linaro LKFT > https://lkft.linaro.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ 2020-07-20 14:46 stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ Naresh Kamboju 2020-07-20 14:52 ` Naresh Kamboju @ 2020-07-20 15:04 ` Arnd Bergmann 2020-07-20 15:24 ` Greg Kroah-Hartman 1 sibling, 1 reply; 5+ messages in thread From: Arnd Bergmann @ 2020-07-20 15:04 UTC (permalink / raw) To: Naresh Kamboju; +Cc: linux- stable, Greg Kroah-Hartman, Sasha Levin, saravanak On Mon, Jul 20, 2020 at 4:46 PM Naresh Kamboju <naresh.kamboju@linaro.org> 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@google.com> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Saravana Kannan <saravanak@google.com> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Ingo Molnar <mingo@kernel.org> > Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org > Signed-off-by: Sasha Levin <sashal@kernel.org> 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. Arnd ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ 2020-07-20 15:04 ` Arnd Bergmann @ 2020-07-20 15:24 ` Greg Kroah-Hartman 2020-07-20 15:25 ` Greg Kroah-Hartman 0 siblings, 1 reply; 5+ messages in thread From: Greg Kroah-Hartman @ 2020-07-20 15:24 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Naresh Kamboju, linux- stable, Sasha Levin, saravanak 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@linaro.org> 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@google.com> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > Signed-off-by: Ingo Molnar <mingo@kernel.org> > > Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org > > Signed-off-by: Sasha Levin <sashal@kernel.org> > > 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. greg k-h ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ 2020-07-20 15:24 ` Greg Kroah-Hartman @ 2020-07-20 15:25 ` Greg Kroah-Hartman 0 siblings, 0 replies; 5+ messages in thread From: Greg Kroah-Hartman @ 2020-07-20 15:25 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Naresh Kamboju, linux- stable, Sasha Levin, saravanak 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@linaro.org> 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@google.com> > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > > Signed-off-by: Ingo Molnar <mingo@kernel.org> > > > Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org > > > Signed-off-by: Sasha Levin <sashal@kernel.org> > > > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-07-20 15:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-20 14:46 stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’ Naresh Kamboju 2020-07-20 14:52 ` Naresh Kamboju 2020-07-20 15:04 ` Arnd Bergmann 2020-07-20 15:24 ` Greg Kroah-Hartman 2020-07-20 15:25 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).