github: extend LLM review rules with three new categories

Tightened from real bot reviews:

- Patch regeneration: spell out which make ... refresh command
  to recommend for each patch directory class, so the bot stops
  suggesting git format-patch for quilt-managed patches.
- Backports / cherry-picks: a backport's diff should match the
  upstream commit on main verbatim; flag only deviations and
  the missing (cherry picked from commit <sha>) trailer, not
  pre-existing style issues.
- New device support: require Hardware specification, Flash
  instructions, and MAC address layout sections in the commit
  message that introduces a new device. Two reference commits
  (986ca4c887, a2dcbd79a4) named so the bot can sample the
  expected shape.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23184
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

.github/llm-review-rules.md

@@ -15,3 +15,75 @@ start.
 - **MAC from MTD.** `mediatek,mtd-eeprom = <&factory 0xNNNN>;` --> use
   `nvmem-cells = <&macaddr_factory_NN>;` +
   `nvmem-cell-names = "mac-address";`.
+
+## Patch regeneration
+
+OpenWrt patches are quilt-managed and **not** refreshed with
+`git format-patch`. When a patch's hunk headers, fuzz, or context
+need to be regenerated, the project-specific commands are:
+
+- `target/linux/<platform>/patches-<X.Y>/...` --> `make
+  target/linux/refresh` (with the matching target selected in
+  `.config`)
+- `target/linux/generic/backport-<X.Y>/...`,
+  `target/linux/generic/pending-<X.Y>/...`, and
+  `target/linux/generic/hack-<X.Y>/...` --> same `make
+  target/linux/refresh`. Note these live under
+  `target/linux/generic/`, not under each `<platform>/`.
+- `package/<area>/<pkg>/patches/...` --> `make
+  package/<pkg>/refresh` (e.g. `package/kernel/mac80211/patches/...`
+  --> `make package/mac80211/refresh`)
+
+If a patch's metadata is wrong, recommend the matching `make ...
+refresh` command, not `git format-patch`.
+
+## New device support — required commit-message sections
+
+A PR is adding support for a new device when it adds a new `.dts` /
+`.dtsi` file under `target/linux/<plat>/dts/` and a new
+`define Device/<vendor>_<model>` block under any `.mk` file in
+`target/linux/<plat>/image/` (the block can live in
+`<subtarget>.mk`, in a shared `common-<vendor>.mk` /
+`generic-<vendor>.mk` include, or in another `.mk` in that
+directory). The commit message introducing the device must contain
+three sections, even if short:
+
+1. **Hardware specification** — SoC, RAM (size + chip if known),
+   Flash (type + size + chip), WiFi (band + chains + chip), Ethernet
+   (port count + speed + switch chip), LEDs/Buttons (count + type),
+   UART (header location, pinout, baud rate), Power (voltage +
+   current).
+2. **Flash instructions** — at minimum one fully-described install
+   path: which image to use, how to put the device into a
+   flashable state (TFTP recovery, U-Boot menu, OEM web UI,
+   serial-console method), and a reverting-to-stock note when a
+   procedure exists. Verbatim button/IP/hostname strings, not
+   hand-wavy descriptions.
+3. **MAC address layout** — where each interface's MAC comes from
+   (factory partition + offset, board_data text, derived from
+   label, etc.), one line per interface (LAN/WAN/2.4G/5G/...).
+   Use `xx:xx:xx` for the unit-specific bytes.
+
+Reference well-formed examples (use `git show <sha>` to inspect):
+
+- `986ca4c887f4088b6fbc703faa88884350e9274f` — terse, well-structured.
+- `a2dcbd79a4460617bd42151555448f8bca8ca7be` — fuller, with LED layout
+  and notes; flash instructions cover U-Boot and OEM-dashboard paths.
+
+Flag missing or empty sections. Don't dictate exact wording — both
+references differ significantly in tone and length. The bar is
+"could a stranger flash this device from the commit message alone?".
+Don't apply this rule to backports, refactors, DTS-only fixes, or
+PRs that only add a hardware variant of an existing device (e.g.
+`DEVICE_ALT0_*` only) — the original commit already carries the
+spec.
+
+## Backports / cherry-picks
+
+PRs targeting `openwrt-NN.NN` branches or titled `[X.Y] ...` are
+backports. Their diffs should match the upstream commit on `main`
+verbatim. Code-style or design issues that already exist on the
+upstream commit belong on a fix-to-main PR, not on the backport —
+flag only deviations introduced by the cherry-pick itself, plus
+the missing `(cherry picked from commit <sha>)` trailer.
+`git cherry-pick -x` adds the trailer automatically.