On Tue, 07 May 2013 10:37:57 +0200 Nico Huber nico.huber@secunet.com wrote:
I am not entirely sure why the translation table was introduced in the first place although dediprog's indices could be "stored" in the array offset, but mixing the two approaches is of course not a good idea.
The translation table was used to make it obvious that the speeds are not ordered (see speed values for 12M and 8M). As the value range is continuous, we could use the array index as value. But please, comment on the interchanged speeds, when doing so.
Well, I see one flaw in the current code: The default value for spispeed_idx in dediprog_init() (2 --> 8M) doesn't match the value mentioned in the manpage (12M).
That's exactly why I started looking at it. I even had a patch that changed the default frequency in the manpage already :) No idea how I cam up with that stupid change... thanks for catching that.
Obviously I got quite confused by the 3 ways of communicating the requested SPI frequency (the string, the index of the array, the integer that is stored in the array and gets transferred to the programmer). I think that is kinda awkward although I see the point of course.
I will leave it alone anyway since it is there already and we don't know what Dediprog might bring us in the future ;) I will however change the default spispeed_idx from 2 to 1 matching the manpage and the default of Dediprog's CLI tool.