[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]