Received: by 2002:a05:7412:8d1c:b0:fa:4c10:6cad with SMTP id bj28csp548740rdb; Wed, 17 Jan 2024 09:41:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IHvZGrktCj7DwNjmep8lW3pV7KyHpXwPIC5ZzvHsCOTgIJ7WqUWmsF9aQe4zEH7ifguP7x9 X-Received: by 2002:ac8:5fc1:0:b0:429:74f4:5adb with SMTP id k1-20020ac85fc1000000b0042974f45adbmr10238129qta.12.1705513284938; Wed, 17 Jan 2024 09:41:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705513284; cv=pass; d=google.com; s=arc-20160816; b=AgG6qXy7n12a4QhGJRBTaBbZtNTNsgzr+WfKgtP4LYJ/rGIbqOi814oWBD4VFT3Wec Bn+27daYu8qbG/R7o16bnk8mhtWJ9PFPgkG7ZDsRVzMwcArDcURN4GoPQMIQTodQqhqp YhfxljqSvopvqBh/QG+K8WJg2RO+cbOaOYwj2nDpK+k5NeP/K2dKTX4KeFooUR00A20M kuboAzUPrJBhPMGzYEJKLiC9HEyRkOx4fW3wTr/okDcwXtJKLXfCgc72I+0n7KqBiQ+P 7P2hYLxq5sZuCdJNe8oKADj5v+rmk7vrohrsCOMGx0FUdoO9M00Z2MmJjeD3k6A7RZUw Mvjg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=R3KIr93cXzFGXG0CIR3UTFsNxAvmBzln1Yix1gFoIcI=; fh=H/9kepTwWS0EMaR3cPuL/tNIH9SNpu1Qads1zi5u9iw=; b=GuKF2wHL6+jdFMpnvMDt5OxoAKAr9PhfJn0MQ6xY3FXgErnkGY56K4TO7sftbqY/jZ CubsxSbtnAozu9brLndDzeA1xmeVfR8/UzhPb99MMJTvK352nlJUQ625J+i42jwblzAo q+QtsvxZbyrhX6cuqE9zz9sOGiN5xxzOjKzzSBPQxOntxMqt9Ftf9WhgatzjvlJg5kuc R203XeWaCy3iIyvLhVStRsrIHrbw6mv0ROBUbAntn5uqmbtE2eQ11tNo3vW0XFD1D9uI 3bOjM53Q305YGCTQrmf7LbERofAFLmcqTbpI4R85+FbXN4NF1lKKbU/hycqDPe6ytgKi F0Fg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sBevjfMZ; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-29288-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29288-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id f27-20020a05620a12fb00b00783316bff67si12031722qkl.689.2024.01.17.09.41.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jan 2024 09:41:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-29288-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sBevjfMZ; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-29288-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29288-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id AF6841C2381C for ; Wed, 17 Jan 2024 17:41:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E288422EE9; Wed, 17 Jan 2024 17:41:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sBevjfMZ" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09F8222636; Wed, 17 Jan 2024 17:41:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705513277; cv=none; b=i9v6W4pFuy9GGoR7wsfonwnyQDTBhiezlnTvfpUEk1gkbDCVnqslPcf9j1zd/dSAfVhxDfjRQyLzjkdKUgrvJ9bnK8ig39UJwEVpTtiaaaXQSjSnb/mnd7HpMJyKX8ZO5jNqoQZbyoQSwynBqEAuUomNpoftNsekhVISY8cVLzw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705513277; c=relaxed/simple; bh=oMyiDD+Iv9PCZrZI/1gZAt5oqiBycCP8w9pHbV1lWu4=; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To; b=PMS3JKNnFYHfb2sZqv6mqdYH8/AjDA9cjUJjUW7HdDjffxC1fXGT+ZPmwsyntJulvkezwz32rs+FEJyrWn9ZuG7Ot11Vq542odLt904cFRtQtoUSHTtndV4XpHrY4TNrQhOtVv7X67Mjq5/rzXREYHn7ZlwNeD6OZ2KvJxFvEsc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sBevjfMZ; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42424C433F1; Wed, 17 Jan 2024 17:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705513276; bh=oMyiDD+Iv9PCZrZI/1gZAt5oqiBycCP8w9pHbV1lWu4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sBevjfMZJTsk0Z3N2eXC9xsiFZfpBm+jywM0ZqHd+H8ixc7g1WKJjwuH6xtzFfBD2 J/2kI0FLLvGFJZN4w8D6tmXCEt4L5wRmZio7hi+UHK1KJfw/mRDpDl7HjqPpnf4RU8 rqMCyz93kzjJHrIZ6uBDtVnNNvb5d0THqQ/RUACMVD+C0WgEmm8rYEyfKMeGoVowR8 p1/w87TVGdRe5AEc1BSDEQn6sv5oXKeQeodwLxz0UzRKhdNjjCtXYfuLpL1qjXbRLk xD1bt4pTdG61tolFQUqZjEDIqew5YSFbsSGrjl2HSQMbWLPWwKsm4WGRqvZoskDOwi /d5zpsGQIe1hQ== Date: Wed, 17 Jan 2024 11:41:14 -0600 From: Rob Herring To: Stephen Boyd Cc: Frank Rowand , linux-kernel@vger.kernel.org, patches@lists.linux.dev, linux-um@lists.infradead.org, linux-arm-kernel@lists.infradead.org, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 4/6] of: Create of_root if no dtb provided by firmware Message-ID: <20240117174114.GA2779523-robh@kernel.org> References: <20240112200750.4062441-1-sboyd@kernel.org> <20240112200750.4062441-5-sboyd@kernel.org> <20240115203230.GA1439771-robh@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jan 16, 2024 at 05:18:15PM -0800, Stephen Boyd wrote: > Quoting Rob Herring (2024-01-15 12:32:30) > > On Fri, Jan 12, 2024 at 12:07:47PM -0800, Stephen Boyd wrote: > > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > > > index da9826accb1b..9628e48baa15 100644 > > > --- a/drivers/of/Kconfig > > > +++ b/drivers/of/Kconfig > > > @@ -54,9 +54,14 @@ config OF_FLATTREE > > > select CRC32 > > > > > > config OF_EARLY_FLATTREE > > > - bool > > > + bool "Functions for accessing Flat Devicetree (FDT) early in boot" > > > > I think we could instead just get rid of this kconfig option. Or > > always enable with CONFIG_OF (except on Sparc). The only cost of > > enabling it is init section functions which get freed anyways. > > Getting rid of it is a more massive change. It can be the default and > kept hidden instead? If it can't be selected on Sparc then it should be > hidden there anyway. The easier option is certainly fine for this series. I just don't want it visible. > > > select DMA_DECLARE_COHERENT if HAS_DMA && HAS_IOMEM > > > select OF_FLATTREE > > > + help > > > + Normally selected by platforms that process an FDT that has been > > > + passed to the kernel by the bootloader. If the bootloader does not > > > + pass an FDT to the kernel and you need an empty devicetree that > > > + contains only a root node to exist, then say Y here. > > > > > > config OF_PROMTREE > > > bool > [...] > > > @@ -195,6 +191,17 @@ static inline int of_node_check_flag(const struct device_node *n, unsigned long > > > return test_bit(flag, &n->_flags); > > > } > > > > > > +/** > > > + * of_have_populated_dt() - Has DT been populated by bootloader > > > + * > > > + * Return: True if a DTB has been populated by the bootloader and it isn't the > > > + * empty builtin one. False otherwise. > > > + */ > > > +static inline bool of_have_populated_dt(void) > > > +{ > > > + return of_root != NULL && !of_node_check_flag(of_root, OF_EMPTY_ROOT); > > > > Just a side comment, but I think many/all callers of this function could > > just be removed. > > > > I don't love new flags. Another possible way to handle this would be > > checking for "compatible" being present in the root node. I guess this > > is fine as-is for now at least. > > Ok. I can add a check for a compatible property. That's probably better > anyway. Should there be a compatible property there to signal that this > DT isn't compatible with anything? I worry about DT overlays injecting a > compatible string into the root node, but maybe that is already > prevented. I worry about DT overlays injecting anything... I don't think it is explicitly forbidden, but I have asked that any general purpose interface to apply overlays be restricted to nodes explicitly allowed (e.g. downstream of a connector node). For now, the places (i.e. drivers) overlays are applied are limited. We could probably restrict the root node to new nodes only and no new or changed properties. Rob