On 15:25 Tue 07 Jun , Laurent Gauch wrote:
>/ >
/>/ >/If our ft2232.c patches are not merged quickly, Amontec Team will
certainly
/>/ >/>/ come with a new specific jtagkey.c API driver instead of the ft2232.c
JTAG
/>/ >/>/ driver.
/>/ >/>/ The advantage with a specific Amontec JTAGkey API
> Definitely! I'm holding off on this patch in favor of a patch that deletes
> cruft instead of decorating it :-)
I have a soft spot for patches that delete code that nobody
understands
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International
On Thu, Jun 9, 2011 at 8:37 AM, Peter Stuge wrote:
> Andreas Fritiofson wrote:
>> Strange thing with this function is that the allocated buffer doesn't seem
>> to be used for anything. The data read into it doesn't go anywhere. Maybe
>> the entire function is flawed, or is the data really supposed
Andreas Fritiofson wrote:
> Strange thing with this function is that the allocated buffer doesn't seem
> to be used for anything. The data read into it doesn't go anywhere. Maybe
> the entire function is flawed, or is the data really supposed to be
> discarded?
If noone can answer this then I woul
Free the buffer before return. Also check the malloc return value.
Perhaps it's not a good idea to exit() on error, but it's in line with the
rest of the function.
Strange thing with this function is that the allocated buffer doesn't seem
to be used for anything. The data read into it doesn't g
>/
/>/ I suggest to drop this patch and merge a simpler fix for the problem
/>/ adressed by this patch. Only a few lines of code would need to change.
/>/
/>/
/Attached is such a patch. The benefit over Tomek's patch is that it frees
not only the allocated buffer but also closes the ftdi handle (
Øyvind Harboe wrote:
> Nit, the construct below is a little bit fancy. I'd prefer splitting
> it over multiple lines to make it more accessible to the
> casual reader.
Or just use goto, please, which is clear, simple, well understood,
and elegant all at once. :)
//Peter
_
Andreas Fritiofson wrote:
> I'm not very fond of the "infinite-loop-that's-not-actually-a-loop-at-all"
> along with the extra indentation.
+1
> This patch doesn't use gotos either but another (perhaps even more)
> neglected construct, like it or not. :)
Hah. I wouldn't have done it this way, bu
Looks OK to me.
Any objections?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
__
To me this patch looks good. Any objections?
Nit, the construct below is a little bit fancy. I'd prefer splitting
it over multiple lines to make it more accessible to the
casual reader.
In terms of splitting this patch up, it might be possible
to move the ft2232_quit() fn first, but the patch is
Free the buffer before return. Also check the malloc return value.
Perhaps it's not a good idea to exit() on error, but it's in line with the
rest of the function.
Strange thing with this function is that the allocated buffer doesn't seem
to be used for anything. The data read into it doesn't go
On Tue, Jun 7, 2011 at 5:19 PM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> I suggest to drop this patch and merge a simpler fix for the problem
> adressed by this patch. Only a few lines of code would need to change.
>
>
Attached is such a patch. The benefit over Tomek's patch i
On 15:25 Tue 07 Jun , Laurent Gauch wrote:
> >
> >/If our ft2232.c patches are not merged quickly, Amontec Team will certainly
> >/>/ come with a new specific jtagkey.c API driver instead of the ft2232.c
> >JTAG
> >/>/ driver.
> >/>/ The advantage with a specific Amontec JTAGkey API driver in
13 matches
Mail list logo
