doc: Update docs/blog post to reference ZMK variants

* Update Zephyr 4.1 blog post to mention ZMK variants
* Add note to hardware support page about variants

Author: petejohanson

docs/blog/2025-12-09-zephyr-4-1.md

@@ -61,6 +61,12 @@ The following steps will get you building ZMK locally against Zephyr 4.1:
 
 From there, you should be ready to build as normal!
 
+## ZMK Board Variant
+
+The new Zephyr version includes a [standard mechanism for extending boards](https://docs.zephyrproject.org/4.1.0/hardware/porting/board_porting.html#board-extensions) found in Zephyr (like the Seeeduino XIAO, or Raspberry Pi Pico) with new variants that include additional configuration/defaults that are relevant to the application. This also means the original "stock" board can still be used as is, if consumers don't want to use those customizations for any reason.
+
+As a result, all board definitions found in the ZMK tree now must be used with a `zmk` variant. For example, the previous board ID of `adv360pro_left` would now be `adv360pro_left/nrf52840/zmk`, which can be elided to `adv360pro_left//zmk` since there's only one SoC on the board.
+
 ## Board Revisions
 
 As part of this change, ZMK is now using board/shield revisions, rather than duplicate board/shield definitions. This means that instead of having e.g. `nice_nano`, and `nice_nano_v2`, we only have `nice_nano`, which by default points to the `2.0.0` revision. To point to the original Nice!Nano V1, you would need to use `[email protected]` where you would have previously used `nice_nano`. Of course, you could also put `[email protected]` if you wished to make that explicit, instead of merely replacing `nice_nano_v2` with `nice_nano`. Some boards, such as the `nrfmicro`, also have additional _board qualifiers_ such as the choice between multiple SoCs. Board qualifiers must always be specified, and do not have defaults. See [Zephyr's overview](https://docs.zephyrproject.org/4.1.0/hardware/porting/board_porting.html#board-terminology) for more information on board qualifiers. The below table provides an overview of some of the differences in in-tree boards we have in ZMK, and how they are selected in the new build system. The shorthand shows the minimum needed to build with a specific board, taking into account defaults.
@@ -429,5 +435,13 @@ Once a ZMK version based on Zephyr 4.1 is released, we'll be working towards upd
 - Removing ZMK's use of the deprecated, and now removed, `kscan` APIs in favor of the newer matrix input API. ZMK already supports the matrix input API, but has not yet converted our existing drivers to that API. Advanced users looking to test can try leveraging the upstream Zephyr drivers today to test that functionality, but that is _not_ officially supported and is likely to have bugs or untested side effects.
 - Move the new USB stack, that includes better High-Speed USB support.
 
+:::note
+
+The following changes have been made since this blog post was originally published:
+
+- The [move to `zmk` variants by default]()https://github.com/zmkfirmware/zmk/pull/3145 for ZMK boards was documented.
+
+:::
+
 [nmunnich]: https://github.com/nmunnich
 [petejohanson]: https://github.com/petejohanson

docs/docs/hardware.mdx

@@ -44,6 +44,12 @@ With the solid technical foundation of Zephyr™ RTOS, ZMK can support a wide di
 including but not limited to Nordic nRF52, Raspberry Pi RP2040/RP2350, most ST STM32 MCUs, and Microchip SAMD21.
 That being said, there are specific [boards / shields](development/hardware-integration/index.mdx#boards--shields) that have been implemented and tested by the ZMK contributors, listed below.
 
+:::note
+
+With the [upgrade to Zephyr 4.1](/blog/2025/12/09/zephyr-4-1#zmk-board-variant), the ZMK project has moved all in-tree boards to use a `zmk` [board variant](https://docs.zephyrproject.org/4.1.0/glossary.html#term-variant), for consistency when distinguishing from stock boards that are actually in upstream Zephyr.
+
+:::
+
 <HardwareList items={Metadata} />
 
 {/* prettier-ignore */}