Re: [virtio-dev] Re: [virtio-comment] [PATCH] [PATCH v5] virtio-spi: add the device specification

[Jonathon Reinhart <jrreinhart@google.com>]

On Wed, Nov 29, 2023 at 5:00âAM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 29-11-23, 16:54, Haixu Cui wrote:
> > On 11/29/2023 4:33 PM, Cornelia Huck wrote:
> > > On Wed, Nov 29 2023, Haixu Cui <quic_haixcui@quicinc.com> wrote:
> > > > On 11/29/2023 3:30 PM, Viresh Kumar wrote:
> > > > > On 28-11-23, 20:58, Haixu Cui wrote:
> > > > > > On 11/27/2023 6:17 PM, Viresh Kumar wrote:
> > > > > Hmm, I worked with a SPI controller over a decade ago, and I must be forgetting
> > > > > something here I guess. But from whatever little I remember, with full-duplex
> > > > > transfer, data flows on both MOSI and MISO lines as soon as clock signal is
> > > > > applied.  And so amount of data sent is always be equal to amount of data
> > > > > received by both sides.
> > > > >
> > > > > Also if I see Linux's implementation of the `struct spi_transfer` [1], I see
> > > > > `tx_buf`, `rx_buf` and a single `len` field, which applies to both the buffers.
> > > > > Which I guess is indicating that both buffers are supposed to be of same length.
> > > > >
> > > > > What am I missing ?
> > > >
> > > > Oh so sorry for that. And I don't make it clear. Yes, tx_buf and rx_buf
> > > > have the same size, Linux has such restriction. Just as you mention,
> > > > kernel level spi_transfer has single "len", the same for
> > > > spi_ioc_transfer passed from the userland.
> > > >
> > > > But I am not sure if this is in the scope of the spec. Because this is
> > > > ensured by Linux, but Virtio SPI driver won't also can't verify this.
> > > > This is a prerequisite for virtio spi processing requests.
>
> I don't think this is a Linux only thing. This is how the SPI protocol is
> designed to begin with. A clock is applied, data from FIFOs of both master and
> slaves gets exchanged over the MOSI and MISO lines... And the length is _always_
> the same. We are talking about the full-duplex mode of the hardware here and
> this is how it works AFAICT.
>

IMO the length doesn't _need_ to be the same. Sure, the clock always
runs, and the shift registers of the master and slave are always
clocking in data from their respective input lines. But that doesn't
mean that (all of) the received data actually *means* anything -- that
is determined by the application protocol.

For example, the initiator (master) might want to send 100 bytes but
only cares about the first 8 bytes received. Why should it need to
provide a 100 byte buffer for that received data? Certainly the stack
should be capable of discarding the other 92 bytes?

For a given SPI transfer, the clock needs to run for
(max(num_tx_bytes, num_rx_bytes) * word_size) cycles.