Received: by 10.213.65.68 with SMTP id h4csp891497imn; Thu, 22 Mar 2018 10:49:40 -0700 (PDT) X-Google-Smtp-Source: AG47ELvE1tE51eLooxCEGrZ1MoyGdqywiavCAt98Oyu7c/BfNXAFkHndfHr1f5KNf+KFVD4bgzKk X-Received: by 10.101.77.198 with SMTP id q6mr12541915pgt.61.1521740980645; Thu, 22 Mar 2018 10:49:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521740980; cv=none; d=google.com; s=arc-20160816; b=FyswLHIc01PrwGDvdC8snzb3Upz8P2svlYMC5MwfyTjdWoedc6abwI3sqW7onT3ZoU bXMQMIcLqXQg137sY2PuKLTf47zHGsj8CuJwBBaymdTWEJVmRvDmQhhN/k02W5HT5Ehm g+i7q00U30u/ROkvgGQfvnRXSegiEr81jNRCW1Ae3zBY2InbkTbuyPysqY7suC7zktH9 VBlVYeLvk+J4pF+TKNuG55Kka8atTKMSvtVHWmS4Rn8H+iyJb4P5AUfVevsYzjyrF7U/ h4PHkjQsbYEo3Tx0YTCojUu6W/iNJ7ArxGA67IrninkZsxcoZFsjR00BHu6D54UZQfzW iq8g== 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=BQCAGagCPa1acP6UqSLk8JwliOw4NIrXTObxlSq8wYs=; b=rLGjTMigIsBnE3tD0iJEMmK8wrLTSLgw0vKYQCHFRcDpvx6KD79LyFg9+v/4g2QXDV 5X38+WuTApxeH0TrkmD881yJwpFnOG0maNdqOQqY13SCM7HiyBJdw7KStLy1AQtpQh+h fnKx0dmXC1+i1nUT77GtcE4CjKH9hzFqJk8ACpV0W29p4HwbJfnFUgiVhg+RppTBpXnF oMgESabCmE1/Tu7osINCV2nIsZg0YBWllxtImSKuO89czbJA6RSc8H3+UebGziyzohpu LLS9F+6cj7+TWf8EASBmCnxn1VvltyTxSOYTCqK5Oc/aT3r6WIOwsSpg1PT/5JnKK42F tgPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=iEA8tWs9; 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 az10-v6si6353985plb.145.2018.03.22.10.49.21; Thu, 22 Mar 2018 10:49:40 -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=iEA8tWs9; 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 S1751819AbeCVRs1 (ORCPT + 99 others); Thu, 22 Mar 2018 13:48:27 -0400 Received: from conssluserg-02.nifty.com ([210.131.2.81]:36251 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751416AbeCVRs0 (ORCPT ); Thu, 22 Mar 2018 13:48:26 -0400 Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) (authenticated) by conssluserg-02.nifty.com with ESMTP id w2MHm9Xs002194; Fri, 23 Mar 2018 02:48:09 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com w2MHm9Xs002194 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1521740890; bh=BQCAGagCPa1acP6UqSLk8JwliOw4NIrXTObxlSq8wYs=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=iEA8tWs9gy6chCH1hiUPxJ2W71R08NhscHm7vqlVIkaH5UOmvzsfpsBn83uSu0fwx TK+Nf0YiBtBBUl0L6d2Gszkz0H1lVGtfl0lMSg9PHuBpcrmg0yh6PWO5p5fxUNw1XT t1nIvmPf+vRqr/odMYKArFpmA1Q3DGIifnSX3ovvyODghX9jJ8rCczpJL1yOdolL8d s6o2xs53kNzjg/vEnV3cSvCibgLvxT5589wL6YqqIFAckfJ1wCqH2411diO7V/dMXL 0mnHdmtePbhmLExu6mwdlrwpw6BwAa+fqApBt4UqKAS00HCUtQ2HSBTJWHin0dARBU syDfQSSPCKFig== X-Nifty-SrcIP: [209.85.213.47] Received: by mail-vk0-f47.google.com with SMTP id j85so5742868vke.0; Thu, 22 Mar 2018 10:48:09 -0700 (PDT) X-Gm-Message-State: AElRT7GnVpMRQpWLoqLU0SjCX+OTPAQNbgCpu5t9DX3RFZtYJ9reSvQf ZApR0OO2vLsKsSRI0R4YkqKZbNVBibWWHkSYIDI= X-Received: by 10.31.176.130 with SMTP id z124mr9580680vke.65.1521740888495; Thu, 22 Mar 2018 10:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.53.175 with HTTP; Thu, 22 Mar 2018 10:47:27 -0700 (PDT) In-Reply-To: References: <20180315153730.3798004-1-arnd@arndb.de> <1806382.Agy9d77yKa@avalon> From: Masahiro Yamada Date: Fri, 23 Mar 2018 02:47:27 +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 > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds This has been in my TODO list for a while, but I have not had time to finish it. Some people use .PRECIOUS to suppress file removal, but it is wrong IMO. .SECONDARY is the right one, but one problem is, this does not work with pattern rules. I will send a patch soon for the core improvement. -- Best Regards Masahiro Yamada