Hi Andreas,
Thank you for your comment.
It doesn't build. Leftover variable no longer used.
minor issue
Apart from that it seems OK from my limited review. I could agree with the
others that it looks like a needlessly complex fix for a simple missing
free. Maybe there's a bigger picture here but I don't get the open/init
deinit/close separation or why it's needed (Why would you want to open
without initializing?). Haven't given it much thought though. Is the
mentioned followup patch already posted?
The mentioned patches are not posted, but ready to.
As asked by maintainer's, we want to have small and precise patches.
We only posted the patch 1/5 .
https://lists.berlios.de/pipermail/openocd-development/2011-May/019176.html
We want to have it merged before to give the 2..5/5.
The 2..5/5 will be depending of the acceptation of 1/5 ...
---
We do not want to open without init, but we want to init or re-init an already
opened device handle :-)
In the same way, we want to deinit without having to close the device handle !
In an other way, we want to be able to force deinit and close or close only
without having to have a interface quit() call from the upper layer, in case
something wrong during open init or others.
We want to make sure any USB JTAG SWD adapters based ft2232 (as jtagkey) are
correctly deinitialized at any shutdown of openocd (as via jtagkey_deinit).
(Actually nothing is done during the quit except close the handle ... but we
have to make sure deassert JTAG PORT AND TRST SRST IO (and to deassert SWD
mode), to reset the MPSSE, to go away the bit-bang mode, and only then close
the handle)
If we split this to a deinit() close() we will produce a much better code.
Having open init deinit close well separated IN the ft2232.c will help us to
make the ft2232 interface more robust and more clean.
But remember, the open init deinit close ARE NOT ON THE INTERFACE API,
Regards,
Laurent
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 High-speed USB JTAG dongle
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
