From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1891FC433E6 for ; Mon, 20 Jul 2020 15:24:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E963522482 for ; Mon, 20 Jul 2020 15:24:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595258644; bh=uRCMHcHJl4fPVWceCPdyp93kNTNvmq7Vqyc5uNGo16Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=E6B59f4eJBPK5E9+Ve6c1k1S3E1XoESLPUrOBeItUHExBsI04FIM3ltHf9nOWS/DK gyTunCvz3RzA1PMBiGl6OCpu6VhSocZkY3K8j9AeKKxbG6h/kfbck3b9OyMTPliE+W pfWyS3KLbmc5qKukG/VncWGCgKaDNEvepee4zf4s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728518AbgGTPYB (ORCPT ); Mon, 20 Jul 2020 11:24:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:49668 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728378AbgGTPX6 (ORCPT ); Mon, 20 Jul 2020 11:23:58 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E084822482; Mon, 20 Jul 2020 15:23:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595258637; bh=uRCMHcHJl4fPVWceCPdyp93kNTNvmq7Vqyc5uNGo16Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0znQOwouszdzqLvIPlovTh97GZJUBzQv8jVO+Dc1EvWDhuRu0yGjjf5tnhDO7aOns lH3SgF3hADCnkQWOGwd0xnJJJBa8oueOPpEEwXWat8u2Fh+Xo2PSJXIqhL6UONTaAe 5PzFwwZP7efclELqi9qXmQC2SMUi3fzytuHBotMw= Date: Mon, 20 Jul 2020 17:24:07 +0200 From: Greg Kroah-Hartman To: Arnd Bergmann Cc: Naresh Kamboju , linux- stable , Sasha Levin , saravanak@google.com Subject: Re: stable-rc 5.4: arm build =?utf-8?Q?fai?= =?utf-8?Q?led=3A_arm-init=2Ec=3A327=3A12=3A_error=3A_implicit_declaration?= =?utf-8?B?IG9mIGZ1bmN0aW9uIOKAmGdldF9kZXZfZnJvbV9md25vZGXigJk=?= Message-ID: <20200720152407.GA1381945@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Jul 20, 2020 at 05:04:57PM +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 4:46 PM Naresh Kamboju > 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 > > Signed-off-by: Ard Biesheuvel > > Signed-off-by: Saravana Kannan > > Signed-off-by: Ard Biesheuvel > > Signed-off-by: Ingo Molnar > > Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org > > Signed-off-by: Sasha Levin > > 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