[U-Boot] [RFC] gpio command: return value on write, additional actions

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday, July 05, 2011 15:15:15 Andreas Pretzsch wrote:
> Am Dienstag, den 05.07.2011, 13:44 -0400 schrieb Mike Frysinger:
> > 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.
> 
> Didn't quite get that. In terms of "gpio value" = "give me the current
> (output latch) value without setting it to input if it's an output" ?

yes.  all it does is return gpio_get_value().

> We can't change the return value of "gpio input", as it's out in the
> wild and would break existing scripts.

i dont think this is that big of a deal

> I'd say clear/set/toggle are changeable, don't see any legit
> return-value-usage here. For 100% backward compatibility, one could
> leave them as they are and use 0|1 as new actions with return 0, as
> proposed.
> 
> So these variants:
>   gpio clear|0 => set to output, write 0, return success
>   gpio set|1   => set to output, write 1, return success
>   gpio toggle  => (set to output), toggle output, return success
>   gpio input   => set to input, return pin value
>   gpio value   => return current pin/latch/whatever value
> or
>   gpio clear   => set to output, write 0, return 0
>   gpio set     => set to output, write 1, return 1
>   gpio 0       => set to output, write 0, return success
>   gpio 1       => set to output, write 1, return success
>   gpio toggle  => (set to output), toggle output, return new_val
>   gpio input   => set to input, return pin value
>   gpio value   => return current pin/latch/whatever value
> 
> Not perfectly symmetric, but the best way out I can think of.
> Maybe "get" instead of "value", as it's more usual. OTOH, get (to some
> people) implies "set to input", so value is more explicit.

i prefer to have the command be simple and throw the extended logic onto the 
people writing scripts rather than trying to encode script logic into the 
commands themselves

> > > 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 || :
>
> Not fully, you'd need "gpio set PF1 || true". Not that this makes it
> less ugly...

but it is doable if we want to just say now "ignore the value" without 
changing any code
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110705/ff122f6c/attachment.pgp