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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 0BA9CC433E6 for ; Tue, 9 Feb 2021 17:12:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A2A4264EC0 for ; Tue, 9 Feb 2021 17:12:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233042AbhBIRMt (ORCPT ); Tue, 9 Feb 2021 12:12:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233025AbhBIRMr (ORCPT ); Tue, 9 Feb 2021 12:12:47 -0500 Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D556C061756 for ; Tue, 9 Feb 2021 09:11:29 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id u66so18251290oig.9 for ; Tue, 09 Feb 2021 09:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/M585z7ZzYXNwMMt9gcvkTvDIHc7/LPBrsNluqsDW04=; b=jjP+yMx/RnBV1Di0U/aHVSskc+93QxxwidegEwOpi9lmaTgAWGve0SttBEciPppPmA DunvXxLFRfsF/2VkhyAvba3hw9JBerLbbxDb28SWYBf3G6w0+OAbduiETqQhQyU8yIBU Pa+Up2445IBNhqbXnR8S/RlFeV8HU3nCYqtn3mgL6l3ttUE1UrarJvBlJ845xYtOlwik dV8O0tRLCEBm/xpkLctklvcbkPF1wkCoqbSiD9h7jQjr3Q7Bb/Q+3EX5CjDrZZYt7KG+ 72LeT6E/HjiJHn27Kjpv3ioubBhYwlW258NZTufp7uO+TykEV+IWHkf/p0Nyh/aNPYI/ JvxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=/M585z7ZzYXNwMMt9gcvkTvDIHc7/LPBrsNluqsDW04=; b=YXGpZzPvCIEZbFrH8Hrubo0psr4eK9lJMvmIXbWmOZR29QzaPs+TIWaqyxwI/H1KCd oZysKlfTox1NyLAq2Tkz6m3qsic8HhPVI1UajrakGApPQNYdRSg35L9apWLbAu9szRiV T7gAd9U5F1Etbgt6pMsXvVWbq28Kz0+cfM6tTN5viFe/EGzaMZC1U7y4KLX7dBaJdel5 yDcFxNB+7NxwU4H0C4I8sZIn1SWSKIEEAqxrcoXtz9S9rNjSFfiXC6xBwz7qIrZEHuxb 31+88CB3h8Rf0M7OCMOy6CK2cGIx9DjDQtYnP8bBGfGIIV0Du/Rw7Uz6q1QD/MRwKJb3 098g== X-Gm-Message-State: AOAM531EpMpHIExcSeEI11thZOwvVDKcS+5cyyXAe7AVLaNxgOxXzaIA 3QgoWzPAZmS+wb18tPvvDD4cnA== X-Google-Smtp-Source: ABdhPJwHt4G19lG9pP4nTma2e4koC2dEk87yls/3W9mzOMBIF8Jc/NpgIgypbQz3LP2NYfixSx9W1Q== X-Received: by 2002:aca:dd08:: with SMTP id u8mr3233941oig.55.1612890688863; Tue, 09 Feb 2021 09:11:28 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id m15sm4361297otl.11.2021.02.09.09.11.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Feb 2021 09:11:28 -0800 (PST) Date: Tue, 9 Feb 2021 11:11:26 -0600 From: Bjorn Andersson To: Rob Herring List-Id: Cc: Alexandre Belloni , Arnd Bergmann , Krzysztof Kozlowski , Geert Uytterhoeven , Olof Johansson , Arnd Bergmann , arm-soc , SoC Team , Linux ARM , "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" , "linux-kernel@vger.kernel.org" , Marek Szyprowski , Sylwester Nawrocki , DTML , Tony Lindgren , Frank Rowand , Gregory Clement , Nicolas Ferre , Linus Walleij , Shawn Guo , Geert Uytterhoeven , Alexandre Torgue , Kevin Hilman , Maxime Ripard Subject: Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12 Message-ID: References: <20210206134531.l5vpzlmev4v3f3uo@kozik-lap> <20210208184230.onhlioflyylkx6xo@kozik-lap> <20210208213537.GA351084@piout.net> <20210208231040.GF351084@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue 09 Feb 08:27 CST 2021, Rob Herring wrote: > On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni > wrote: > > > > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote: > > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni > > > wrote: > > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski wrote: > > > > > > Let me steer the discussion to original topic - it's about old kernel > > > > > > and new DTB, assuming that mainline kernel bisectability is not > > > > > > affected. > > > > > > > > > > > > Flow looks like this: > > > > > > > > > > > > 0. You have existing bidings and drivers. > > > > > > 1. Patch changing bindings (with new compatible) and drivers gets > > > > > > accepted by maintainer. > > > > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1. > > > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by > > > > > > maintainer and it is sent as v5.12-rc1 material to SoC maintainers. > > > > > > > > > > > > So again: old kernel, using old bindings, new DTB. > > > > > > > > > > > > > > I don't think forward compatibility was ever considered. I've seen it > > > > being mentioned a few times on #armlinux but honestly this simply can't > > > > be achieved. This would mean being able to write complete DT bindings > > > > for a particular SoC at day 0 which will realistically never happen. You > > > > may noteven have a complete datasheet and even if you have a datasheet, > > > > it may not be complete or it may be missing hw errata that are > > > > discovered later on and need a new binding to handle. > > > > > > You do not have to write the correct DT for this, the only requirement > > > is that any changes to a node are backward-compatible, which is > > > typically the case if you add properties or compatible strings without > > > removing the old one. A bugfix in this case is also backward-compatible. > > > > > > The part that can not happen instead is to write a DT that can expose > > > features that any future kernel will use. > > > > > > > But I think we are speaking about the other way around were you would be > > e.g. removing properties or splitting a node is multiple different > > nodes following a different understanding of the hardware. > > And in this case, any rework of the bindings will be forbidden, like > > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will > > break older kernels trying to use the new dtb. > > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is > > an other case. > > I'm not sure want to keep the older properties or the older compatible > > string as a fallback for this use case. > > > > > > > However, once the firmware is updated, it may no longer be possible to > > > > > go back to the old kernel in case the new one is busted. > > > > > > > > > > > > > Any serious update strategy will update both the kernel and device tree > > > > at the same time, exactly like you already have to update the initramfs > > > > with the kernel as soon as it is including kernel modules. > > > > I would expect any embedded platform to actually use a container format, > > > > like a FIT image that will ship the kernel, DT and intiramfs in a single > > > > image and will allow to sign all parts. > > > > > > Embedded systems that do this have no requirement for backward > > > or forward compatibility at all, the only requirement for these is bisectability > > > of git commits. > > > > > > > Yes and I can't see any drawbacks in this approach. > > > > > > > A similar problem can happen with the EBBR boot flow that relies on > > > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the > > > > > actual boot loader. This is commonly supported across distros. While > > > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run > > > > > that, this often fails in practice because u-boot needs to fill a > > > > > board specific set of DT properties (bootargs, detected memory, > > > > > mac address, ...). The usual way this gets handled is that u-boot loads > > > > > grub2 and the dtb from disk and then passes the modified dtb to grub, > > > > > which picks only kernel+initrd from disk and boots this with the dtb. > > > > > > > > > > The result is similar to case with dtb built into the firmware: after > > > > > upgrading the dtb that gets loaded by u-boot, grub can still pick > > > > > old kernels but they may not work as they did in the past. There are > > > > > obviously ways to work around it, but it does lead to user frustration. > > > > > > > > > > > > > Are there really any platforms with the dtb built into the firmware? > > > > I feel like this is a mythical creature used to scare people into keeping > > > > the DTB ABI stable. Aren't all the distribution already able to cope > > > > with keeping DTB and kernel in sync? > > > > > > I think most traditional PowerPC systems fall into this category, most > > > > My understanding was that the traditional PPC systems had a small device > > tree and usually are not affected by driver changes but I may be wrong. > > > > > systems that boot using UEFI+grub (as I explained), and anyone who > > > uses a distro kernel on custom hardware with their own dtb. > > > > > > > Aren't the ones using a distro kernel with a custom dtb more concerned > > by backward compatibility (i.e. new kernel with old dtb) rather than old > > kernel on new dtb? If they have an old dtb, an old kernel, and update to > > a new kernel, backward compatibility will ensure this continues to work. > > If then they work on updating their dtb, they still have the old one and > > can make the distribution match dtb and kernel. This is already handled > > properly by debian and I guess the other distributions as it is anyway > > already matching kernel and initramfs. > > SUSE is doing the opposite AIUI. This is a bit harder because adding > any new provider breaks compatibility as the old kernel will wait for > a non-existent driver for the new provider. That was the motivation > for deferred probe timeouts. Of course, I wouldn't really call a > platform stable if you are still adding clock, pinctrl, power-domain, > etc. providers. > IMHO "stable" in this context means that we've hit the point in development when these questions are no longer relevant. Either because the development is _done_ or more likely it's too old for anyone to care. Unfortunately this is the state that we're optimizing for and we're simply relying on luck to boot Linux on a reasonably complex machine. Regards, Bjorn