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