devicetree: format files in boards #92805

kylebonnici · 2025-07-07T20:50:47Z

Diff for boards folder as per discussion in #92334

JarmouniA · 2025-07-07T22:10:11Z

Can you split this into a commit for each vendor, otherwise it takes ages to load.

mathieuchopstm

(non-blocking remarks up to ST boards)

mathieuchopstm · 2025-07-09T15:33:14Z

boards/adafruit/feather_esp32s3_tft/adafruit_feather_esp32s3_tft_procpu.dts

+		spi-one-frame = <0xf0>;	/* 625 ns high and 625 ns low */
+		spi-zero-frame = <0xc0>;	/* 312.5 ns high and 937.5 ns low */


IMO both comments should remain aligned.

not sure why this was marked as resolved - maybe it was fixed at some point but currently it's off. Not sure if you're just systematically adding one tab character before the comment, but it's not as simple a that and you should either just make it a simple whitespace and not care about trying to have comments from different lines be flush, or you need something like what we have in the new-ish feature that augments build/zephyr/zephyr.dts with useful comments
afdb62d

Or maybe just don't do anything with comments beside basic whitespace sanitization (i.e clean up any bad mixup of whitespaces and tabs), and stop there?

/* node '/cpus' defined in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:22 */ cpus { #address-cells = < 0x1 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:23 */ #size-cells = < 0x0 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:24 */ /* node '/cpus/cpu@0' defined in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:26 */ cpuapp: cpu: cpu@0 { compatible = "arm,cortex-m33f"; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:27 */ reg = < 0x0 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:28 */ device_type = "cpu"; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:29 */ clocks = < &hfpll >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:30 */ #address-cells = < 0x1 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:31 */ #size-cells = < 0x1 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:32 */ /* node '/cpus/cpu@0/itm@e0000000' defined in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:34 */ itm: itm@e0000000 { compatible = "arm,armv8m-itm"; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:35 */ reg = < 0xe0000000 0x1000 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:36 */ swo-ref-frequency = < 0x7a12000 >; /* in zephyr/dts/vendor/nordic/nrf54l_05_10_15.dtsi:37 */ }; }; };

I had marked it as resolved as it is the same many another's.there was one where I asked what I should do with comments i tagged you in that thread ... apologies if marking as resolved was not the right thing to do. If can you reply where I tagged you it would help me follow what to do next.

I am open to any change I just need to know which ones to do

I think going with a single whitespace is better than adding a hard tab in the middle of the line.
While aligning comments is nice, the proposal of using a hard tab doesn't always achieve alignment, so keep it simple by just requiring a single space before comment.

I have rebased and changed the rule to as space as per the above suggestions.

boards/adafruit/feather_esp32s3_tft_reverse/adafruit_feather_esp32s3_tft_reverse_procpu.dts

boards/adafruit/qt_py_esp32s3/adafruit_qt_py_esp32s3_procpu.dts

boards/ambiq/apollo510_evb/apollo510_evb-pinctrl.dtsi

boards/amd/versal2_rpu/versal2_rpu-qemu.dts

boards/shields/arduino_uno_click/arduino_uno_click.overlay

boards/shields/x_nucleo_eeprma2/x_nucleo_eeprma2.overlay

mathieuchopstm

Two blockers on ST boards + one nit.

boards/st/nucleo_wb05kz/nucleo_wb05kz.dts

boards/st/nucleo_wb09ke/nucleo_wb09ke.dts

boards/st/nucleo_wb07cc/arduino_r3_connector.dtsi

kylebonnici · 2025-07-10T08:21:19Z

I have seen the feedback and aligning comment over different lines is not trivial and IMO not practical.

Currently the formatter will make sure that there is a tab between the comment first token and prev token when prev token is on the same line. If prev token is not on the same line than comment is will be aligned the same way the value would be

node{
	prop = <10
	       /* align as if it is a value like 1o and 20 */
	       20
	       >,
	       /* align as if it as a value like <10 20> */
	       <10 20>;
}

Keep in mine user can have multiple values on same line like <10 20> and also <10 20>, <10 20>

hence consider the below:

node{
	prop = <10 20 30	/* foo */
	        /* align as if it is a value like 1o and 20 */
	        40	/* bar */  50 	/* foo */
	       >,
	       /* align as if it as a value like <10 20> */
	       <10 20>,	/* foo */  <20 30>, 	/* bar */;
}

Not to mention what if comment is before the value like

node{
	prop = <10
	        /* align as if it is a value like 1o and 20 */
	        /* foo */ 20
	       >,
	       /* align as if it as a value like <10 20> */
	       <10 20>;
}

If we are to consider the suggested changes by @mathieuchopstm I will need contribution in the form of concrete rules on what to for every use case possible.

pillo79

Love this effort and the linter work, really appreciated, thanks! 👍 🙇
Minor questions/feedback on the new formatting on the Arduino DTS files.

boards/arduino/giga_r1/arduino_giga_r1_stm32h747xx_m7.dts

pillo79 · 2025-07-10T09:41:34Z

boards/arduino/opta/arduino_opta_stm32h747xx_m7.dts

 	pinctrl-0 = <
-		&eth_ref_clk_pa1
-		&eth_crs_dv_pa7
-		&eth_rxd0_pc4
-		&eth_rxd1_pc5
-		&eth_tx_en_pg11
-		&eth_txd1_pg12
-		&eth_txd0_pg13
-	>;
+		     &eth_ref_clk_pa1


Would it be possible to detect this situation and enforce that the first entry be included with the opening <, or is there some other place where this formatting kind is really needed?

They are useless AFAICS: devicetree_generated.h is unchanged with or without them.
Not sure the linter can complain about those, however, since there may be other situations where they are actually useful.

The linter so far formats the document if it has no syntax errors and if it has syntax errors it will not format but rather report the syntax issues.

The item you mentioned is a diagnostic rule and I can certainly add this to the dts-lsp. FYI I am not an embedded or zephyr developer so more information and explanation on why

zephyr,memory-attr = <(DT_MEM_ARM(ATTR_MPU_RAM))>;

is not needed and how you reached this conclusion it will help me a lot.

With respect to the linter also doing diagnostic check, This is in my plan but for now I want the first baby step in once the linter is in we can expand and enable more. Also diagnostic can be a bit slower as it needs to parse not only the DTS files but also all the headers

Would it be possible to detect this situation and enforce that the first entry be included with the opening <, or is there some other place where this formatting kind is really needed?

So if I understand correctly you want the first values to be next to the < and I guess the last to be next to >;?
would you also want to extend this to byte string i.e [ and I guess the last to be next to ];?

With regards to changing the rule I have no issue as long as other Zephyr maintainer all agree this is the way to go!

FYI I am not an embedded or zephyr developer so more information and explanation on why

zephyr,memory-attr = <(DT_MEM_ARM(ATTR_MPU_RAM))>;

is not needed and how you reached this conclusion it will help me a lot.

DT_MEM_ARM is defined as:

zephyr/include/zephyr/dt-bindings/memory-attr/memory-attr-arm.h

Line 24 in 7a8bd3d

#define DT_MEM_ARM(x) ((x) << DT_MEM_ARCH_ATTR_SHIFT)

i.e. DT_MEM_ARM(ATTR_MPU_RAM) expands to ((ATTR_MPU_RAM) << DT_MEM_ARCH_ATTR_SHIFT) - the whole expression is already within parenthesis, so the ones around the macro invocation itself are redundant.

Additionally, per the Linux kernel coding style guidelines which Zephyr follows:

macros defining constants using expressions must enclose the expression in parentheses. Beware of similar issues with macros using parameters.

#define CONSTANT 0x4000 #define CONSTEXP (CONSTANT | 3)

So any expression resulting only from a macro expansion ought to already be wrapped in parentheses. (things like AAA | BBB need to be wrapped manually, but that's a given)

(As secondary remark, outside formatting considerations: this pattern should be replaced by zephyr,memory-attr = <DT_MEM_ARM_MPU_RAM>; instead)

Would it be possible to detect this situation and enforce that the first entry be included with the opening <, or is there some other place where this formatting kind is really needed?

So if I understand correctly you want the first values to be next to the < and I guess the last to be next to >;? would you also want to extend this to byte string i.e [ and I guess the last to be next to ];?

With regards to changing the rule I have no issue as long as other Zephyr maintainer all agree this is the way to go!

I'm out of the loop so my question may be silly, but where do the formatting rules used in this PR come from in the first place? I wasn't even aware that DTS files could be formatted by a tool (reading your comment, and vaguely remembering there was a tech talk about DTS-lsp, I'm assuming this is something new and recent, but I may be wrong?)

So if I understand because the macro resolved with (...) then we do not need it in the prop = <()>. this can be a new feature in the LPS in the quick actions.

I can already evaluate all the macros But For LSP to do analysts on the outcome of the macro I need to parse the .h files and for the formatting stage this is not being done for performance reasons. Keep in mind that in overlays and dtsi files the macros available at compile/preprocessing time will change on the main board file and the order of the includes so to do this and format a dtsi/overlay file the main board dts files will be a requirement. I am not sure we want to this in the formatting check.

sorry I lost track of things a bit, what's the proposal here?

TL;DR linter should treat ANYTHING and ANYTHING(...) as "something already in parentheses after expansion" and warn patterns such as prop = <(MACRO(x))>;

so if it finds anything like <SOMETHING (-10)> or <SOMETHING(-10)> it won't try to change it, right?

Will do change and do commit separately so we can see the diff

@fabiobaltieri @mathieuchopstm see last commit for changes with respect to the above.

boards/variscite/imx8mp_var_dart/imx8mp_var_dart_mimx8ml8_a53.dts

keith-zephyr · 2025-07-14T19:10:05Z

I created PR #93123 to explicitly make the bracket usage part of the Zephyr devicetree style guide.

boards/arduino/portenta_h7/arduino_portenta_h7-common.dtsi

mathieuchopstm · 2025-07-22T09:47:25Z

boards/arduino/portenta_h7/arduino_portenta_h7-common.dtsi

+		     &fmc_a2_pf2 &fmc_a3_pf3 &fmc_a4_pf4 &fmc_a5_pf5
+		     &fmc_sdnras_pf11 &fmc_a6_pf12 &fmc_a7_pf13 &fmc_a8_pf14
+		     &fmc_a9_pf15 &fmc_a10_pg0 &fmc_a11_pg1 &fmc_a12_pg2
+		     &fmc_a14_pg4	/* FMC_BA0 */ &fmc_a15_pg5	/* FMC_BA1 */


Maybe the comments could be moved on top of the property to solve the issue here:

/* fmc_a14_pg4 is FMC_BA0 and fmc_a15_pg5 is FMC_BA1 */

mathieuchopstm · 2025-07-22T09:52:39Z

I would like to dismiss my -1 since current proposal is OK for me, but GitHub is very helpfully hiding where I would usually do it because of merge conflicts...

If someone knows another way, please let me know 🙂 - in any case, feel free to dismiss it later if I forget to.

Dismissed as per reviewers's request

kylebonnici · 2025-07-22T18:35:17Z

After looking at other tools formatting after the /* and after the * and before */ is not normal done as this will hinder comments like the below

I will revert the changes and remove the NIT pick request to

- /* Not a GPIO*/
+ /* Not a GPIO */

FYI @mathieuchopstm

pillo79 · 2025-07-23T07:46:45Z

boards/nxp/frdm_k32l2b3/frdm_k32l2b3-pinctrl.dtsi

 			pinmux =
-				<LPUART0_RX_PTA1>,
-				<LPUART0_TX_PTA2>;
+				 <LPUART0_RX_PTA1>,
+				 <LPUART0_TX_PTA2>;


Do we allow this wrap after =? It's really rare and gains nothing in terms of indentation; the style guide also says "use a single space on both sides of = in property definitions", which may be interpreted as disallowing this form.
IMO this should be joined with previous line, like the opening brace scenario.

Push commit to address this feedback + rebased on main again

boards/adafruit/qt_py_rp2040/seeed_xiao_connector.dtsi

fabiobaltieri · 2025-07-23T08:43:28Z

boards/adi/sdp_k1/adi_sdp_120pin_connector.dtsi

-	cs-gpios = <&sdp_k1_120_hdr SDP_120_SPI_SEL_A_N (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+	cs-gpios = <&sdp_k1_120_hdr SDP_120_SPI_SEL_A_N(GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;


this has the same issue that has been discussed in the other thread, the speace is meaningful, this is a tuple with three fields not a macro with argument

Will check tonight

fabiobaltieri · 2025-07-23T08:55:29Z

Lot of good fixes in this, feeling like a good fraction of these or more could be merged and moved off the way right now so we have less delta to work with, tempted to do some cherry-pick and squash here, what do other folks think?

mathieuchopstm · 2025-07-23T15:10:24Z

Opened #93603 for the STM32WB0 boards that caused a fuss.

kylebonnici · 2025-07-23T18:25:13Z

@fabiobaltieri I have started over from main and applied the linter. Split commits by vendor + changed formatting to allow {} from { }

Hope this helps

kylebonnici · 2025-08-01T21:46:18Z

@keith-zephyr @fabiobaltieri @kartben I have rebase one more time and now the changes we discus are all included in the individual commit per vendor i.e.

...<(MACRO)>.. -> ...<MACRO>..

and

Space before each comment instead of tab when not first token on line

I guess @fabiobaltieri we should not stop making changes and stated getting some of these changes In?

kylebonnici · 2025-08-09T17:07:21Z

Is there any action I can take to start getting this in?

Applying dts-linter results for format files in boards/seeed Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/segger Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/sensry Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/shields Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/sifive Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/silabs Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/sipeed Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/snps Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/sparkfun Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/st Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/tdk Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/technexion Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/telink Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/ti Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/toradex Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/u-blox Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/udoo Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/variscite Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/vngiotlab Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/waveshare Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/we Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/weact Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/wemos Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/witte Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Applying dts-linter results for format files in boards/wiznet Signed-off-by: Kyle Micallef Bonnici <[email protected]>

Fix files that needed line splitting to be less then 100 with Fix files that needed to use node referance to force propes to fit in 100 width Signed-off-by: Kyle Micallef Bonnici <[email protected]>

sonarqubecloud · 2025-09-02T00:09:18Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

nandojve · 2025-09-02T05:59:31Z

boards/atmel/sam/sam4e_xpro/sam4e_xpro.dts

-				<15 0 &pioa 14 0>;	/* SPI(SCK)    EXTx */
-							/* GND              */
-							/* +3.3V            */
+		gpio-map = <0 0 &piob 2 0>,	/* AFE AD0          */


The comments still not correct. Align the 3 boards and disable formatting for these files.

These will have to be fixed manually.

linter did not touch the comment as we agreed, it fixed issues on same line comment is on which in turn made comment move.

As per my previous comment linter will not touch comments with respect to the previous token unless the comments first token is the first in that line!. Hence it will also not attempt to realign!

To avoid this then linter will not be allowed to touch lines with comments! which will defeat the purpose! of this automated process!

We also need to be reasonable as we are fixing a lot of pat mistakes in formatting, Once formatting is in place users will start off with a formatted file and the alignment they chose for there comments will be preserved.

Please note this is an automated process. Instead of asking each contributor with files with bad formatting to fix manually, the tool is automatically fixing these... if some extra work remains this can IMO be done by each vendor after formation is in place!

The comments still not correct. Align the 3 boards and disable formatting for these files.

@nandojve please provide me lists (in addition to boards/atmel/sam/sam4e_xpro/sam4e_xpro.dts)
of file you want me to skip formatting on!

kylebonnici force-pushed the dtc/formating-boards branch 2 times, most recently from 0d7d462 to 99d1999 Compare July 8, 2025 10:21

mathieuchopstm reviewed Jul 9, 2025

View reviewed changes

mathieuchopstm previously requested changes Jul 9, 2025

View reviewed changes

boards/st/nucleo_wb05kz/nucleo_wb05kz.dts Outdated Show resolved Hide resolved

boards/st/nucleo_wb09ke/nucleo_wb09ke.dts Outdated Show resolved Hide resolved

boards/st/nucleo_wb07cc/arduino_r3_connector.dtsi Show resolved Hide resolved

mathieuchopstm added area: Boards area: Shields Shields (add-on boards) labels Jul 9, 2025

pillo79 reviewed Jul 10, 2025

View reviewed changes

fabiobaltieri reviewed Jul 11, 2025

View reviewed changes

boards/variscite/imx8mp_var_dart/imx8mp_var_dart_mimx8ml8_a53.dts Outdated Show resolved Hide resolved

kylebonnici force-pushed the dtc/formating-boards branch from e58046c to f0d9999 Compare July 13, 2025 17:38

kylebonnici force-pushed the dtc/formating-boards branch from 8a6b08f to 1817796 Compare July 21, 2025 22:53

kylebonnici requested a review from mathieuchopstm July 21, 2025 22:58

mathieuchopstm reviewed Jul 22, 2025

View reviewed changes

kylebonnici force-pushed the dtc/formating-boards branch from f6c062b to 61cb0d3 Compare July 22, 2025 18:57

pillo79 reviewed Jul 23, 2025

View reviewed changes

kylebonnici force-pushed the dtc/formating-boards branch from bb664f4 to 2906c3f Compare July 23, 2025 08:05

fabiobaltieri reviewed Jul 23, 2025

View reviewed changes

boards/adafruit/qt_py_rp2040/seeed_xiao_connector.dtsi Outdated Show resolved Hide resolved

fabiobaltieri reviewed Jul 23, 2025

View reviewed changes

kylebonnici force-pushed the dtc/formating-boards branch from 2906c3f to d86b293 Compare July 23, 2025 18:22

kylebonnici force-pushed the dtc/formating-boards branch from 0286cda to ac97e81 Compare August 1, 2025 21:41

kylebonnici added 25 commits September 1, 2025 16:50

devicetree: format files in boards/seeed

47a0ff7

Applying dts-linter results for format files in boards/seeed Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/segger

fa08674

Applying dts-linter results for format files in boards/segger Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/sensry

ba2d190

Applying dts-linter results for format files in boards/sensry Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/shields

722dc18

Applying dts-linter results for format files in boards/shields Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/sifive

bfd2255

Applying dts-linter results for format files in boards/sifive Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/silabs

7ee30eb

Applying dts-linter results for format files in boards/silabs Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/sipeed

dedf988

Applying dts-linter results for format files in boards/sipeed Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/snps

035d817

Applying dts-linter results for format files in boards/snps Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/sparkfun

0622a2f

Applying dts-linter results for format files in boards/sparkfun Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/st

1b1382a

Applying dts-linter results for format files in boards/st Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/tdk

2c5fdb4

Applying dts-linter results for format files in boards/tdk Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/technexion

55df820

Applying dts-linter results for format files in boards/technexion Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/telink

e24b79a

Applying dts-linter results for format files in boards/telink Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/ti

8532b25

Applying dts-linter results for format files in boards/ti Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/toradex

dea6196

Applying dts-linter results for format files in boards/toradex Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/u-blox

de875d6

Applying dts-linter results for format files in boards/u-blox Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/udoo

5148e91

Applying dts-linter results for format files in boards/udoo Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/variscite

10718d1

Applying dts-linter results for format files in boards/variscite Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/vngiotlab

2db0bf2

Applying dts-linter results for format files in boards/vngiotlab Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/waveshare

207c9fd

Applying dts-linter results for format files in boards/waveshare Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/we

247d3d9

Applying dts-linter results for format files in boards/we Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/weact

11474f0

Applying dts-linter results for format files in boards/weact Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/wemos

c8a3970

Applying dts-linter results for format files in boards/wemos Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/witte

5a9cf3f

Applying dts-linter results for format files in boards/witte Signed-off-by: Kyle Micallef Bonnici <[email protected]>

devicetree: format files in boards/wiznet

0095e30

Applying dts-linter results for format files in boards/wiznet Signed-off-by: Kyle Micallef Bonnici <[email protected]>

kylebonnici force-pushed the dtc/formating-boards branch from 070b3d5 to 0095e30 Compare September 1, 2025 14:50

Formatting: Fix long lines Manually

45ee0ef

Fix files that needed line splitting to be less then 100 with Fix files that needed to use node referance to force propes to fit in 100 width Signed-off-by: Kyle Micallef Bonnici <[email protected]>

kylebonnici force-pushed the dtc/formating-boards branch from 3673237 to 45ee0ef Compare September 1, 2025 23:43

nandojve requested changes Sep 2, 2025

View reviewed changes

		spi-one-frame = <0xf0>; /* 625 ns high and 625 ns low */
		spi-zero-frame = <0xc0>; /* 312.5 ns high and 937.5 ns low */

		cs-gpios = <&sdp_k1_120_hdr SDP_120_SPI_SEL_A_N (GPIO_ACTIVE_LOW \| GPIO_PULL_UP)>;
		cs-gpios = <&sdp_k1_120_hdr SDP_120_SPI_SEL_A_N(GPIO_ACTIVE_LOW \| GPIO_PULL_UP)>;

devicetree: format files in boards #92805

Are you sure you want to change the base?

devicetree: format files in boards #92805

Conversation

kylebonnici commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JarmouniA commented Jul 7, 2025

Uh oh!

mathieuchopstm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kartben Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kylebonnici Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mathieuchopstm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kylebonnici commented Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pillo79 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mathieuchopstm Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kylebonnici Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

keith-zephyr commented Jul 14, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mathieuchopstm commented Jul 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

kylebonnici commented Jul 7, 2025 •

edited

Loading

kartben Jul 23, 2025 •

edited

Loading

kylebonnici Jul 23, 2025 •

edited

Loading

kylebonnici commented Jul 10, 2025 •

edited

Loading

mathieuchopstm Jul 10, 2025 •

edited

Loading

kylebonnici Jul 10, 2025 •

edited

Loading

mathieuchopstm commented Jul 22, 2025 •

edited

Loading

kylebonnici commented Jul 22, 2025 •

edited

Loading

kylebonnici commented Jul 23, 2025 •

edited

Loading

kylebonnici Sep 2, 2025 •

edited

Loading