OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.

So the spec should clearly point this out to avoid any mistakes. Or if you have
a usecase where you can have different lengths for tx and rx buffers, that I am
not aware of ?

> > > What is your suggestion? How about adding some descriptions here, like
> > > "for full-duplex, tx_buf and rx_buf are same in size, this is guaranteed
> > > by the kernel"?
> > 
> > We must not really make any assumptions in the spec about concrete
> > implementations (here, the Linux kernel), as someone implementing it in
> > a different environment will need to make explicit choices.

I agree. I pointed this out since this is how the protocol works.

> > So, if tx_buf and rx_buf are required to be of the same size, it needs
> > to be explicitly stated in the spec, or an implementation might choose
> > to do it differently.

--
Viresh


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]