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

On 11/29/2023 4:33 PM, Cornelia Huck wrote:
> On Wed, Nov 29 2023, Haixu Cui <[email protected]> wrote:
> 
>> Hi Viresh,
>>
>> 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:
>>>>> On 24-11-23, 15:20, Haixu Cui wrote:
>>>>>> +For half-duplex read transfer, \field{rx_buf} is filled by Virtio SPI device and consumed
>>>>>> +by Virtio SPI driver. For half-duplex write transfer, \field{tx_buf} is filled by Virtio
>>>>>> +SPI driver and consumed by Virtio SPI device. And for full-duplex read and write transfer,
>>>>>> +both \field{tx_buf} and \field{rx_buf} are used.
>>>>>
>>>>> Should the length of both the buffers in full-duplex mode be same ? If yes, then
>>>>> this should be mentioned (in case it is not).
>>>>>
>>>>
>>>> No, there is no such limitation. Write and read buffers may be different is
>>>> size.
>>>
>>> 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.
>>
>> 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.
> 
> 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.

Okay! Thanks Huck for guidance and thanks Viresh for pointing it out. 
Much appreciated.

Best Regards
Haixu Cui

> 
> 
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: [email protected]
> Unsubscribe: [email protected]
> List help: [email protected]
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
> 


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [email protected]
Unsubscribe: [email protected]
List help: [email protected]
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: 
https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]