On Fri, 2009-06-12 at 21:42 -0700, David Brownell wrote:
> Doc update: say "jtag newtap ... -disable" records the
> state after exiting the RESET state, matching the only
> implementation we're working with so far (TI ICEpick-C).
>
> Matching code updates, including a few minor cleanups
> mostly related to the JTAG event callback mechanism:
>
> - a memory leak in jtag_tap_free()
> - fix conceptual bug in unregistering JTAG event callbacks
> - remove hidden assumption about JTAG event numbering
> - move function declarations to the header where they belong
> - some end'o'line whitespace
>
> Now we're sure the "enable" flag value is correct after resets.
Why did you move the declarations of jtag_tap_{init,free} to the bottom
of jtag.h? If anything, they should appear near the other jtag_tap_*
routine declarations, but I put them in tcl.c because I think they might
be better wrapped by higher-level TAP APIs such as jtag_tap_create and
jtag_tap_destroy (which exist -- in monolithic form -- inside the JTAG
TCL routines, FWIW). I didn't get that far; the amount of factoring
that could be done is rather overwhelming.
Also, would it be too much to ask to separate your changes into slightly
smaller pieces? Personally, I have been trying to lean towards
bite-sized patches as we move toward 0.2.0; this one chews on few pieces
at once. While the changes look correct, I have been trying to maximize
the ability for others to spot regressions through bisection.
Plus, you will motivate me to finish the "import series from e-mail"
portions of my patch handling scripts, if you start producing series of
patches with a dozen patches each. Or do you think my recent practices
have taken this idea too far?
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
