I am all in favor for this change. But I would prefer to eliminate the
cases first where jtag_add_end_state() is called immediately before
jtag_add_*r_scan(..., TAP_INVALID).


On arm11.h:
ARM11_TAP_DEFAULT should not be changed. It is used only between the
arm11 and the arm11_dbgtap layer. The calls to the jtag.c layer all
use explicit end states.


Michael


On Wed, May 20, 2009 at 5:39 PM, Øyvind Harboe <[email protected]> wrote:
> This patch is intended to collect feedback on a change to the JTAG API.
>
> I do *not* intend to commit any of this until after a discussion & 0.2 
> release:
>
> 1. remove TAP_INVALID as a legal argument. The caller *must* provide
> an end state.
> 2. deprecate jtag_add_end_state(). It is the calling code's responsibility
> to figure out what the end state should be. Today this is handled
> by a global variable, but the calling code can, in time, be converted to
> handle this more cleanly.
>
> Steps:
>
> 1. A patch like the attached one. Remove TAP_INVALID as a valid argument.
> This should be a pretty safe change and have no effect whatsoever. Commit
> it and wait a week or so for any fallout to be reported(inconceivable, but
> I'm just being paranoid about this step). I will redo this patch against svn
> head when it is time to implement step #1(it took 5 minutes to put together).
>
> 2. remove all code in jtag.c that assumes that TAP_INVALID can be passed
> in as an argument. Commit & wait.
>
> 3. remove all code in interface drivers that assumes TAP_INVALID can be
> passed in. Commit & wait.
>
> 4. rename jtag_add_end_state() to deprecated_add_end_state(). Commit & wait.
>
> Done!
>
> At this point the code is "littered" with usage of global variables. This 
> usage
> should be cleaned up in due course, but on a schedule that allows testing each
> commit.
>
>
> Comments?
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://consulting.zylin.com
>
> _______________________________________________
> Openocd-development mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to