Please revert and add a TEST_OK_PR definition. Only PR had been tested for that chip.
In that case I will heavily disagree with this convention of shortening that wasn't documented in the header (after understanding PR actually means probe/read based on our IRC discussion). TEST_OK_PR is very close to TEST_OK_PREW, and it's hard to see what has what when just looking at the struct itself in the code. Also high changes of real typoes, especially after there is precedence of a TEST_OK_PRW for instance, with the reporter reporting probe, read and write to work fine, and not getting back about erase. Still better than UNTESTED but very easy to mistake or typo to PREW.
Meanwhile, added the TEST_OK_PR to the header for now to not claim false things AND be buildable, as requested.
Thanks, Mart Raudsepp
On 28.05.2008 01:56, Mart Raudsepp wrote:
Please revert and add a TEST_OK_PR definition. Only PR had been tested for that chip.
In that case I will heavily disagree with this convention of shortening that wasn't documented in the header (after understanding PR actually means probe/read based on our IRC discussion). TEST_OK_PR is very close to TEST_OK_PREW, and it's hard to see what has what when just looking at the struct itself in the code. Also high changes of real typoes, especially after there is precedence of a TEST_OK_PRW for instance, with the reporter reporting probe, read and write to work fine, and not getting back about erase. Still better than UNTESTED but very easy to mistake or typo to PREW.
Meanwhile, added the TEST_OK_PR to the header for now to not claim false things AND be buildable, as requested.
Thanks!
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Mart Raudsepp