[RFC PATCH 18/77] dtc-parser.y: Avoid an empty proplist

Herve Codina posted 77 patches 3 weeks, 5 days ago
[RFC PATCH 18/77] dtc-parser.y: Avoid an empty proplist
Posted by Herve Codina 3 weeks, 5 days ago
In the dts parser grammar, a nodedef is defined by
  '{' proplist subnodes '}' ';'
with both proplist and subnodes that can be empty lists.

Soon a new list will be added in the nodedef related to export symbol
list.

Having all those lists with support for empty lists will lead to some
Bison warnings:
  warning: 4 shift/reduce conflicts [-Wconflicts-sr]
  warning: 1 reduce/reduce conflict [-Wconflicts-rr]

The simpler way to remove those warning and thus have a robust parsing
is to avoid those empty lists.

Update the proplist definition and nodedef definition to avoid those
multiple empty lists. Instead of allowing a proplist to be an empty
list, force the list to be a non empty one and update the nodedef to
handle explicitly the absence of the proplist to support the case where
no properties are available, i.e. the case of a node composed only of
sub-nodes.

This doesn't change the functional behavior.

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
 dtc-parser.y | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/dtc-parser.y b/dtc-parser.y
index d8914d2..2e152b0 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -272,12 +272,16 @@ nodedef:
 		{
 			$$ = build_node($2, $3, &@$);
 		}
+	| '{' subnodes '}' ';'
+		{
+			$$ = build_node(NULL, $2, &@$);
+		}
 	;
 
 proplist:
-	  /* empty */
+	  propdef
 		{
-			$$ = NULL;
+			$$ = chain_property($1, NULL);
 		}
 	| proplist propdef
 		{
-- 
2.52.0
Re: [RFC PATCH 18/77] dtc-parser.y: Avoid an empty proplist
Posted by David Gibson 3 weeks, 3 days ago
On Mon, Jan 12, 2026 at 03:19:08PM +0100, Herve Codina wrote:
> In the dts parser grammar, a nodedef is defined by
>   '{' proplist subnodes '}' ';'
> with both proplist and subnodes that can be empty lists.
> 
> Soon a new list will be added in the nodedef related to export symbol
> list.
> 
> Having all those lists with support for empty lists will lead to some
> Bison warnings:
>   warning: 4 shift/reduce conflicts [-Wconflicts-sr]
>   warning: 1 reduce/reduce conflict [-Wconflicts-rr]
> 
> The simpler way to remove those warning and thus have a robust parsing
> is to avoid those empty lists.
> 
> Update the proplist definition and nodedef definition to avoid those
> multiple empty lists. Instead of allowing a proplist to be an empty
> list, force the list to be a non empty one and update the nodedef to
> handle explicitly the absence of the proplist to support the case where
> no properties are available, i.e. the case of a node composed only of
> sub-nodes.
> 
> This doesn't change the functional behavior.
> 
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>

I think it makes sense to apply this on its own before the rest of the
series, but the commit message will want rewording for that context.

> ---
>  dtc-parser.y | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/dtc-parser.y b/dtc-parser.y
> index d8914d2..2e152b0 100644
> --- a/dtc-parser.y
> +++ b/dtc-parser.y
> @@ -272,12 +272,16 @@ nodedef:
>  		{
>  			$$ = build_node($2, $3, &@$);
>  		}
> +	| '{' subnodes '}' ';'
> +		{
> +			$$ = build_node(NULL, $2, &@$);
> +		}
>  	;
>  
>  proplist:
> -	  /* empty */
> +	  propdef
>  		{
> -			$$ = NULL;
> +			$$ = chain_property($1, NULL);
>  		}
>  	| proplist propdef
>  		{
> -- 
> 2.52.0
> 
> 

-- 
David Gibson (he or they)	| 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
Re: [RFC PATCH 18/77] dtc-parser.y: Avoid an empty proplist
Posted by Herve Codina 3 weeks, 1 day ago
Hi David,

On Thu, 15 Jan 2026 12:34:19 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

...

> 
> I think it makes sense to apply this on its own before the rest of the
> series, but the commit message will want rewording for that context.
> 

I will do this rewording and I will move the patch at the begining of the
series in the next iteration.

Best regards,
Hervé