+typedef int (*jtag_callback_t)(u8 *in, jtag_callback_data_t data1, jtag_callback_data_t data2, jtag_callback_data_t data3);
+
+
+/* This callback can be executed immediately the queue has been flushed. Note that
+ * the JTAG queue can either be executed synchronously or asynchronously. Typically
+ * for USB the queue is executed asynchronously. For low latency interfaces, the
+ * queue may be executed synchronously.
+ *
+ * These callbacks are typically executed *after* the *entire* JTAG queue has been
+ * executed for e.g. USB interfaces.
+ *
+ * The callbacks are guaranteeed to be invoked in the order that they were queued.
+ *
+ * The strange name is due to C's lack of overloading using function arguments
+ *
+ * The callback mechansim is very general and does not really make any assumptions
+ * about what the callback does and what the arguments are.
+ *
+ * in - typically used to point to the data to operate on. More often than not
+ * this will be the data clocked in during a shift operation
+ *
+ * data1 - an integer that is big enough to be used either as an 'int' or
+ * cast to/from a pointer
+ *
+ * data2 - an integer that is big enough to be used either as an 'int' or
+ * cast to/from a pointer
+ *
+ * Why stop at 'data2' for arguments? Somewhat historical reasons. This is
+ * sufficient to implement the jtag_check_value_mask(), besides the
+ * line is best drawn somewhere...
+ *
+ * If the execution of the queue fails before the callbacks, then the
+ * callbacks may or may not be invoked depending on driver implementation.
+ */
+extern void jtag_add_callback4(jtag_callback_t, u8 *in,
+ jtag_callback_data_t data1, jtag_callback_data_t data2,
+ jtag_callback_data_t data3);
+
+
+/* run a TAP_RESET reset. End state is TAP_RESET, regardless
+ * of start state.
+ */
+extern void jtag_add_tlr(void);
+
+/* Application code *must* assume that interfaces will
+ * implement transitions between states with different
+ * paths and path lengths through the state diagram. The
+ * path will vary across interface and also across versions
+ * of the same interface over time. Even if the OpenOCD code
+ * is unchanged, the actual path taken may vary over time
+ * and versions of interface firmware or PCB revisions.
+ *
+ * Use jtag_add_pathmove() when specific transition sequences
+ * are required.
+ *
+ * Do not use jtag_add_pathmove() unless you need to, but do use it
+ * if you have to.
+ *
+ * DANGER! If the target is dependent upon a particular sequence
+ * of transitions for things to work correctly(e.g. as a workaround
+ * for an errata that contradicts the JTAG standard), then pathmove
+ * must be used, even if some jtag interfaces happen to use the
+ * desired path. Worse, the jtag interface used for testing a
+ * particular implementation, could happen to use the "desired"
+ * path when transitioning to/from end
+ * state.
+ *
+ * A list of unambigious single clock state transitions, not