stp: correct what the blocking state does

A blocked port does pass a received BPDU up to the CPU. The evidence is in
logicog's capture of a looped pair: the port the loop check had already
blocked kept reporting a BPDU age of zero seconds across dumps taken more
than a forward delay apart, and that counter is only cleared in stp_in().
That is also what makes the loop latch work, since the port that stays
forwarding has to go on hearing the blocked one.

The tag flag comment said the source address is not learned on the egress
port. doc/CpuPort.md defines it as not learning the source address from the
frame at all, which is the narrower claim to make. The dangling heading
above it described a field that is documented there too.

doc/stp.md

@@ -59,9 +59,10 @@ to the CPU. `stp_setup()` prints a warning for every STP-enabled port in that
 state.
 
 Port states live in `RTL837X_MSTP_STATES (0x5310)`, two bits per port:
-`00` disabled, `01` blocking, `10` learning, `11` forwarding. In the blocking
-state a port forwards nothing except frames sent by the CPU, and nothing it
-receives reaches the CPU.
+`00` disabled, `01` blocking, `10` learning, `11` forwarding. A port in
+blocking forwards nothing between ports, but it still sends what the CPU
+hands it and still passes a received BPDU up to the CPU, which is what lets
+loop detection go on working on a port it has already blocked.
 
 ## Timers
 

rtl837x_common.h

@@ -72,9 +72,8 @@ struct vlan_tag {
 #define RTL_FRAME_TAG_ID	0x8899
 #define RTL_FRAME_TAG_VERSION	0x04
 /* Bits of the tag's `flags` word, see doc/CpuPort.md. */
-#define RTL_TAG_LEARN_DIS	0x0020	/* do not learn the CPU's SA on the egress port */
+#define RTL_TAG_LEARN_DIS	0x0020	/* do not learn the source address from this frame */
 #define RTL_TAG_KEEP		0x0080	/* keep the frame's 802.1Q tag format as injected */
-/* The `pmask` word, see doc/CpuPort.md. */
 
 // For TX, an 8 byte (plus 4 byte padding when when VLAN is enabled)
 // header describing the frame to be moved to the Asic is used