Ga Hing Woo

Been doing some RK3588 board porting and kept running into the same category of bug — dtc compiles clean, dtbs_check passes, but the board either panics on suspend or a peripheral silently fails to probe.
Stuff like:
Peripheral on the EE supply wired to something that only stays alive in the AO domain → suspend-resume panic
Copy-pasted a GPIO bank with 32 pins, used pin 35 → kernel panic at driver probe
SPI clock request exceeds PLL maximum → silent bus hang
Two nodes sharing the same GIC SPI interrupt line
None of these are schema violations — they require knowing the actual cross-domain constraints of the SoC, which dtc has no idea about.
 
So I wrote a Python tool that builds an in-memory model of the power tree, clock tree, and pin assignments, then runs constraint rules against it:
$ pip install soc-consistency $ socc check board.dts --soc rk3588 error[PD-001] Power domain crossing — i2c@fe2b0000 uses vcc_3v3 (EE domain) but is connected to vcc_1v8 (AO domain). Will panic on suspend. error[GP-003] GPIO index out of bounds — gpio1 pin 35 on a 32-pin bank. warn[CK-003] Clock rate mismatch — spi0 requests 50 MHz from pll_cpll (max 24 MHz).  
There's also a decompile command that runs dtc on a binary blob and annotates the output with peripheral names from the SoC database — useful when you're staring at a vendor DTB and have no idea which block is at which address:
$ socc decompile vendor.dtb --soc rk3588 gpio0@fd8a0000 /* GPIO0 (32-pin, 3.3V) */ { cru@fd7c0000 /* CRU — Clock and Reset Unit */ {  
RK3588 has the most complete constraint coverage right now. The constraint format is a simple YAML file — happy to accept PRs for other SoCs.
GitHub: https://github.com/gahingwoo/SoC-Consistency
Docs/rules reference: in the README
If you hit false positives on a real BSP DTS, open an issue — BSP files from vendors tend to have a lot of "intentional" violations that I'm still tuning the rules around.