devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] checks: Suppress warnings on overlay fragments
@ 2023-03-08  9:15 Qun-Wei Lin
       [not found] ` <20230308091539.11178-1-qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Qun-Wei Lin @ 2023-03-08  9:15 UTC (permalink / raw)
  To: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+
  Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
	casper.li-NuS5LvNUpcJWk0Htik3J/w,
	chinwen.chang-NuS5LvNUpcJWk0Htik3J/w,
	kuan-ying.lee-NuS5LvNUpcJWk0Htik3J/w,
	ivan.tseng-NuS5LvNUpcJWk0Htik3J/w,
	ladon.huang-NuS5LvNUpcJWk0Htik3J/w, Qun-Wei Lin

The overlay fragment is a special case where some properties are not
present in the overlay source file, but in the base file.

example:
+-----------------------------+--------------------+
| base.dts                    | overlay.dts        |
+-----------------------------+--------------------+
| /dts-v1/;                   | /dts-v1/;          |
|                             | /plugin/;          |
| /{                          |                    |
|   parent: test {            | &parent {          |
|     #address-cells = <1>;   |   child@0 {        |
|     #size-cells = <0>;      |     reg = <0x0>;   |
|   };                        |   };               |
| };                          | };                 |
+-----------------------------+--------------------+

It will cause the following false alarms when compiling the overlay dts.

1. /fragment@0/__overlay__: Character '_' not recommended in node name
2. /fragment@0/__overlay__: Relying on default #address-cells value
3. /fragment@0/__overlay__: Relying on default #size-cells value
4. /fragment@0/__overlay__:reg: property has invalid length (4 bytes)
   (#address-cells == 2, #size-cells == 1)

This workaround will fix them by skip checking for node named __overlay__.

Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
V1 -> V2:
 - Add is_overlay_node() helper
 - Skip anything starting with "__" in check_node_name_chars_strict()

 checks.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/checks.c b/checks.c
index 69f2649..637c6da 100644
--- a/checks.c
+++ b/checks.c
@@ -151,6 +151,11 @@ static bool is_multiple_of(int multiple, int divisor)
 		return (multiple % divisor) == 0;
 }
 
+static bool is_overlay_node(struct node *node)
+{
+	return streq(node->name, "__overlay__");
+}
+
 static bool run_check(struct check *c, struct dt_info *dti)
 {
 	struct node *dt = dti->dt;
@@ -325,6 +330,13 @@ static void check_node_name_chars_strict(struct check *c, struct dt_info *dti,
 {
 	int n = strspn(node->name, c->data);
 
+	/*
+	 * Do not check __overlay__, __fixups__, __local_fixups__, etc.
+	 * These node names starting with "__" are automatically generated by DTC.
+	 */
+	if (!strncmp(node->name, "__", 2))
+		return;
+
 	if (n < node->basenamelen)
 		FAIL(c, dti, node, "Character '%c' not recommended in node name",
 		     node->name[n]);
@@ -767,6 +779,9 @@ static void check_reg_format(struct check *c, struct dt_info *dti,
 		return;
 	}
 
+	if (is_overlay_node(node->parent))
+		return;
+
 	if (prop->val.len == 0)
 		FAIL_PROP(c, dti, node, prop, "property is empty");
 
@@ -1197,6 +1212,9 @@ static void check_avoid_default_addr_size(struct check *c, struct dt_info *dti,
 	if (!node->parent)
 		return; /* Ignore root node */
 
+	if (is_overlay_node(node->parent))
+		return;
+
 	reg = get_property(node, "reg");
 	ranges = get_property(node, "ranges");
 
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
       [not found] ` <20230308091539.11178-1-qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
@ 2023-03-09 15:12   ` Rob Herring
       [not found]     ` <CAL_JsqKTM=gaQGZhrBCRkBusYYMci0mJGAFf9RTvCx00G2OJzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Rob Herring @ 2023-03-09 15:12 UTC (permalink / raw)
  To: Qun-Wei Lin
  Cc: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+,
	devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
	casper.li-NuS5LvNUpcJWk0Htik3J/w,
	chinwen.chang-NuS5LvNUpcJWk0Htik3J/w,
	kuan-ying.lee-NuS5LvNUpcJWk0Htik3J/w,
	ivan.tseng-NuS5LvNUpcJWk0Htik3J/w,
	ladon.huang-NuS5LvNUpcJWk0Htik3J/w

On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcLQFizaE/u3fw@public.gmane.orgm> wrote:
>
> The overlay fragment is a special case where some properties are not
> present in the overlay source file, but in the base file.
>
> example:
> +-----------------------------+--------------------+
> | base.dts                    | overlay.dts        |
> +-----------------------------+--------------------+
> | /dts-v1/;                   | /dts-v1/;          |
> |                             | /plugin/;          |
> | /{                          |                    |
> |   parent: test {            | &parent {          |
> |     #address-cells = <1>;   |   child@0 {        |
> |     #size-cells = <0>;      |     reg = <0x0>;   |
> |   };                        |   };               |
> | };                          | };                 |
> +-----------------------------+--------------------+
>
> It will cause the following false alarms when compiling the overlay dts.
>
> 1. /fragment@0/__overlay__: Character '_' not recommended in node name
> 2. /fragment@0/__overlay__: Relying on default #address-cells value
> 3. /fragment@0/__overlay__: Relying on default #size-cells value
> 4. /fragment@0/__overlay__:reg: property has invalid length (4 bytes)
>    (#address-cells == 2, #size-cells == 1)
>
> This workaround will fix them by skip checking for node named __overlay__.
>
> Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> V1 -> V2:
>  - Add is_overlay_node() helper
>  - Skip anything starting with "__" in check_node_name_chars_strict()
>
>  checks.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Though I do wonder if as a matter of policy on overlay structure, if
we should require an overlay to have the parent node with
#address-cells/#size-cells. In the end that would be duplicated data,
but without it there's no way to parse and validate reg/ranges in an
unapplied overlay. That's just one example issue in being able to
validate overlays.

Rob

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
       [not found]     ` <CAL_JsqKTM=gaQGZhrBCRkBusYYMci0mJGAFf9RTvCx00G2OJzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2023-04-13 12:43       ` Qun-wei Lin (林群崴)
       [not found]         ` <347151917fb777e66a54e983efbbe0303f63e01a.camel-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Qun-wei Lin (林群崴) @ 2023-04-13 12:43 UTC (permalink / raw)
  To: robh-DgEjT+Ai2ygdnm+yROfE0A
  Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
	Casper Li (李中榮),
	david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+,
	Kuan-Ying Lee (李冠穎),
	Chinwen Chang (張錦文),
	Ivan Tseng (曾志軒)

On Thu, 2023-03-09 at 09:12 -0600, Rob Herring wrote:
> On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin@mediatek.com>
> wrote:
> > 
> > The overlay fragment is a special case where some properties are
> > not
> > present in the overlay source file, but in the base file.
> > 
> > example:
> > +-----------------------------+--------------------+
> > > base.dts                    | overlay.dts        |
> > 
> > +-----------------------------+--------------------+
> > > /dts-v1/;                   | /dts-v1/;          |
> > >                             | /plugin/;          |
> > > /{                          |                    |
> > >   parent: test {            | &parent {          |
> > >     #address-cells = <1>;   |   child@0 {        |
> > >     #size-cells = <0>;      |     reg = <0x0>;   |
> > >   };                        |   };               |
> > > };                          | };                 |
> > 
> > +-----------------------------+--------------------+
> > 
> > It will cause the following false alarms when compiling the overlay
> > dts.
> > 
> > 1. /fragment@0/__overlay__: Character '_' not recommended in node
> > name
> > 2. /fragment@0/__overlay__: Relying on default #address-cells value
> > 3. /fragment@0/__overlay__: Relying on default #size-cells value
> > 4. /fragment@0/__overlay__:reg: property has invalid length (4
> > bytes)
> >    (#address-cells == 2, #size-cells == 1)
> > 
> > This workaround will fix them by skip checking for node named
> > __overlay__.
> > 
> > Signed-off-by: Qun-Wei Lin <qun-wei.lin@mediatek.com>
> > ---
> > V1 -> V2:
> >  - Add is_overlay_node() helper
> >  - Skip anything starting with "__" in
> > check_node_name_chars_strict()
> > 
> >  checks.c | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> 
> Though I do wonder if as a matter of policy on overlay structure, if
> we should require an overlay to have the parent node with
> #address-cells/#size-cells. In the end that would be duplicated data,
> but without it there's no way to parse and validate reg/ranges in an
> unapplied overlay. That's just one example issue in being able to
> validate overlays.
> 
> Rob

Hi Rob,

Thank you for your review.

I think I've found another problem:
+-------------------------+----------------+
| base.dts                | overlay.dts    |
+-------------------------+----------------+
| /dts-v1/;               | /dts-v1/;      |
| /{                      | /plugin/;      |
|   #address-cells = <1>; |                |
|   #size-cells = <0>;    | &test {        |
|   test: example@0 {     |   reg = <0x1>; |
|     reg = <0x0>;        | };             |
|   };                    |                |
| };                      |                |
+-------------------------+----------------+

The following error message is printed when compiling:
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid
length (4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg
or ranges property, but no unit name
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
default #address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
default #size-cells value

We can't get the #address-cells/#size-cells of the parent of the
example node in the overlay structure.
Do you think we should change it to is_overlay_node(node) instead of
is_overlay_node(node->parent)?
Or we just need to skip checking for node names starting with "__" in
check_node_name_chars_strict()?

Qun-Wei

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
       [not found]         ` <347151917fb777e66a54e983efbbe0303f63e01a.camel-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
@ 2023-04-18 17:33           ` Rob Herring
       [not found]             ` <CAL_Jsq+L50RZ-s55tncFMHA1AwL5An13n2OVPzknnpu=uOvzhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Rob Herring @ 2023-04-18 17:33 UTC (permalink / raw)
  To: Qun-wei Lin (林群崴)
  Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
	Casper Li (李中榮),
	david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+,
	Kuan-Ying Lee (李冠穎),
	Chinwen Chang (張錦文),
	Ivan Tseng (曾志軒)

On Thu, Apr 13, 2023 at 7:44 AM Qun-wei Lin (林群崴)
<Qun-wei.Lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>
> On Thu, 2023-03-09 at 09:12 -0600, Rob Herring wrote:
> > On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin@mediatek.com>
> > wrote:
> > >
> > > The overlay fragment is a special case where some properties are
> > > not
> > > present in the overlay source file, but in the base file.
> > >
> > > example:
> > > +-----------------------------+--------------------+
> > > > base.dts                    | overlay.dts        |
> > >
> > > +-----------------------------+--------------------+
> > > > /dts-v1/;                   | /dts-v1/;          |
> > > >                             | /plugin/;          |
> > > > /{                          |                    |
> > > >   parent: test {            | &parent {          |
> > > >     #address-cells = <1>;   |   child@0 {        |
> > > >     #size-cells = <0>;      |     reg = <0x0>;   |
> > > >   };                        |   };               |
> > > > };                          | };                 |
> > >
> > > +-----------------------------+--------------------+
> > >
> > > It will cause the following false alarms when compiling the overlay
> > > dts.
> > >
> > > 1. /fragment@0/__overlay__: Character '_' not recommended in node
> > > name
> > > 2. /fragment@0/__overlay__: Relying on default #address-cells value
> > > 3. /fragment@0/__overlay__: Relying on default #size-cells value
> > > 4. /fragment@0/__overlay__:reg: property has invalid length (4
> > > bytes)
> > >    (#address-cells == 2, #size-cells == 1)
> > >
> > > This workaround will fix them by skip checking for node named
> > > __overlay__.
> > >
> > > Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > > ---
> > > V1 -> V2:
> > >  - Add is_overlay_node() helper
> > >  - Skip anything starting with "__" in
> > > check_node_name_chars_strict()
> > >
> > >  checks.c | 18 ++++++++++++++++++
> > >  1 file changed, 18 insertions(+)
> >
> > Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Though I do wonder if as a matter of policy on overlay structure, if
> > we should require an overlay to have the parent node with
> > #address-cells/#size-cells. In the end that would be duplicated data,
> > but without it there's no way to parse and validate reg/ranges in an
> > unapplied overlay. That's just one example issue in being able to
> > validate overlays.
> >
> > Rob
>
> Hi Rob,
>
> Thank you for your review.
>
> I think I've found another problem:
> +-------------------------+----------------+
> | base.dts                | overlay.dts    |
> +-------------------------+----------------+
> | /dts-v1/;               | /dts-v1/;      |
> | /{                      | /plugin/;      |
> |   #address-cells = <1>; |                |
> |   #size-cells = <0>;    | &test {        |
> |   test: example@0 {     |   reg = <0x1>; |
> |     reg = <0x0>;        | };             |
> |   };                    |                |
> | };                      |                |
> +-------------------------+----------------+
>
> The following error message is printed when compiling:
> Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid
> length (4 bytes) (#address-cells == 2, #size-cells == 1)
> Warning (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg
> or ranges property, but no unit name
> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
> default #address-cells value
> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
> default #size-cells value
>
> We can't get the #address-cells/#size-cells of the parent of the
> example node in the overlay structure.
> Do you think we should change it to is_overlay_node(node) instead of
> is_overlay_node(node->parent)?
> Or we just need to skip checking for node names starting with "__" in
> check_node_name_chars_strict()?

I think this is the tip of the iceberg in terms of being able to
validate overlays. Turning off address checks just kicks the problem
to schema validation.  Perhaps the overlay should be structured to
include the parent bus node with #address-cells and #size-cells.

Rob

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
       [not found]             ` <CAL_Jsq+L50RZ-s55tncFMHA1AwL5An13n2OVPzknnpu=uOvzhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2023-05-14  6:42               ` david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+
  2024-01-16 12:54                 ` Roger Quadros
  0 siblings, 1 reply; 8+ messages in thread
From: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+ @ 2023-05-14  6:42 UTC (permalink / raw)
  To: Rob Herring
  Cc: Qun-wei Lin (林群崴),
	devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
	Casper Li (李中榮),
	Kuan-Ying Lee (李冠穎),
	Chinwen Chang (張錦文),
	Ivan Tseng (曾志軒)

[-- Attachment #1: Type: text/plain, Size: 5647 bytes --]

On Tue, Apr 18, 2023 at 12:33:26PM -0500, Rob Herring wrote:
> On Thu, Apr 13, 2023 at 7:44 AM Qun-wei Lin (林群崴)
> <Qun-wei.Lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >
> > On Thu, 2023-03-09 at 09:12 -0600, Rob Herring wrote:
> > > On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin@mediatek.com>
> > > wrote:
> > > >
> > > > The overlay fragment is a special case where some properties are
> > > > not
> > > > present in the overlay source file, but in the base file.
> > > >
> > > > example:
> > > > +-----------------------------+--------------------+
> > > > > base.dts                    | overlay.dts        |
> > > >
> > > > +-----------------------------+--------------------+
> > > > > /dts-v1/;                   | /dts-v1/;          |
> > > > >                             | /plugin/;          |
> > > > > /{                          |                    |
> > > > >   parent: test {            | &parent {          |
> > > > >     #address-cells = <1>;   |   child@0 {        |
> > > > >     #size-cells = <0>;      |     reg = <0x0>;   |
> > > > >   };                        |   };               |
> > > > > };                          | };                 |
> > > >
> > > > +-----------------------------+--------------------+
> > > >
> > > > It will cause the following false alarms when compiling the overlay
> > > > dts.
> > > >
> > > > 1. /fragment@0/__overlay__: Character '_' not recommended in node
> > > > name
> > > > 2. /fragment@0/__overlay__: Relying on default #address-cells value
> > > > 3. /fragment@0/__overlay__: Relying on default #size-cells value
> > > > 4. /fragment@0/__overlay__:reg: property has invalid length (4
> > > > bytes)
> > > >    (#address-cells == 2, #size-cells == 1)
> > > >
> > > > This workaround will fix them by skip checking for node named
> > > > __overlay__.
> > > >
> > > > Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > > > ---
> > > > V1 -> V2:
> > > >  - Add is_overlay_node() helper
> > > >  - Skip anything starting with "__" in
> > > > check_node_name_chars_strict()
> > > >
> > > >  checks.c | 18 ++++++++++++++++++
> > > >  1 file changed, 18 insertions(+)
> > >
> > > Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > >
> > > Though I do wonder if as a matter of policy on overlay structure, if
> > > we should require an overlay to have the parent node with
> > > #address-cells/#size-cells. In the end that would be duplicated data,
> > > but without it there's no way to parse and validate reg/ranges in an
> > > unapplied overlay. That's just one example issue in being able to
> > > validate overlays.
> > >
> > > Rob
> >
> > Hi Rob,
> >
> > Thank you for your review.
> >
> > I think I've found another problem:
> > +-------------------------+----------------+
> > | base.dts                | overlay.dts    |
> > +-------------------------+----------------+
> > | /dts-v1/;               | /dts-v1/;      |
> > | /{                      | /plugin/;      |
> > |   #address-cells = <1>; |                |
> > |   #size-cells = <0>;    | &test {        |
> > |   test: example@0 {     |   reg = <0x1>; |
> > |     reg = <0x0>;        | };             |
> > |   };                    |                |
> > | };                      |                |
> > +-------------------------+----------------+
> >
> > The following error message is printed when compiling:
> > Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid
> > length (4 bytes) (#address-cells == 2, #size-cells == 1)
> > Warning (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg
> > or ranges property, but no unit name
> > Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
> > default #address-cells value
> > Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
> > default #size-cells value
> >
> > We can't get the #address-cells/#size-cells of the parent of the
> > example node in the overlay structure.
> > Do you think we should change it to is_overlay_node(node) instead of
> > is_overlay_node(node->parent)?
> > Or we just need to skip checking for node names starting with "__" in
> > check_node_name_chars_strict()?
> 
> I think this is the tip of the iceberg in terms of being able to
> validate overlays. Turning off address checks just kicks the problem
> to schema validation.  Perhaps the overlay should be structured to
> include the parent bus node with #address-cells and #size-cells.

Right.  So, I think to handle this properly we need to change the
structure of dtc:

  * Rather than applying source level overlays as we parse them, we
    should parse them each separately into a structure, then
    internally apply them

  * Checks would then need to be divided into those (A) that can be
    checked on any individual overlay fragment, and those (B) that can
    only be checked on a complete tree

  * We'd run the (A) checks before merging the overlays in dtc, and
    the (B) checks only after doing so.

  * For runtime overlays (/plugin/) we'd skip the (B) checks entirely,
    which would accomplish what you're aiming for here.

I had plans to make a restructure like this quite a while ago, but
I've never had the time to go ahead with it.  If you want to give it a
go, that would be great.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
  2023-05-14  6:42               ` david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+
@ 2024-01-16 12:54                 ` Roger Quadros
  2024-01-22 16:01                   ` Rob Herring
  0 siblings, 1 reply; 8+ messages in thread
From: Roger Quadros @ 2024-01-16 12:54 UTC (permalink / raw)
  To: david, Rob Herring
  Cc: Qun-wei Lin (林群崴),
	Casper Li (李中榮),
	Kuan-Ying Lee (李冠穎),
	Chinwen Chang (張錦文),
	Ivan Tseng (曾志軒),
	devicetree-compiler, Bajjuri, Praneeth

Hi David & Rob,

On 14/05/2023 09:42, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org wrote:
> On Tue, Apr 18, 2023 at 12:33:26PM -0500, Rob Herring wrote:
>> On Thu, Apr 13, 2023 at 7:44 AM Qun-wei Lin (林群崴)
>> <Qun-wei.Lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>
>>> On Thu, 2023-03-09 at 09:12 -0600, Rob Herring wrote:
>>>> On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin@mediatek.com>
>>>> wrote:
>>>>>
>>>>> The overlay fragment is a special case where some properties are
>>>>> not
>>>>> present in the overlay source file, but in the base file.
>>>>>
>>>>> example:
>>>>> +-----------------------------+--------------------+
>>>>>> base.dts                    | overlay.dts        |
>>>>>
>>>>> +-----------------------------+--------------------+
>>>>>> /dts-v1/;                   | /dts-v1/;          |
>>>>>>                             | /plugin/;          |
>>>>>> /{                          |                    |
>>>>>>   parent: test {            | &parent {          |
>>>>>>     #address-cells = <1>;   |   child@0 {        |
>>>>>>     #size-cells = <0>;      |     reg = <0x0>;   |
>>>>>>   };                        |   };               |
>>>>>> };                          | };                 |
>>>>>
>>>>> +-----------------------------+--------------------+
>>>>>
>>>>> It will cause the following false alarms when compiling the overlay
>>>>> dts.
>>>>>
>>>>> 1. /fragment@0/__overlay__: Character '_' not recommended in node
>>>>> name
>>>>> 2. /fragment@0/__overlay__: Relying on default #address-cells value
>>>>> 3. /fragment@0/__overlay__: Relying on default #size-cells value
>>>>> 4. /fragment@0/__overlay__:reg: property has invalid length (4
>>>>> bytes)
>>>>>    (#address-cells == 2, #size-cells == 1)
>>>>>
>>>>> This workaround will fix them by skip checking for node named
>>>>> __overlay__.
>>>>>
>>>>> Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> V1 -> V2:
>>>>>  - Add is_overlay_node() helper
>>>>>  - Skip anything starting with "__" in
>>>>> check_node_name_chars_strict()
>>>>>
>>>>>  checks.c | 18 ++++++++++++++++++
>>>>>  1 file changed, 18 insertions(+)
>>>>
>>>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>
>>>> Though I do wonder if as a matter of policy on overlay structure, if
>>>> we should require an overlay to have the parent node with
>>>> #address-cells/#size-cells. In the end that would be duplicated data,
>>>> but without it there's no way to parse and validate reg/ranges in an
>>>> unapplied overlay. That's just one example issue in being able to
>>>> validate overlays.
>>>>
>>>> Rob
>>>
>>> Hi Rob,
>>>
>>> Thank you for your review.
>>>
>>> I think I've found another problem:
>>> +-------------------------+----------------+
>>> | base.dts                | overlay.dts    |
>>> +-------------------------+----------------+
>>> | /dts-v1/;               | /dts-v1/;      |
>>> | /{                      | /plugin/;      |
>>> |   #address-cells = <1>; |                |
>>> |   #size-cells = <0>;    | &test {        |
>>> |   test: example@0 {     |   reg = <0x1>; |
>>> |     reg = <0x0>;        | };             |
>>> |   };                    |                |
>>> | };                      |                |
>>> +-------------------------+----------------+
>>>
>>> The following error message is printed when compiling:
>>> Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid
>>> length (4 bytes) (#address-cells == 2, #size-cells == 1)
>>> Warning (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg
>>> or ranges property, but no unit name
>>> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
>>> default #address-cells value
>>> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
>>> default #size-cells value
>>>
>>> We can't get the #address-cells/#size-cells of the parent of the
>>> example node in the overlay structure.
>>> Do you think we should change it to is_overlay_node(node) instead of
>>> is_overlay_node(node->parent)?
>>> Or we just need to skip checking for node names starting with "__" in
>>> check_node_name_chars_strict()?
>>
>> I think this is the tip of the iceberg in terms of being able to
>> validate overlays. Turning off address checks just kicks the problem
>> to schema validation.  Perhaps the overlay should be structured to
>> include the parent bus node with #address-cells and #size-cells.
> 
> Right.  So, I think to handle this properly we need to change the
> structure of dtc:
> 
>   * Rather than applying source level overlays as we parse them, we
>     should parse them each separately into a structure, then
>     internally apply them
> 
>   * Checks would then need to be divided into those (A) that can be
>     checked on any individual overlay fragment, and those (B) that can
>     only be checked on a complete tree
> 
>   * We'd run the (A) checks before merging the overlays in dtc, and
>     the (B) checks only after doing so.
> 
>   * For runtime overlays (/plugin/) we'd skip the (B) checks entirely,
>     which would accomplish what you're aiming for here.
> 
> I had plans to make a restructure like this quite a while ago, but
> I've never had the time to go ahead with it.  If you want to give it a
> go, that would be great.
> 

FYI.
I'm facing a somewhat similar issue with this patch [1]
[1] https://lore.kernel.org/all/20230923080046.5373-2-rogerq@kernel.org/

arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #address-cells value
arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #size-cells value

To give some background:

The GPMC block has separate address spaces per chip select.

 From Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
   ranges:
     minItems: 1
     description: |
       Must be set up to reflect the memory layout with four
       integer values for each chip-select line in use,
       <cs-number> 0 <physical address of mapping> <size>

The ranges location in the device tree overlay is correct. The overlay is
obviously meaningless without the base tree. It depends on the #address-cells
and #size-cells defined in the base tree.

Your proposal to fix this is valid but is definitely not trivial to fix
especially for someone who is not familiar with dtc internals. :P

Is there something simpler we could do to resolve this issue for overlay nodes.
e.g. For overlay nodes we skip the "Relying on default address/size" check?

diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c
index 9f31d2607182..a4e94c4b7b08 100644
--- a/scripts/dtc/checks.c
+++ b/scripts/dtc/checks.c
@@ -1197,6 +1197,9 @@ static void check_avoid_default_addr_size(struct check *c, struct dt_info *dti,
 	if (!node->parent)
 		return; /* Ignore root node */
 
+	if (streq(node->name, "__overlay__"))
+		return; /* Ignore overlay nodes */
+
 	reg = get_property(node, "reg");
 	ranges = get_property(node, "ranges");

-- 
cheers,
-roger

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
  2024-01-16 12:54                 ` Roger Quadros
@ 2024-01-22 16:01                   ` Rob Herring
  2024-01-23 14:49                     ` Roger Quadros
  0 siblings, 1 reply; 8+ messages in thread
From: Rob Herring @ 2024-01-22 16:01 UTC (permalink / raw)
  To: Roger Quadros
  Cc: david, Qun-wei Lin (林群崴),
	Casper Li (李中榮),
	Kuan-Ying Lee (李冠穎),
	Chinwen Chang (張錦文),
	Ivan Tseng (曾志軒),
	devicetree-compiler, Bajjuri, Praneeth

On Tue, Jan 16, 2024 at 02:54:23PM +0200, Roger Quadros wrote:
> Hi David & Rob,
> 
> On 14/05/2023 09:42, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org wrote:
> > On Tue, Apr 18, 2023 at 12:33:26PM -0500, Rob Herring wrote:
> >> On Thu, Apr 13, 2023 at 7:44 AM Qun-wei Lin (林群崴)
> >> <Qun-wei.Lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >>>
> >>> On Thu, 2023-03-09 at 09:12 -0600, Rob Herring wrote:
> >>>> On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin@mediatek.com>
> >>>> wrote:
> >>>>>
> >>>>> The overlay fragment is a special case where some properties are
> >>>>> not
> >>>>> present in the overlay source file, but in the base file.
> >>>>>
> >>>>> example:
> >>>>> +-----------------------------+--------------------+
> >>>>>> base.dts                    | overlay.dts        |
> >>>>>
> >>>>> +-----------------------------+--------------------+
> >>>>>> /dts-v1/;                   | /dts-v1/;          |
> >>>>>>                             | /plugin/;          |
> >>>>>> /{                          |                    |
> >>>>>>   parent: test {            | &parent {          |
> >>>>>>     #address-cells = <1>;   |   child@0 {        |
> >>>>>>     #size-cells = <0>;      |     reg = <0x0>;   |
> >>>>>>   };                        |   };               |
> >>>>>> };                          | };                 |
> >>>>>
> >>>>> +-----------------------------+--------------------+
> >>>>>
> >>>>> It will cause the following false alarms when compiling the overlay
> >>>>> dts.
> >>>>>
> >>>>> 1. /fragment@0/__overlay__: Character '_' not recommended in node
> >>>>> name
> >>>>> 2. /fragment@0/__overlay__: Relying on default #address-cells value
> >>>>> 3. /fragment@0/__overlay__: Relying on default #size-cells value
> >>>>> 4. /fragment@0/__overlay__:reg: property has invalid length (4
> >>>>> bytes)
> >>>>>    (#address-cells == 2, #size-cells == 1)
> >>>>>
> >>>>> This workaround will fix them by skip checking for node named
> >>>>> __overlay__.
> >>>>>
> >>>>> Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>> ---
> >>>>> V1 -> V2:
> >>>>>  - Add is_overlay_node() helper
> >>>>>  - Skip anything starting with "__" in
> >>>>> check_node_name_chars_strict()
> >>>>>
> >>>>>  checks.c | 18 ++++++++++++++++++
> >>>>>  1 file changed, 18 insertions(+)
> >>>>
> >>>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>>
> >>>> Though I do wonder if as a matter of policy on overlay structure, if
> >>>> we should require an overlay to have the parent node with
> >>>> #address-cells/#size-cells. In the end that would be duplicated data,
> >>>> but without it there's no way to parse and validate reg/ranges in an
> >>>> unapplied overlay. That's just one example issue in being able to
> >>>> validate overlays.
> >>>>
> >>>> Rob
> >>>
> >>> Hi Rob,
> >>>
> >>> Thank you for your review.
> >>>
> >>> I think I've found another problem:
> >>> +-------------------------+----------------+
> >>> | base.dts                | overlay.dts    |
> >>> +-------------------------+----------------+
> >>> | /dts-v1/;               | /dts-v1/;      |
> >>> | /{                      | /plugin/;      |
> >>> |   #address-cells = <1>; |                |
> >>> |   #size-cells = <0>;    | &test {        |
> >>> |   test: example@0 {     |   reg = <0x1>; |
> >>> |     reg = <0x0>;        | };             |
> >>> |   };                    |                |
> >>> | };                      |                |
> >>> +-------------------------+----------------+
> >>>
> >>> The following error message is printed when compiling:
> >>> Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid
> >>> length (4 bytes) (#address-cells == 2, #size-cells == 1)
> >>> Warning (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg
> >>> or ranges property, but no unit name
> >>> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
> >>> default #address-cells value
> >>> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
> >>> default #size-cells value
> >>>
> >>> We can't get the #address-cells/#size-cells of the parent of the
> >>> example node in the overlay structure.
> >>> Do you think we should change it to is_overlay_node(node) instead of
> >>> is_overlay_node(node->parent)?
> >>> Or we just need to skip checking for node names starting with "__" in
> >>> check_node_name_chars_strict()?
> >>
> >> I think this is the tip of the iceberg in terms of being able to
> >> validate overlays. Turning off address checks just kicks the problem
> >> to schema validation.  Perhaps the overlay should be structured to
> >> include the parent bus node with #address-cells and #size-cells.
> > 
> > Right.  So, I think to handle this properly we need to change the
> > structure of dtc:
> > 
> >   * Rather than applying source level overlays as we parse them, we
> >     should parse them each separately into a structure, then
> >     internally apply them
> > 
> >   * Checks would then need to be divided into those (A) that can be
> >     checked on any individual overlay fragment, and those (B) that can
> >     only be checked on a complete tree
> > 
> >   * We'd run the (A) checks before merging the overlays in dtc, and
> >     the (B) checks only after doing so.
> > 
> >   * For runtime overlays (/plugin/) we'd skip the (B) checks entirely,
> >     which would accomplish what you're aiming for here.
> > 
> > I had plans to make a restructure like this quite a while ago, but
> > I've never had the time to go ahead with it.  If you want to give it a
> > go, that would be great.
> > 
> 
> FYI.
> I'm facing a somewhat similar issue with this patch [1]
> [1] https://lore.kernel.org/all/20230923080046.5373-2-rogerq@kernel.org/
> 
> arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #address-cells value
> arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #size-cells value
> 
> To give some background:
> 
> The GPMC block has separate address spaces per chip select.
> 
>  From Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
>    ranges:
>      minItems: 1
>      description: |
>        Must be set up to reflect the memory layout with four
>        integer values for each chip-select line in use,
>        <cs-number> 0 <physical address of mapping> <size>
> 
> The ranges location in the device tree overlay is correct. The overlay is
> obviously meaningless without the base tree. It depends on the #address-cells
> and #size-cells defined in the base tree.
> 
> Your proposal to fix this is valid but is definitely not trivial to fix
> especially for someone who is not familiar with dtc internals. :P
> 
> Is there something simpler we could do to resolve this issue for overlay nodes.
> e.g. For overlay nodes we skip the "Relying on default address/size" check?

I think the overlay needs to define #address-cells/#size-cells because 
otherwise the only way we can ever validate (not just with dtc, but any 
tool) an overlay is by applying it. That of course means either you 
have to change the overlay target to the parent node or allow something 
like this to work:

#address-cells = <1>;
#size-cells = <0>;

&test {
  reg = <0x1234>;
};

In this case, the sizes aren't really used, but serve as annotations for 
the tools.

Rob

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] checks: Suppress warnings on overlay fragments
  2024-01-22 16:01                   ` Rob Herring
@ 2024-01-23 14:49                     ` Roger Quadros
  0 siblings, 0 replies; 8+ messages in thread
From: Roger Quadros @ 2024-01-23 14:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: david, Qun-wei Lin (林群崴),
	Casper Li (李中榮),
	Kuan-Ying Lee (李冠穎),
	Chinwen Chang (張錦文),
	Ivan Tseng (曾志軒),
	devicetree-compiler, Bajjuri, Praneeth



On 22/01/2024 18:01, Rob Herring wrote:
> On Tue, Jan 16, 2024 at 02:54:23PM +0200, Roger Quadros wrote:
>> Hi David & Rob,
>>
>> On 14/05/2023 09:42, david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org wrote:
>>> On Tue, Apr 18, 2023 at 12:33:26PM -0500, Rob Herring wrote:
>>>> On Thu, Apr 13, 2023 at 7:44 AM Qun-wei Lin (林群崴)
>>>> <Qun-wei.Lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>>>
>>>>> On Thu, 2023-03-09 at 09:12 -0600, Rob Herring wrote:
>>>>>> On Wed, Mar 8, 2023 at 3:17 AM Qun-Wei Lin <qun-wei.lin@mediatek.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> The overlay fragment is a special case where some properties are
>>>>>>> not
>>>>>>> present in the overlay source file, but in the base file.
>>>>>>>
>>>>>>> example:
>>>>>>> +-----------------------------+--------------------+
>>>>>>>> base.dts                    | overlay.dts        |
>>>>>>>
>>>>>>> +-----------------------------+--------------------+
>>>>>>>> /dts-v1/;                   | /dts-v1/;          |
>>>>>>>>                             | /plugin/;          |
>>>>>>>> /{                          |                    |
>>>>>>>>   parent: test {            | &parent {          |
>>>>>>>>     #address-cells = <1>;   |   child@0 {        |
>>>>>>>>     #size-cells = <0>;      |     reg = <0x0>;   |
>>>>>>>>   };                        |   };               |
>>>>>>>> };                          | };                 |
>>>>>>>
>>>>>>> +-----------------------------+--------------------+
>>>>>>>
>>>>>>> It will cause the following false alarms when compiling the overlay
>>>>>>> dts.
>>>>>>>
>>>>>>> 1. /fragment@0/__overlay__: Character '_' not recommended in node
>>>>>>> name
>>>>>>> 2. /fragment@0/__overlay__: Relying on default #address-cells value
>>>>>>> 3. /fragment@0/__overlay__: Relying on default #size-cells value
>>>>>>> 4. /fragment@0/__overlay__:reg: property has invalid length (4
>>>>>>> bytes)
>>>>>>>    (#address-cells == 2, #size-cells == 1)
>>>>>>>
>>>>>>> This workaround will fix them by skip checking for node named
>>>>>>> __overlay__.
>>>>>>>
>>>>>>> Signed-off-by: Qun-Wei Lin <qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>> V1 -> V2:
>>>>>>>  - Add is_overlay_node() helper
>>>>>>>  - Skip anything starting with "__" in
>>>>>>> check_node_name_chars_strict()
>>>>>>>
>>>>>>>  checks.c | 18 ++++++++++++++++++
>>>>>>>  1 file changed, 18 insertions(+)
>>>>>>
>>>>>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>
>>>>>> Though I do wonder if as a matter of policy on overlay structure, if
>>>>>> we should require an overlay to have the parent node with
>>>>>> #address-cells/#size-cells. In the end that would be duplicated data,
>>>>>> but without it there's no way to parse and validate reg/ranges in an
>>>>>> unapplied overlay. That's just one example issue in being able to
>>>>>> validate overlays.
>>>>>>
>>>>>> Rob
>>>>>
>>>>> Hi Rob,
>>>>>
>>>>> Thank you for your review.
>>>>>
>>>>> I think I've found another problem:
>>>>> +-------------------------+----------------+
>>>>> | base.dts                | overlay.dts    |
>>>>> +-------------------------+----------------+
>>>>> | /dts-v1/;               | /dts-v1/;      |
>>>>> | /{                      | /plugin/;      |
>>>>> |   #address-cells = <1>; |                |
>>>>> |   #size-cells = <0>;    | &test {        |
>>>>> |   test: example@0 {     |   reg = <0x1>; |
>>>>> |     reg = <0x0>;        | };             |
>>>>> |   };                    |                |
>>>>> | };                      |                |
>>>>> +-------------------------+----------------+
>>>>>
>>>>> The following error message is printed when compiling:
>>>>> Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid
>>>>> length (4 bytes) (#address-cells == 2, #size-cells == 1)
>>>>> Warning (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg
>>>>> or ranges property, but no unit name
>>>>> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
>>>>> default #address-cells value
>>>>> Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on
>>>>> default #size-cells value
>>>>>
>>>>> We can't get the #address-cells/#size-cells of the parent of the
>>>>> example node in the overlay structure.
>>>>> Do you think we should change it to is_overlay_node(node) instead of
>>>>> is_overlay_node(node->parent)?
>>>>> Or we just need to skip checking for node names starting with "__" in
>>>>> check_node_name_chars_strict()?
>>>>
>>>> I think this is the tip of the iceberg in terms of being able to
>>>> validate overlays. Turning off address checks just kicks the problem
>>>> to schema validation.  Perhaps the overlay should be structured to
>>>> include the parent bus node with #address-cells and #size-cells.
>>>
>>> Right.  So, I think to handle this properly we need to change the
>>> structure of dtc:
>>>
>>>   * Rather than applying source level overlays as we parse them, we
>>>     should parse them each separately into a structure, then
>>>     internally apply them
>>>
>>>   * Checks would then need to be divided into those (A) that can be
>>>     checked on any individual overlay fragment, and those (B) that can
>>>     only be checked on a complete tree
>>>
>>>   * We'd run the (A) checks before merging the overlays in dtc, and
>>>     the (B) checks only after doing so.
>>>
>>>   * For runtime overlays (/plugin/) we'd skip the (B) checks entirely,
>>>     which would accomplish what you're aiming for here.
>>>
>>> I had plans to make a restructure like this quite a while ago, but
>>> I've never had the time to go ahead with it.  If you want to give it a
>>> go, that would be great.
>>>
>>
>> FYI.
>> I'm facing a somewhat similar issue with this patch [1]
>> [1] https://lore.kernel.org/all/20230923080046.5373-2-rogerq@kernel.org/
>>
>> arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #address-cells value
>> arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #size-cells value
>>
>> To give some background:
>>
>> The GPMC block has separate address spaces per chip select.
>>
>>  From Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
>>    ranges:
>>      minItems: 1
>>      description: |
>>        Must be set up to reflect the memory layout with four
>>        integer values for each chip-select line in use,
>>        <cs-number> 0 <physical address of mapping> <size>
>>
>> The ranges location in the device tree overlay is correct. The overlay is
>> obviously meaningless without the base tree. It depends on the #address-cells
>> and #size-cells defined in the base tree.
>>
>> Your proposal to fix this is valid but is definitely not trivial to fix
>> especially for someone who is not familiar with dtc internals. :P
>>
>> Is there something simpler we could do to resolve this issue for overlay nodes.
>> e.g. For overlay nodes we skip the "Relying on default address/size" check?
> 
> I think the overlay needs to define #address-cells/#size-cells because 
> otherwise the only way we can ever validate (not just with dtc, but any 
> tool) an overlay is by applying it. That of course means either you 
> have to change the overlay target to the parent node or allow something 
> like this to work:
> 
> #address-cells = <1>;
> #size-cells = <0>;
> 
> &test {
>   reg = <0x1234>;
> };
> 
> In this case, the sizes aren't really used, but serve as annotations for 
> the tools.

But one address/size-cells might not fit all cases in an overlay as the
nodes in the overlay may have parents with different address/size-cells.

-- 
cheers,
-roger

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-01-23 14:49 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-08  9:15 [PATCH v2] checks: Suppress warnings on overlay fragments Qun-Wei Lin
     [not found] ` <20230308091539.11178-1-qun-wei.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2023-03-09 15:12   ` Rob Herring
     [not found]     ` <CAL_JsqKTM=gaQGZhrBCRkBusYYMci0mJGAFf9RTvCx00G2OJzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-04-13 12:43       ` Qun-wei Lin (林群崴)
     [not found]         ` <347151917fb777e66a54e983efbbe0303f63e01a.camel-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2023-04-18 17:33           ` Rob Herring
     [not found]             ` <CAL_Jsq+L50RZ-s55tncFMHA1AwL5An13n2OVPzknnpu=uOvzhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-14  6:42               ` david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+
2024-01-16 12:54                 ` Roger Quadros
2024-01-22 16:01                   ` Rob Herring
2024-01-23 14:49                     ` Roger Quadros

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).