diff --git a/README.md b/README.md
index 5de31b6..ec78d9a 100644
--- a/README.md
+++ b/README.md
@@ -89,10 +89,9 @@ print(t["lf"]["125kHz_V"], t["lf"]["134kHz_V"], t["lf"]["peak_freq_kHz"])
 print(t["hf"]["13.56MHz_V"])
 ```
 
-> ⚠️ **`hw.led` needs firmware with `CMD_LED_CONTROL`** (our LED port — currently a
-> pending follow-up). On stock/current firmware `0x011A` is `CMD_SET_HF_FIELD_TIMEOUT`,
-> so `hw.led` is presently a no-op. The API below is what it will drive once that
-> firmware lands.
+> **`hw.led` needs our firmware fork** (`CMD_LED_CONTROL` @ `0x011B`). It is not in
+> stock upstream firmware — there `0x011A` is `CMD_SET_HF_FIELD_TIMEOUT` and `hw.led`
+> is a no-op. With the fork flashed (the `firmware/` submodule) it drives the LEDs as below.
 
 **LED control** is platform-aware — color names map to the correct physical LED on both PM3 Easy and RDV4. Accepts color names (`"green"`, `"red"`, `"orange"`, `"blue"`/`"red2"`, `"all"`), letters (`"a"`-`"d"`), comma-separated combos (`"green,red"`), or a bitmask int. Pick one action kwarg:
 
diff --git a/pm3py/core/protocol.py b/pm3py/core/protocol.py
index e866b05..9c0f2f4 100644
--- a/pm3py/core/protocol.py
+++ b/pm3py/core/protocol.py
@@ -157,7 +157,8 @@ class Cmd(IntEnum):
     TIA = 0x0117
     BREAK_LOOP = 0x0118
     SET_TEAROFF = 0x0119
-    LED_CONTROL = 0x011A
+    SET_HF_FIELD_TIMEOUT = 0x011A
+    LED_CONTROL = 0x011B  # our firmware fork (0x011A is upstream's SET_HF_FIELD_TIMEOUT)
     GET_DBGMODE = 0x0120
 
     # FPGA