[Letux-kernel] X1600 upstreaming efforts

[H. Nikolaus Schaller]

Hi Paul.

> Am 21.04.2025 um 16:29 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Monday, 21 April 2025 08:24:36 CEST H. Nikolaus Schaller wrote:
>> 
>>> Am 21.04.2025 um 00:25 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> 
>>> Running the tool on the device tree produces lots of complaints! One of
>>> them will be about the phandle of the aliases node, presumably because
>>> the validator assumes that every property in an aliases node is an alias,
> 
>> IMHO the issue are not the phandles in the aliases { properties } but the
>> label/phandle of the alias node itself (see below).
> 
> What happens is that there is a phandle for the node that gets associated with 
> it when the device tree is compiled, as if the following had been written:
> 
> aliases {
>    ...
>    phandle = <27>;
> };
> 
> However, the validator assumes that the only properties it will see in an 
> aliases node are alias definitions. It does not expect a phandle definition 
> which has a different form to the alias definitions.

Ok.

> 
> So, the short-circuiting of value decoding in prop_value for the aliases node 
> causes the TypeError by relying on this assumption that is either broken by 
> the device tree or by a change in underlying library behaviour. (Below, we 
> discover that it is by the device tree.)
> 
> Later on, we see that the validator explicitly checks the aliases node and 
> complains about non-array property values, perhaps driven by the schema. Hence 
> the need to discard the phandle before the validator actually does any 
> validation.

Ok.

> 
>> Finally I removed the aiases: label and the error is gone... This confirms
>> your findings that there should be no phandle for aliases (for whatever
>> reasons).
> 
> Then it seems that "aliases: aliases" introduces the phandle.

Of course it defines a phandle so that a potential "property = <&aliases>" or
&aliases { new aliases } would work. But likely this does not make sense...

> Maybe the 
> validator should handle this eventuality even if it might be said that people 
> should not be writing this kind of thing in their device trees.

So in summary we have found a bug in the validator... Is it worth reporting?
Well, no... We have too many bugs in our lx16 code :)

Best regards and thanks,
Nikolaus

PS: I have received 3 PCBs for the LX20 (one is broken by manufacture process).
I have planned to build one board with power regulators only and two full LX20
boards... Then we will see if they emit smoke or some console log :)