Am Donnerstag, den 21.07.2011, 11:01 +0200 schrieb Detlev Zundel:
Hi Mike,
[...]
Following the common U-Boot way to do this, I'd suggest sspi [<bus>:]<cs>[.<mode>] <bit_len> <dout> [din_env_var] and either never print the read result to the console (my favorite) or only if no env variable to store is passed. To be defined, comments welcome.
is this the common u-boot approach ? seems like extending every random func to take a supplementary env var is the wrong way. if the hush shell simply supported syntax like: foo="`sspi ......`" then every command would get this for free
Indeed - this would be the best solution and I would greatly appreciate such a feature as it would be a big step in what we can script (elegantly) in U-Boot.
Full ACK that. I'd love to have a (nearly) full-scale hush shell in U-Boot. Esp. as IMHO we left the "small scale bootloader" area for quite some time now. And adjusting to different hardware variants purely by script instead of special code is a valuable target IMHO. A bit inconvenient with U-Boot hush shell, but doable.
But I doubt that this will be there in the immediate future (sorry, currently no time on my side for this). And it won't help with the old parser.
So how to proceed with the sspi command ? - keep it as it is, ignoring the "read not scriptable" status - strip down the printf output to only the value (required for ``) - add the additional parameter
Personally, I don't care that much, as I don't need a SPI read in any of my devices here and could live with the noisy SPI write. But as I opened up this issue, I'd like to finalize it.
Wolfgang, Detlev, Mike, please decide.
In this context, I suppose the original "spi.w" patch is NAK ?
Also, given any rework of the sspi command, cmd_spi.c should probably be checkpatch-massaged (9 errors, 11 warnings, incl. kernel-stuff) before. The usual whitespace and line length issues. I suppose this would go in despite merge window closure, but any other change won't, so submit it as separate patch instead of a series ?