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=-5.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 CD526C432BE for ; Tue, 31 Aug 2021 14:22:00 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D685F600AA for ; Tue, 31 Aug 2021 14:21:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D685F600AA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5315F82C90; Tue, 31 Aug 2021 16:21:57 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="snA3+Izb"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4C82D831C8; Tue, 31 Aug 2021 16:21:54 +0200 (CEST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C705682A01 for ; Tue, 31 Aug 2021 16:21:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qk1-x72f.google.com with SMTP id f22so19732435qkm.5 for ; Tue, 31 Aug 2021 07:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5driQqxRdtApP6pFx5sVcacsYPbFXDPeTq9LvN/1Dls=; b=snA3+Izb5YDmYMfb1BWqGSb7D1PxV4+/8oSFXixdM8ObsVNJ/jh/Z2zdRXzNNFBhqx tpLZc/u4bmACDcjxHTr6bjPLwSJntWlcGY7hOMRXx1js+BEAMqy5dFIZl1t2sGWC2c8b djoAGjsWz4o+RKXN2lSnQsgYjE3dC6np/JXloJNZ9Th9wxl4IlxL8EoI0OEDHNHQ57z+ oS8jwspk45DNPN6aJ4eJdYJJS3qZ0Kl2hOCPlIKGeGWhJz1Ntt4hQFCzPqB3BfWjX8FQ nwaj+pIwoNAuW0Dmxk/WQupGxK7pS/KuBEl373uYHwZ45l9uYgpl/kYMx9p81UtXVpj2 HQEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5driQqxRdtApP6pFx5sVcacsYPbFXDPeTq9LvN/1Dls=; b=OvEzOKJzKt+/thNqlDQbEBXM2DXgnyvjrSLMs2E6mO1w2A4NEX3MmjStVNBXMWNoem 29v3dPRFQjgmhdOjZ1uZlEnB87zUoV7kPOh2FE5F9lo6Qsc1w9Qxuwa7QXAXnbyWqvCS 67/DiNz5CQD3TaUUO13we4blFfVdOXjNI8LZ3xlbd6Nrvn9oyD0eoNcKKbe1PPqheQwa uFUHEV2bAb3EgNgmPbZbypi5DM/qOGXHout2y0Z4JDjl5QMpM/e6WE1/zB10WYBDDV/v US7c/MXanJ/JoZ0lalTE8pow22rDqfzl5Qx0q56VN1E5roMfv5gLLrHnr4TYN4i4WbXz ha2g== X-Gm-Message-State: AOAM530+nu1IM+k3uSqQth+7lnGxhh+vNp62S0WDGC6SbBbxGWaTwvbB 4aZDEa/K7MivoDGu3y60tJI= X-Google-Smtp-Source: ABdhPJy2gd+eSGouiBJ3bMlCIyF+EUZY1oAr5WXsiGuOSm7uOMw8+9A5UJYV/ATqI5AWmH1po1HQcw== X-Received: by 2002:a37:6c2:: with SMTP id 185mr3306190qkg.260.1630419708450; Tue, 31 Aug 2021 07:21:48 -0700 (PDT) Received: from [192.168.1.201] (pool-108-45-127-224.washdc.fios.verizon.net. [108.45.127.224]) by smtp.googlemail.com with ESMTPSA id r19sm10693608qtt.86.2021.08.31.07.21.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Aug 2021 07:21:47 -0700 (PDT) From: Sean Anderson Subject: Re: incompatible device trees between u-boot and linux To: Rob Herring , Vladimir Oltean Cc: Tom Rini , Michael Walle , Priyanka Jain , U-Boot Mailing List , Heiko Thiery References: <51c2a92f6bf771769f1e2da5157727e8@walle.cc> <20210825140045.GR858@bill-the-cat> <20210825141816.qfn25xlech55rwsg@skbuf> <20210825142610.GU858@bill-the-cat> <20210825151220.xkpxxucce2oicfvy@skbuf> Message-ID: Date: Tue, 31 Aug 2021 10:21:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 8/31/21 9:35 AM, Rob Herring wrote: > On Wed, Aug 25, 2021 at 10:12 AM Vladimir Oltean wrote: >> >> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote: >>> On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote: >>>> On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote: >>>>> On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I noticed that there is a fallback to the u-boot device tree for linux >>>>>> (esp. EFI boot) if no other device tree was found, see [1]. It seems this >>>>>> is working fine for imx devices, for example, where you can just boot a >>>>>> stock installer iso via EFI. It will just work and it is quite a nice >>>>>> feature as a fallback. >>>>>> >>>>>> Now for the layerscape architecture, the ls1028a in my case, things are >>>>>> more difficult because the bindings differ between u-boot and linux - one >>>>>> which comes to mind is DSA and ethernet. >>>>>> >>>>>> Which begs the general question, is it encouraged to have both bindings >>>>>> diverge? To me it seems, that most bindings in u-boot are ad-hoc and there >>>>>> is no real review or alignment but just added as needed, which is ok if >>>>>> they are local to u-boot. But since they are nowadays passed to linux >>>>>> (by default!) I'm not so sure anymore. >>>>>> >>>>>> OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like >>>>>> they should (could?) be shared between linux and u-boot. >>>>>> >>>>>> -michael >>>>>> >>>>>> [1] >>>>>> https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471 >>>>> >>>>> The U-Boot device tree is supposed to be able to be passed on to Linux >>>>> and Just Work. The bindings are not supposed to be different between >>>>> the two (except for when we take the binding while it's being hashed out >>>>> upstream BUT THEN RESYNCED). >>>> >>>> You might need to spell that out a bit clearer. >>>> >>>> You are saying that both U-Boot and Linux are allowed to have their own >>>> custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = "in-band-status"' >>>> for Linux), as long as the device tree files themselves are in sync, and >>>> the subset of the device tree blob understood by Linux (i.e. the U-Boot >>>> blob sans the U-Boot specifics) is compatible with the Linux DT blob? >>> >>> I don't know what about the Linux example makes it Linux specific. But >>> yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored >>> by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in >>> logic (as much as it can be used is that device trees are device trees >> ^ >> I don't think this parenthesis ever closes... >> >>> and describe the hardware and developers don't need to write a device >>> tree for Linux and a device tree for U-Boot and a device tree for >>> FreeBSD and ... So yes, you're supposed to use the device tree for a >> ^ >> so I never get the answer to "the whole reason is...". >> >>> platform and it works here and there and every where. >> >> The fact that only Linux uses it makes it Linux specific. >> >>>> To expand even further on that, it means we should put 'managed = "in-band-status"' >>>> in U-Boot, which is a Linux phylink device tree property, even if U-Boot >>>> does not use phylink? >>> >>> We should be able to drop in the device trees from Linux and use them. >>> Custodians should be re-syncing them periodically. Some are, even. >> >> Are you ready to take up device tree bindings for PTP timers, PCIe root >> complex event collectors, cascaded interrupt controllers, things which >> U-Boot will never ever need to support? >> >> At least in Linux there is a policy to not add device tree nodes that do >> not have drivers. > > That is not the policy. The policy is DT nodes must have binding > (schema) documentation and the binding should be complete as possible > (not what some driver currently uses). However, for complex bindings, > it might be difficult to write the binding in absence of a driver. It is effective policy for some arches... When the K210 patches were submitted, any bindings for devices without enabled drivers were requested to be (and subsequently were) removed, even though many of those bindings were based off of existing documentation. This is the primary cause of divergence between the Linux and U-Boot devicetrees for this platform. It is also the main reason that I have not bothered putting together a sync patch. --Sean