As of today (2011.06), the generic gpio command (common/cmd_gpio.c) gpio <input|set|clear|toggle> <port><pin> - input/set/clear/toggle the specified pin (e.g. PF10) always returns the value read or set.
While this is sensible for read (input) and maybe (questionable) for toggle, I don't see an usage for write (set/clear).
Also, this leads to unexpected side effects with complex constructs, e.g. consider this environment: setA=gpio set PF1 setB=gpio clear PF2 setAB_separate=env run setA ; env run setB setAB_concatenated=env run setA setB setBA_concatenated=env run setB setA
While executing "setAB_separate" and "setBA_concatenated" work as expected, "setAB_concatenated" will only run setA, but not setB, as setA "failed" (ret=1). [1] The same would apply to e.g. && constructs.
As it works this way in the release and hence the behaviour is essentially fixed, changing the return value is probably not an option. OTOH, the breakage here might be negligible, at least for set/clear. But in any case, it should be documented.
Beside this, I'd like to extend the gpio command with the additional actions "0" and "1", always returning 0 (given the write was successful): gpio <input|set|clear|toggle|0|1> <port><pin>
As a nice benefit, it would strip down constructs like if test ${LED_x} -eq 0;then gpio set PF1;else gpio clear PF1;fi to a simple "gpio ${LED_x} PF1".
Any comments or objections before I submit a patch ?
[1] http://www.denx.de/wiki/DULG/CommandLineParsing "General rules"