Re: stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’

From: Arnd Bergmann <arnd@arndb.de>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: linux- stable <stable@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>,
	saravanak@google.com
Subject: Re: stable-rc 5.4: arm build failed: arm-init.c:327:12: error: implicit declaration of function ‘get_dev_from_fwnode’
Date: Mon, 20 Jul 2020 17:04:57 +0200	[thread overview]
Message-ID: <CAK8P3a24UWMoH9775FD3++Uwp1O-9gJkjoiq0M21RLZoe7TxbQ@mail.gmail.com> (raw)
In-Reply-To: <CA+G9fYuPe=XkrTx+yDo556D5t4wrFRFXctPPb2+7w+v-hAHvyw@mail.gmail.com>

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