[PATCH] Coding Style: Format arch/arm/boot/dts/xilinx

[kylebonnici]

Hi,

On 1/7/26 08:49, Michal wrote:
> 
> 
> Hi,
> 
> On 1/6/26 21:28, kylebonnici wrote:
> 
> > Hi,
> 
> 
> first of all please don't do top posting.

Noted 

> 
> > Thanks for the feedback.
> > 
> > with regard to subject I am not sure in what subsystem file formatting would go (especially if we run it on even more files and more systems are modified) Your guidance would be appreciated.
> 
> 
> arm: xilinx:
> 
> or for 64 bit version
> 
> arm64: xilinx:

At this point how does one go about changing subject ? by creating a new patch or is there some other process?

> 
> > With regard to improving the line wrapping, can you share some examples so that I can start looking on improving this?
> 
> 
> 
> run it over zynqmp.dtsi file
> And focus on pcie node
> 
> @@ -958,8 +979,10 @@ pcie: pcie at fd0e0000 {
> <0x0 0xfd480000 0x0 0x1000>,
> 
> <0x80 0x00000000 0x0 0x10000000>;
> 
> reg-names = "breg", "pcireg", "cfg";
> - ranges = <0x02000000 0x00000000 0xe0000000 0x00000000
> 0xe0000000 0x00000000 0x10000000>,/* non-prefetchable memory */
> 
> - <0x43000000 0x00000006 0x00000000 0x00000006
> 0x00000000 0x00000002 0x00000000>;/* prefetchable memory */
> 
> + ranges = <0x02000000 0x00000000 0xe0000000 0x00000000
> 0xe0000000 0x00000000
> + 0x10000000>,/* non-prefetchable memory */
> 
> + <0x43000000 0x00000006 0x00000000 0x00000006
> 0x00000000 0x00000002
> + 0x00000000>;/* prefetchable memory */
> 
> bus-range = <0x00 0xff>;
> 
> 
> 1. sometimes commens are using space,tab or nothing. Same style would be useful.

Comments are currently untouched when the comment first token is not the first token on the line. 

This is because some users wanted comments to align within a property values e.g. `foo = <...> /* ...*/\n,<...>; /* ...*/`and some wanted to also align comments across multiple properties in the same node. Hence no rule on how this should be formatted was reached when this tool was applied to format the  Zephyr project. 

I am open to discuss some rule that can be followed and looking applying that.

> 2. last cell on next line looks weird to me. I think you can decode
> address-cells/size-cells for ranges and do indentation base on it.

This is not necessarily always possible with out parsing the full context i.e all the includes from the root of this context.

Reasons: 
- This values found in this node in this file might be overridden by some later definition.

- The omission of these values can mean a value of 2 and 1 respectively or again these may have been defined in some other instance in the full dts context.

Currently the rule to wrap is a follows: 
  - Wrap Value (e.g ...., <0xf00 (0xc - 0xb) 0xaa>) > if value length + indentation exceeds the wrap column
  - Wrap Expression (e.g. ...(0xc - 0xb) 0xaa>, Note that expression are wrapped outside in when we have nested expressions and nested expression will be indented to be aligned with the parent expression group > if value length + indentation exceeds the wrap column,
  - Warp Value e.g ....0xaa>
> 
> > To run on more files I will wait for feedback from Rob, Krzysztof and Conor.
> 
> 
> yep.
> 
> Thanks,
> Michal