The devicetree line that compiles clean and boots wrong

Your board comes up. The console prints. The I2C sensor you added last night is not there.

So you do what everyone does. You check the pull-ups. You scope SDA. You add a print to the driver's init hook and it never fires, so you go and read the driver, and about two hours later you scroll past this:

&i2c1 {
    status = "okay";

    bme280@76 {
        compatible = "bosch,bme280";
        reg = <0x76>;
        status = "ok";
    };
};

status = "ok". Two letters short, and the build never said a word.

The compiler has no opinion about it

status is a string property. dtc will compile any string you put there: "ok", "yes", "banana". The value is not the compiler's business.

It is the binding's business. The Devicetree Specification v0.4 defines exactly five values for status: okay, disabled, reserved, fail and fail-sss. Zephyr's generated headers mark a node as present only for the exact string okay. Anything else, including "ok", "enable" and the very natural-looking "enabled", is simply not okay, so the node is not enabled, the device entry is never emitted, and there is nothing on the bus to talk to.

No error. No warning. A clean build and a missing sensor.

It has four cousins

Once you start looking for this shape, a bring-up repo is full of it. Every line below compiles:

compatible = "acme-controller";  /* no comma, so it matches no binding and the driver never probes */
address-cells = <1>;             /* no leading #, so the parent supplies no address cell count */
interrupt-parent = <2>;          /* a literal where a phandle reference belongs */
phandle = <1>;                   /* hand-set, and free to collide with a generated value */
sensor@0x40005400 { };           /* a unit address written with 0x, compared as plain hex */

None of these is a syntax error. They are all spelling mistakes in a language where the spelling is the semantics, and every one of them fails somewhere far away from the line that caused it: at probe time, at link time, or on the bench with a scope in your hand.

Why your assistant writes it too

enabled is the English word for what you are trying to do, and every other config format in the same repository agrees with it:

mp.metrics.enabled=true

# TOML - correct
enabled = true

// devicetree - wrong, and it compiles
status = "enabled";

A model generating an overlay is pattern-matching against a world where enabled is right almost everywhere. Devicetree is the exception, and the exception is not visible in the output. This is the category of mistake that reads correct, reviews correct and builds correct.

The rest of the repo has the same disease

The .dts file is rarely alone. The manifest next to it:

[package]
edition = 2021           # rejected - the year is a string
version = 1.0.0          # not a number; TOML has no bare version literal
requires-python = >=3.9  # PEP 621 wants a quoted specifier

The service config next to that:

com.acme.InventoryClient/mp-rest/uri=https://inventory.svc:8443

The MicroProfile Rest Client key is /mp-rest/url. Any other spelling is not an error - it is ignored, and the client silently falls back to the value baked into the annotation. Then there is AutoHotkey v1 syntax in a v2 script, a Ren'Py label with no colon, an Inkling file still declaring inkling "1.0". All of them plain text as far as the editor is concerned.

What I ended up building

A VS Code pack with 23 of these rules and 50 snippets, covering devicetree, TOML, MicroProfile .properties, AutoHotkey v2, Ren'Py, Swift and Inkling. Ten of the 23 rules are devicetree; the rest are the files that sit around it.

Run it on the file you have open and you get line numbers and a sentence explaining what the correct spelling is and why. That part is free: all 23 rules, all 50 snippets, no key, no account, no network call and no build context. It works on a bare .overlay you pasted out of a vendor forum, which is exactly where the free devicetree extensions stop, because they want a configured Zephyr or nRF context first.

The licence changes the scale rather than the rules. It runs the same 23 rules over every file in the workspace in one pass, writes the findings into the repo as CSV, JSON or HTML so you can attach them to a review, and re-runs the check on every save instead of when you remember to look.

There is a browser version that runs the same 23 rules on text you paste, with nothing uploaded, if you want to check one file before installing anything.

Two hours of driver debugging is worth more than a config linter. That is the whole argument.