diff --git a/src/jtag/jtag.c b/src/jtag/jtag.c
index 751e53f96e1454d4f73f4118d05c4a1ce542b9c8..0af508032a134750373b3538531287e8534d2e17 100644
--- a/src/jtag/jtag.c
+++ b/src/jtag/jtag.c
@@ -2569,10 +2569,31 @@ static int handle_tms_sequence_command(struct command_context_s *cmd_ctx, char *
 }
 
 /**
- * Function jtag_add_statemove
- * moves from the current state to the goal \a state. This needs
+ * Moves from the current state to the goal \a state. This needs
  * to be handled according to the xsvf spec, see the XSTATE command
  * description.
+ *
+ * From the XSVF spec, pertaining to XSTATE:
+ *
+ * For special states known as stable states (Test-Logic-Reset,
+ * Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
+ * predefined TAP state paths when the starting state is a stable state
+ * and when the XSTATE specifies a new stable state.  See the STATE
+ * command in the [Ref 5] for the TAP state paths between stable
+ * states.
+ *
+ * For non-stable states, XSTATE should specify a state that is only one
+ * TAP state transition distance from the current TAP state to avoid
+ * undefined TAP state paths. A sequence of multiple XSTATE commands can
+ * be issued to transition the TAP through a specific state path.
+ *
+ * @note Unless @a tms_bits holds a path that agrees with [Ref 5] in *
+ * above spec, then this code is not fully conformant to the xsvf spec.
+ * This puts a burden on tap_get_tms_path() function from the xsvf spec.
+ * If in doubt, you should confirm that that burden is being met.
+ *
+ * Otherwise, state must be immediately reachable in one clock cycle,
+ * and does not need to be a stable state.
  */
 int jtag_add_statemove(tap_state_t goal_state)
 {
@@ -2589,35 +2610,14 @@ int jtag_add_statemove(tap_state_t goal_state)
 		tap_state_name(goal_state) );
 
 
-	/*	From the XSVF spec, pertaining to XSTATE:
-
-		For special states known as stable states (Test-Logic-Reset,
-		Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
-		predefined TAP state paths when the starting state is a stable state and
-		when the XSTATE specifies a new stable state (see the STATE command in
-		the [Ref 5] for the TAP state paths between stable states). For
-		non-stable states, XSTATE should specify a state that is only one TAP
-		state transition distance from the current TAP state to avoid undefined
-		TAP state paths. A sequence of multiple XSTATE commands can be issued to
-		transition the TAP through a specific state path.
-	*/
-
 	if (goal_state==cur_state )
 		;	/* nothing to do */
-
 	else if( goal_state==TAP_RESET )
 	{
 		jtag_add_tlr();
 	}
-
 	else if( tap_is_state_stable(cur_state) && tap_is_state_stable(goal_state) )
 	{
-		/* 	note: unless tms_bits holds a path that agrees with [Ref 5] in above
-			spec, then this code is not fully conformant to the xsvf spec.  This
-			puts a burden on tap_get_tms_path() function from the xsvf spec.
-			If in doubt, you should confirm that that burden is being met.
-		*/
-
 		tms_bits  = tap_get_tms_path(cur_state, goal_state);
 		tms_count = tap_get_tms_path_len(cur_state, goal_state);
 
@@ -2633,10 +2633,6 @@ int jtag_add_statemove(tap_state_t goal_state)
 
 		jtag_add_pathmove(tms_count, moves);
 	}
-
-	/*	else state must be immediately reachable in one clock cycle, and does not
-		need to be a stable state.
-	*/
 	else if( tap_state_transition(cur_state, true)  == goal_state
 		||   tap_state_transition(cur_state, false) == goal_state )
 	{