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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4E46AC636CD for ; Wed, 8 Feb 2023 01:33:21 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5934785E64; Wed, 8 Feb 2023 02:33:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="WIB456I3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4E89985D7F; Wed, 8 Feb 2023 02:33:15 +0100 (CET) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 1081A85DCE for ; Wed, 8 Feb 2023 02:33:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ej1-x62a.google.com with SMTP id sa10so17096882ejc.9 for ; Tue, 07 Feb 2023 17:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f18Iam8ArsrxR+F8oYNjgBEcxFwY485Xl1S7vazRn6o=; b=WIB456I3i1GIk3OY0w602sNbeCtbys6sCM03H5NIlgwCA7wyEP0gQ8w6cF2frJ2PMY fbPe0mftFs1SbolvsglK6z49Kzg33PzauglBWJdVMwhjVFlNnFEwkdOZUpRaBBsuDqTu b2wB39lF3Z2zhzCa76j8mm8hw4lbr8/1YhUJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f18Iam8ArsrxR+F8oYNjgBEcxFwY485Xl1S7vazRn6o=; b=Pr+bWUx34MAQjJtRBA4LMTxx5IzzPszMl3amRoS3pAvOZGMHvA0LvALQcemWAHQgCJ BIgEqWOajbWkZoEJLAR249tc7p4obZaBmK0ctNxaTDUDbLehEIW4zVFWzznMh5CzhIAc oT5S+7RXX8BU1nD1OQtkwCHLewGAytQjj0iClJj2oOnfsXFF7NLKBGnALL8SuPTgGEV/ qvCUktzMWmF37lwTpvpntWHGR76D78HdByZanUlgVCTHtjfsJpnMnzvQlXXF68KO6qZa NYYMhs/f+bHyghramcNLOOg9pTLYz/mC86iycpqCDx34ulzDWGDnwL2vAaFCgEW0Jft2 Gtnw== X-Gm-Message-State: AO0yUKX1D2P6QRMHd3ERASVm14QZGJnzsEeu0OJoTZi94+5kOimkD57x 1t6DmskbIVsceyghiEfboBd9BTNjqGBKu3Ai3Ga0ew== X-Google-Smtp-Source: AK7set8BieaCfI3CxiW5DLNwNMNwA2XdaYDjG2vDIdmqxSeNjo7j1yM0ykSLjiS5kqLnaLgAUVBcgXYx3oBI1ncHEG4= X-Received: by 2002:a17:906:6a94:b0:896:43bd:7915 with SMTP id p20-20020a1709066a9400b0089643bd7915mr1395328ejr.93.1675819990444; Tue, 07 Feb 2023 17:33:10 -0800 (PST) MIME-Version: 1.0 References: <20230201225428.2001161-1-sjg@chromium.org> <20230201225428.2001161-7-sjg@chromium.org> <5919786f-354d-7d7f-d2a7-19f0b7121a0c@amd.com> In-Reply-To: From: Simon Glass Date: Tue, 7 Feb 2023 18:32:58 -0700 Message-ID: Subject: Re: [PATCH v3 6/8] dm: treewide: Complete migration to new driver model schema To: Tom Rini Cc: Michal Simek , u-boot@lists.denx.de, U-Boot Custodians Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Tom, On Tue, 7 Feb 2023 at 17:16, Tom Rini wrote: > > On Tue, Feb 07, 2023 at 03:25:18PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 7 Feb 2023 at 14:46, Tom Rini wrote: > > > > > > On Tue, Feb 07, 2023 at 02:43:49PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 7 Feb 2023 at 14:06, Tom Rini wrote: > > > > > > > > > > On Mon, Feb 06, 2023 at 10:12:27AM -0700, Simon Glass wrote: > > > > > [snip] > > > > > > On Mon, 6 Feb 2023 at 07:56, Michal Simek wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/6/23 15:44, Tom Rini wrote: > > > > > > > > On Mon, Feb 06, 2023 at 01:22:48PM +0100, Michal Simek wrote: > > > > > > > >> Hi Simon, > > > > > > > >> > > > > > > > >> On 2/1/23 23:54, Simon Glass wrote: > > > > > > > >>> Update various build and test components to use the new schema. > > > > > > > >>> > > > > > > > >>> Signed-off-by: Simon Glass > > > > > > > >>> --- > > > > > > > >>> > > > > > > > >>> (no changes since v1) > > > > > > > >>> > > > > > > > >>> drivers/core/ofnode.c | 10 +++++----- > > > > > > > >>> drivers/video/video-uclass.c | 4 ++-- > > > > > > > >>> dts/Kconfig | 2 +- > > > > > > > >>> include/dm/device.h | 2 +- > > > > > > > >>> include/dm/ofnode.h | 10 +++++----- > > > > > > > >>> scripts/Makefile.lib | 12 ++++++------ > > > > > > > >>> test/dm/test-fdt.c | 2 +- > > > > > > > >>> test/py/tests/test_ofplatdata.py | 8 ++++---- > > > > > > > >>> tools/binman/binman.rst | 3 +-- > > > > > > > >>> tools/dtoc/test_fdt.py | 8 ++++---- > > > > > > > >>> 10 files changed, 30 insertions(+), 31 deletions(-) > > > > > > > >>> > > > > > > > >>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c > > > > > > > >>> index 4d56b1a7675..5249a60639b 100644 > > > > > > > >>> --- a/drivers/core/ofnode.c > > > > > > > >>> +++ b/drivers/core/ofnode.c > > > > > > > >>> @@ -1265,22 +1265,22 @@ bool ofnode_pre_reloc(ofnode node) > > > > > > > >>> { > > > > > > > >>> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_TPL_BUILD) > > > > > > > >>> /* for SPL and TPL the remaining nodes after the fdtgrep 1st pass > > > > > > > >>> - * had property dm-pre-reloc or u-boot,dm-spl/tpl. > > > > > > > >>> + * had property bootph-all or bootph-pre-sram/bootph-pre-ram. > > > > > > > >>> * They are removed in final dtb (fdtgrep 2nd pass) > > > > > > > >>> */ > > > > > > > >>> return true; > > > > > > > >>> #else > > > > > > > >>> - if (ofnode_read_bool(node, "u-boot,dm-pre-reloc")) > > > > > > > >>> + if (ofnode_read_bool(node, "bootph-all")) > > > > > > > >>> return true; > > > > > > > >>> - if (ofnode_read_bool(node, "u-boot,dm-pre-proper")) > > > > > > > >>> + if (ofnode_read_bool(node, "bootph-some-ram")) > > > > > > > >>> return true; > > > > > > > >>> /* > > > > > > > >>> * In regular builds individual spl and tpl handling both > > > > > > > >>> * count as handled pre-relocation for later second init. > > > > > > > >>> */ > > > > > > > >>> - if (ofnode_read_bool(node, "u-boot,dm-spl") || > > > > > > > >>> - ofnode_read_bool(node, "u-boot,dm-tpl")) > > > > > > > >>> + if (ofnode_read_bool(node, "bootph-pre-ram") || > > > > > > > >>> + ofnode_read_bool(node, "bootph-pre-sram")) > > > > > > > >>> return true; > > > > > > > >> > > > > > > > >> Please correct me if I am wrong but this change will likely break all boards > > > > > > > >> which didn't migrate to this at this stage. And because targeting early > > > > > > > >> stages people will be without console. > > > > > > > >> I think we should have transition period for 1-2 releases to give people > > > > > > > >> enough time to migrate. It means print big warning that they have to migrate > > > > > > > >> their DTS. > > > > > > > > > > > > > > > > What's the migration case here we're missing? Is it platforms that > > > > > > > > maintain a dts externally, via tooling / etc, that populate those nodes? > > > > > > > > > > > > > > Yes and I expect there will be a lot of DTs around with some changes for > > > > > > > specific products. > > > > > > > > > > > > > > Also for example QEMU is also generating DT based on it's configuration and > > > > > > > provide it to U-Boot. > > > > > > > https://gitlab.com/qemu-project/qemu/-/blob/master/hw/arm/xlnx-versal-virt.c#L91 > > > > > > > When this patch is applied CI loop should fail for Versal. > > > > > > > > > > > > I am not sure how it helps us to drag this out. It is a breaking > > > > > > change, but a drawn-out process is just going to create a lot of > > > > > > confusion. People should be free to use the schema in Linux .dts files > > > > > > from now on, but if it is not immediately supported in U-Boot then > > > > > > they cannot. This is the most important point, after all. > > > > > > > > > > Now that we've had some of the external migration issues laid out, what > > > > > would it look like to have some sort of backwards compatible hook here > > > > > to fixup an older tree we've been passed? > > > > > > > > We can't do it for SPL, since the processing happens at built time, > > > > but for U-Boot proper we can do something like what Michal suggests, > > > > although perhaps with a warning rather than an error. Likely the > > > > warning would have to be displayed later (if/when U-Boot starts up) > > > > since the console may be one of the problem nodes. > > > > > > Right, if it's a build time thing, we should be able to ... something. > > > Maybe a detect and rename for now, detect and fail in a bit. But > > > > But we only have this problem with out-of-tree .dts files, so I'm not > > sure what you are suggesting here. > > I'm suggesting that you add the logic to detect these cases and deal > with it. We aren't talking about stuff that should have been upstreamed > but wasn't, we're talking about tooling that generates valid dts files > and needs time to update. For runtime I think we can do something like what Michal suggested, but more permissive. We can warn about it when U-Boot has started up. There is no point in doing anything like that in the SPL phase as it is too late. But we can also add a build-time check, as you say. I think you are saying that it should work correctly in that case, rather than just fail? That is easy enough for U-Boot proper I think. For SPL I am not sure. I will take a look. Regards, Simon