On Saturday 13 June 2009, Zach Welch wrote:
> > > 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 id
> > > Why did you move the declarations of jtag_tap_{init,free} to the bottom
> > > of jtag.h?
> >
> > Lack of reason to put them anywhere else in that file. They
> > clearly didn't belong as externs in that ".c" file, though.
>
> Better than exposing them in a public API. I had thought about
On Sat, 2009-06-13 at 01:46 -0700, David Brownell wrote:
> On Saturday 13 June 2009, Zach Welch wrote:
> > 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
> > > implem
On Saturday 13 June 2009, Zach Welch wrote:
> 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).
> >
> > Matchin
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
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 jt
