[PATCH v5 4/4] spi: spidev_test Add three missing spi mode bits

Andy Shevchenko andy.shevchenko at gmail.com
Mon May 22 04:07:58 PDT 2023


On Mon, May 22, 2023 at 10:23 AM Börge Strümpfel
<boerge.struempfel at gmail.com> wrote:
> Am So., 21. Mai 2023 um 21:26 Uhr schrieb Andy Shevchenko
> <andy.shevchenko at gmail.com>:
> > On Sun, May 21, 2023 at 2:35 PM Börge Strümpfel
> > <boerge.struempfel at gmail.com> wrote:
> > > Am So., 21. Mai 2023 um 11:00 Uhr schrieb Andy Shevchenko
> > > <andy.shevchenko at gmail.com>:

...

> > > Thanks for the suggestion. I tried coming up with a logical way of
> > > ordering, but I am having some difficulties deciding. What do you
> > > think of the following order?
> > >
> > > general device settings
> > > " -D --device device to use (default /dev/spidev1.1)\n"
> > > " -s --speed max speed (Hz)\n"
> > > " -d --delay delay (usec)\n"
> > > " -l --loop loopback\n"
> > >
> > > spi mode
> > > " -H --cpha clock phase\n"
> > > " -O --cpol clock polarity\n"
> > > " -F --rx-cpha-flip flip CPHA on Rx only xfer\n"
> > >
> > > number of wires for transmission
> > > " -2 --dual dual transfer\n"
> > > " -4 --quad quad transfer\n"
> > > " -8 --octal octal transfer\n"
> > > " -3 --3wire SI/SO signals shared\n"
> > > " -Z --3wire-hiz high impedance turnaround\n"
> > >
> > > additional parameters
> > > " -b --bpw bits per word\n"
> > > " -L --lsb least significant bit first\n"
> > > " -C --cs-high chip select active high\n"
> > > " -N --no-cs no chip select\n"
> > > " -R --ready slave pulls low to pause\n"
> > > " -M --mosi-idle-low leave mosi line low when idle\n"
> > >
> > > data
> > > " -i --input input data from a file (e.g. \"test.bin\")\n"
> > > " -o --output output data to a file (e.g. \"results.bin\")\n"
> > > " -p Send data (e.g. \"1234\\xde\\xad\")\n"
> > > " -S --size transfer size\n"
> > > " -I --iter iterations\n");
> > >
> > > misc
> > > " -v --verbose Verbose (show tx buffer)\n"
> >
> > Looks great to me, thank you for doing that!
> >
> You are welcome.
> Should I only reorder the flags, or actually introduce the
> "group"-headers to visibly distinguish the options?

Up to you. If you think it increases the usability I'm all for it.

-- 
With Best Regards,
Andy Shevchenko



More information about the linux-arm-kernel mailing list