Received: by 10.213.65.68 with SMTP id h4csp370169imn; Fri, 23 Mar 2018 06:29:28 -0700 (PDT) X-Google-Smtp-Source: AG47ELtyt9zOdXKc3fJ7wHPMAifvz4u5HetCnE43FdKW67MIJyBMbV6TSPY69rVupV64I0BsHBwo X-Received: by 10.99.108.2 with SMTP id h2mr21045036pgc.396.1521811768793; Fri, 23 Mar 2018 06:29:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521811768; cv=none; d=google.com; s=arc-20160816; b=ZBgpOO/AfAFtFL+ybIw7TYkdAw2e5raKv7M0Nb5fwVFi+QjWpXB4COdvzf7tIjqomJ o1f6QdOs1R2v+ow5Rt/0B57sZPVLfIMvK4+oMg90mJRu103q2RibfHYV9NzoE3flEOu6 NLR+2V0EizLzuJsowLdthrxfE30jiCk3ZXAsEYHSLuAjTjMmhR/IrfP3mgGHzakz/4SC OYynnVuCjjYu/dZiMiT07EAplkV6SVkVbjQ7AUVE030sNIRl8K2CUSHmhp+MvY3z2Yul q/l+rjOhVZS8/FCvwzbpjOdX6RNfNgtQv2/FGENVjmjbesXJcwFmgshYK7G/cBcwI5mu eRrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-filter :arc-authentication-results; bh=JA14LA9loYCM3TAox9RTfQfP27F+763BxMQl1NmMB78=; b=AEQnam8iQ2Z4hVkigPv3J4M2I+E9G67C8NoE6wCeIAQy3weLbbjDhbx9d4sgiO9oLK rWYXh4gA+9vqcK6Q1OBT2byF0i8q/AwNaq2xYyj6ExAgLmDkR4UURHdyZWAL+kCkimzI YTaKstdrlw778AutF3ZLXuKt60X1941isS8hge6GPpJnTocaAgRWuzGRnNOgcjt0PqcB 97bHxKeGTr23dGVzn1ysBoWGBVR/xMs8rxd5nMHCh+Vqwy8fKSutFpwnAzrGVZFpdowc 0lkSVhlFAG5myWmC1eq1fjZ4mFvXb2xohJocN/R8/ep/3EpeNzmSd9sp/goAUR/AYFYS ybsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=Zs37Gz4a; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 32-v6si2576884pld.206.2018.03.23.06.29.13; Fri, 23 Mar 2018 06:29:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=Zs37Gz4a; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752331AbeCWN2K (ORCPT + 99 others); Fri, 23 Mar 2018 09:28:10 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:41669 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752101AbeCWN2G (ORCPT ); Fri, 23 Mar 2018 09:28:06 -0400 Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) (authenticated) by conssluserg-04.nifty.com with ESMTP id w2NDRusj030230; Fri, 23 Mar 2018 22:27:57 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com w2NDRusj030230 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1521811677; bh=JA14LA9loYCM3TAox9RTfQfP27F+763BxMQl1NmMB78=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=Zs37Gz4aORX10FL2pSFNGp/AwPLkkbH6E3i63Actn78c6nrN2fOuSb8s32aIB2xB8 OqgedGaSFCYwzvj9ussDfUsl+ykSgOAet26/Zu1WOC3zUKrnhlUSEp4IRhNPkhfyqL PVqqdKYetVqw3qGS4bKtJWQuC7Swl8VjD9+ek2dwqGOL1mvid+31mFqAN+mwpPO+RO jwl7zx33Yx2RN6Yf2dOMCQbQIUfNOOR1LeCOwKFBmyb5p5Tzrg/uZj9xJbrlohN8mw LBBNi8/t5uMBUdpPfTFFL1K+ZjK5FQkLG0gssNb1Pc99WuDkSvMANz8tx6fUNjUVwC u7XJk9PqAUcpg== X-Nifty-SrcIP: [209.85.213.50] Received: by mail-vk0-f50.google.com with SMTP id l123so7264332vke.8; Fri, 23 Mar 2018 06:27:56 -0700 (PDT) X-Gm-Message-State: AElRT7GuGEWjGzTtV/jdyTtQzvhn8hOHSN1yoB3X7XfI9wfY5GKhRwLm Mcbx4ewtLXVFNBRGpg5Xxh/jZYIqnea9EwMc5cw= X-Received: by 10.31.108.87 with SMTP id h84mr18711644vkc.166.1521811675724; Fri, 23 Mar 2018 06:27:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.53.175 with HTTP; Fri, 23 Mar 2018 06:27:15 -0700 (PDT) In-Reply-To: References: <20180315153730.3798004-1-arnd@arndb.de> <1806382.Agy9d77yKa@avalon> From: Masahiro Yamada Date: Fri, 23 Mar 2018 22:27:15 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build To: Geert Uytterhoeven Cc: Laurent Pinchart , Frank.Rowand@sony.com, Arnd Bergmann , David Airlie , =?UTF-8?Q?Niklas_S=C3=B6derlund?= , DRI Development , Linux-Renesas , Linux Kernel Mailing List , Frank Rowand Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-03-23 0:13 GMT+09:00 Geert Uytterhoeven : > Hi Laurent, > > CC Yamada-san > > On Thu, Mar 22, 2018 at 3:50 PM, Laurent Pinchart > wrote: >> On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote: >>> On Fri, Mar 16, 2018 at 2:39 AM, wrote: >>> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote: >>> >> The *.dtb and *.dtb.S files get removed by 'make' during the build >>> >> process, and later seem to be missed during the 'modpost' stage: >>> >> >>> >> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S >>> >> WARNING: could not open >>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or >>> >> directory >>> >> >>> >> As a workaround, this adds all those files to the 'extra-y' target list, >>> >> but that's really ugly. Any ideas for a better fix? >>> > >>> > Does this work for you (untested, but the way it is done in >>> > drivers/of/unittest-data/Makefile): >>> > >>> > .PRECIOUS: \ >>> > >>> > $(obj)/%.dtb.S \ >>> > $(obj)/%.dtb >>> >>> Shouldn't that just be moved to scripts/Makefile.lib, just above the rule >>> to make dtb.S, like is done for other precious objects? >> >> Without any implied acknowledgment that keeping those intermediate files is >> the right solution (I don't claim to master the kernel build system), I think > > Me neither, but I think it is. > > Cfr. .y => .tab.c => .tab.o with .tab.c marked PRECIOUS. > >> such a rule would indeed be better in a core Makefile, as the rules to build >> the .dtb.o file comes from the core too. Could another option be to create a >> rule to compile a .dtb.o from the .dts file directly without going through >> intermediate files that will be removed automatically ? > > Such a rules needs to execute two commands, which is more tricky, considering > error handling. > It's easier (to get right) to have two separate rules, and let make chain them > automatically. > > Gr{oetje,eeting}s, > > Geert > I submit the patches. I'd like to queue them up for the next merge window, so your problems will be fixed if Kbuild pull requests are pulled. The driver Makefile has two problems. [1] Objects are always rebuilt due to missing 'targets' [2] Intermediate files are removed due to missing .SECONDARY (or .PRECIOUS) If you want to fix them by yourself, you can. But, those issues will be taken care of by the core Makefile. Specifically, [1] will be fixed by https://patchwork.kernel.org/patch/10304671/ and [2] by https://patchwork.kernel.org/patch/10304651/ -- Best Regards Masahiro Yamada