Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2417873pxb; Mon, 11 Jan 2021 09:07:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJx733Zk6et44Hz8ogOANqR8SUnoXEMqczsb+Iv7QiGEgwKAflo5xdldpHSsRlTIydWFxKQv X-Received: by 2002:aa7:c403:: with SMTP id j3mr243957edq.217.1610384867909; Mon, 11 Jan 2021 09:07:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610384867; cv=none; d=google.com; s=arc-20160816; b=g3KTk5fhIojv7t72o6AyL5aVk5gUbNoeFt42XVtYpuM0hN/AFTnG2AJ8Ak3p4wmx0e DSxQfEhH31vi4GjibiZ44d0plyVu8usmzE7HYR79cTGX5cJXEq3KxXd2FfxX5W7ibk4t pi430SatF3DcqJcZvM7Fcyjhk6TOuanFmeOutbESZCub/i1CPDPBcbU2M6XaqYT3aLQo 3OxiWdZs+0c/UdHBC4JNas3ceXPuJdvgfFcqOVpRinSmWoNCtqCwjiBrhiA/4EW3OeIS nJxH0IDArgHMqPQmf4OQ5xUHwkU5ZaZU6wThGHgCybavYIjKaibkJkg0cGFEq8LPNKJr D4cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=xMJfVSshWgEj0lAcfWPBo8KWgtflf02LM4k6kBZa15U=; b=FJbjGY2jPwxmuTNSp/zeTO1MhneNrRgvCshFZqdaRsjo2F+EKl6FHoWHku/MeaUxP4 LPq/ckJCD7WUE+i+fDc1ZzGc+pgaQg0nKxR14eC/mpcoMKHVOnSv4lkxXkcxOmBPfsAr LLNHZFKuck6z44zZ5KIAhotH3JuuSFk1RYBScb8P20rGEsoqhgmy74Y4iLU3L6u3fMQg H+hNi6+MbKtWxbPlJR5riDk6oMwSrwu3IHWjlDtUhHXUoD5kyqCa4kaACYMHfkgJzmUm lRdJh2iW1nAnCn9gy+KDxKS3vpQ++41yGpjsalwx+Q2D6or7Ghx4F1tJY5GPhswqJjXJ Za6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=kaT+42xO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f27si1607ejf.555.2021.01.11.09.07.23; Mon, 11 Jan 2021 09:07:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=kaT+42xO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387851AbhAKREj (ORCPT + 99 others); Mon, 11 Jan 2021 12:04:39 -0500 Received: from conssluserg-04.nifty.com ([210.131.2.83]:44092 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727882AbhAKREi (ORCPT ); Mon, 11 Jan 2021 12:04:38 -0500 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (authenticated) by conssluserg-04.nifty.com with ESMTP id 10BH3U0G032490; Tue, 12 Jan 2021 02:03:30 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 10BH3U0G032490 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1610384611; bh=xMJfVSshWgEj0lAcfWPBo8KWgtflf02LM4k6kBZa15U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kaT+42xO4dFBEec3CudgE1dh/SUOSLoqX7ghFIucj0iYivP7tVDmCwxbcZgxuYy40 qaI1b2iwPKhkQ329RV/DIJSOJD/SBrxQ7gixBwwPuN0CGwKi4cssd/gEXwvkzul6WA JD9hVL0rUdXCWZ8wgEx2/AqFuQLDRDmLSFNY7XN2r83baNSUdXV+LnxituaXhmIhnm MkyTakUP+74DbAL6v/3bfoLnb+NgecLmTLa80/YFaMVvKtgj8Nmj51GZD2BOfocM+I bXNGKi+rSuGREh/AzyLnfD2CV5Wa0eUWJAFucxfePqRiWTge34f9Z3bxyu6sijtHQ9 xa/bQ8A2x3tTw== X-Nifty-SrcIP: [209.85.214.170] Received: by mail-pl1-f170.google.com with SMTP id be12so161310plb.4; Mon, 11 Jan 2021 09:03:30 -0800 (PST) X-Gm-Message-State: AOAM530oZsA80kDfAC2B+LEZiyIM7vbac/qOO+M7KNoQv8qmA6nbq9C9 JVLD13UeXHCpvv83hf1+QHTaIApf4XF6SkP08S0= X-Received: by 2002:a17:902:9b91:b029:db:f003:c5eb with SMTP id y17-20020a1709029b91b02900dbf003c5ebmr660291plp.1.1610384609949; Mon, 11 Jan 2021 09:03:29 -0800 (PST) MIME-Version: 1.0 References: <20210111111711.r2xesydzhq5js2nf@vireshk-i7> In-Reply-To: From: Masahiro Yamada Date: Tue, 12 Jan 2021 02:02:52 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 0/2] kbuild: Add support to build overlays (%.dtbo) To: Rob Herring Cc: David Gibson , Viresh Kumar , Arnd Bergmann , Olof Johansson , Pantelis Antoniou , Frank Rowand , Michal Marek , DTML , "linux-kernel@vger.kernel.org" , Linux Kbuild mailing list , Vincent Guittot , Bill Mills , tero.kristo@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021 at 1:13 AM Rob Herring wrote: > > +David Gibson > > On Mon, Jan 11, 2021 at 9:40 AM Masahiro Yamada wrote: > > > > On Mon, Jan 11, 2021 at 8:17 PM Viresh Kumar wrote: > > > > > > On 07-01-21, 14:28, Masahiro Yamada wrote: > > > > Viresh's patch is not enough. > > > > > > > > We will need to change .gitignore > > > > and scripts/Makefile.dtbinst as well. > > > > > > > > In my understanding, the build rule is completely the same > > > > between .dtb and .dtbo > > > > As Rob mentioned, I am not sure if we really need/want > > > > a separate extension. > > > > > > > > A counter approach is to use an extension like '.ovl.dtb' > > > > It clarifies it is an overlay fragment without changing > > > > anything in our build system or the upstream DTC project. > > > > > > By the time you gave feedback, I have already sent the dtbo change for > > > DTC to the device-tree-compiler list (based on Rob's suggestion). > > > > > > And it got merged today by David: > > > > > > https://github.com/dgibson/dtc/commit/163f0469bf2ed8b2fe5aa15bc796b93c70243ddc > > > > > > Can we please finalize what we need to do with naming here and be done > > > with it, so I can rework my patches and get going ? > > > > > > Thanks. > > > > > > -- > > > viresh > > > > > > > > It is unfortunate to see such a patch merged > > before getting agreement about how it should work > > as a whole. > > Given the feedback that dtbo is already a standard, I'd suggest we > just stick with dts->dtbo. OK. dtbo seems a stanrdard already... > > >+# enable creation of __symbols__ node > > >+ifneq ($(dtbo-y),) > > >+DTC_FLAGS += -@ > > >+endif > > > > I am not convinced with this code. > > > > A single user of the dtbo-y syntax gives -@ to all > > device trees in the same directory. > > > > This is not a solution since Rob already stated -@ should be > > given per board (or per platform, at least). > > Agreed. > > > I still do not understand why adding the new syntax dtbo-y > > is helpful. > > I think we should stick with 'dtb-y' here. > > > > Have we already decided to use separate ".dtb" and ".dtbo" for blobs? > > > > Will we use ".dts" for all source files? > > Or, will we use ".dtso" for overlay source files? > > > > How should the build system determine the targets > > that should have -@ option? > > The way it does already. Either: > > DTC_FLAGS += -@ > > in a directory of dts files. Or on a per file basis like: > > DTC_FLAGS_foo_base += -@ Ah yes. I like this. We do not need the dtbo-y syntax. We can simply use dtb-y for base boards and overlay fragments: dtb-$(CONFIG_ARCH_FOO) += \ foo-base.dtb \ foo-overlay1.dtbo \ foo-overlay2.dtbo DTB_FLAGS_foo-base += -@ > > > For consistency, will we need a patch like follows? > > > > > > diff --git a/dtc.c b/dtc.c > > index bdb3f59..474401e 100644 > > --- a/dtc.c > > +++ b/dtc.c > > @@ -120,6 +120,8 @@ static const char *guess_type_by_name(const char > > *fname, const char *fallback) > > return fallback; > > if (!strcasecmp(s, ".dts")) > > return "dts"; > > + if (!strcasecmp(s, ".dtso")) > > + return "dts"; > > if (!strcasecmp(s, ".yaml")) > > return "yaml"; > > if (!strcasecmp(s, ".dtb")) > > @@ -349,6 +351,8 @@ int main(int argc, char *argv[]) > > > > if (streq(outform, "dts")) { > > dt_to_source(outf, dti); > > + else if (streq(outform, "dtso")) { > > + dt_to_source(outf, dti); > > #ifndef NO_YAML > > } else if (streq(outform, "yaml")) { > > if (!streq(inform, "dts")) > > > > > > > > Overall solution looks unclear to me. > > > > > > Again, it is unfortunate that we did not take enough time > > (in spite of the RFC prefix) before proceeding. > > I should have added David here from the start. Honestly, I expected > some discussion there. > > Rob -- Best Regards Masahiro Yamada