On Tuesday, July 05, 2011 12:59:16 Andreas Pretzsch wrote:
> 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).

the trouble with toggle is that there's no way to get the value without 
changing it to the input.  we'd have to add another field that has no 
unintentional side effects like "gpio value".  then we could change all the 
others to return 0/1 based on whether they succeeded, not based on the level 
of the gpio pin.

> 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.

ive never used the shell in u-boot, but couldnt the first logic be:
        setA=gpio set PF1 || :
        setB=gpio clear PF2 || :

> As it works this way in the release and hence the behaviour is
> essentially fixed, changing the return value is probably not an option.

not really.  poor behavior can be adjusted.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to