Hi Mike,
On Mon, Feb 27, 2012 at 10:32 AM, Mike Frysinger <vap...@gentoo.org> wrote:
> On Monday 27 February 2012 00:43:30 Simon Glass wrote:
>> On Sun, Feb 26, 2012 at 8:42 PM, Mike Frysinger wrote:
>> > drivers/mtd/spi/sandbox.c:
>> > static int sb_cmdline_cb_spi_sf(struct sandbox_state *state, const char
>> > *arg) {
>> > unsigned long bus, cs;
>> > const char *spec = sb_spi_parse_spec(arg, &bus, &cs);
>> >
>> > if (!spec)
>> > return 1;
>> >
>> > state->spi[bus][cs][0] = &sb_sf_ops;
>> > state->spi[bus][cs][1] = spec;
>> > return 0;
>> > }
>> > SB_CMDLINE_OPT(spi_sf, 1, "connect a SPI flash: <bus>:<cs>:<id>:<file>");
>>
>> sandbox...give me your address and I'll send you a cheque to cover the
>> bytes so used :-)
>
> it'll have to be a big one to stop the cascading line wrapping :P
>
>> > and people could do:
>> > ./u-boot --spi_sf 0:3:m25p16:./some-file.bin
>> > this would connect the spi flash simulation up to the simulated spi bus 0
>> > on cs 3 and have it simulate a m25p16 flash with "some-file.bin" backing
>> > it.
>> >
>> > if someone were to enter the wrong value for
>> > "0:3:m25p16:./some-file.bin", how do you propose we communicate that ?
>> > the existing code can easily signal the higher parsing logic via return
>> > values, but then we'd just get:
>> > failed to parse option: 0:3:m25p16:./some-file.bin
>> >
>> > but what exactly did the code not like ? was it the bus # ? the cs # ?
>> > the spi flash id ? the backing file ? if the getopt code has access
>> > to printf(), we can clearly communicate to the user what is going wrong.
>>
>> Yes I think printf() is useful in getopt, I just would prefer to avoid
>> using U-Boot's printf. It goes through all the console code, and we
>> might be running a test that deliberately breaks that, perhaps.
>> Actually this could be a pretty important thing to sort out - we need
>> to keep a clear boundary between test code and U-Boot code (as we
>> discussed over GPIO). Having the test code use U-Boot's printf() is
>> blurring that.
>
> we probably need to add architecture details like this to doc/README.sandbox
> so we can stay on the same page ...
Yes I agree.
>
>> To your example, if the syntax is correct perhaps, then it got through
>> initial parsing. If the filename is wrong, or the bus number, then
>> perhaps there will be a message and failure much later. Perhaps the
>> initial parsing just does what it can to avoid running past an obvious
>> syntax error. But we can't really know success until we open the file,
>> or try the bus.
>
> if the bus/cs are valid, the rest of the parsing is delayed until you do "sf
> probe" at which point you'd get an explanation of what is wrong. i guess we
> can live with this for now.
Yes, I feel like we have done more than enough plumbing in advance of
use. Let's see how it goes.
Regards,
Simon
> -mike
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
