Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Haixu Cui <quic_haixcui@quicinc.com>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: virtio-dev@lists.oasis-open.org,
	virtio-comment@lists.oasis-open.org,
	harald.mommer@opensynergy.com, broonie@kernel.org,
	qiang4.zhang@linux.intel.com, quic_ztu@quicinc.com,
	alex.bennee@linaro.org, vincent.guittot@linaro.org
Subject: [virtio-dev] Re: [virtio-comment] [PATCH] [PATCH v5] virtio-spi: add the device specification
Date: Wed, 29 Nov 2023 09:33:49 +0100	[thread overview]
Message-ID: <871qc9x8k2.fsf@redhat.com> (raw)
In-Reply-To: <0674be8e-221f-479a-8da2-8a3e59e45bb9@quicinc.com>

On Wed, Nov 29 2023, Haixu Cui <quic_haixcui@quicinc.com> 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2023-11-29  8:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24  7:20 [virtio-dev] [PATCH] [PATCH v5] virtio-spi: add the device specification Haixu Cui
2023-11-24 15:46 ` [virtio-dev] " Cornelia Huck
2023-11-27 13:14   ` Haixu Cui
2023-11-27 14:26     ` Cornelia Huck
2023-11-27 14:33       ` [virtio-dev] Re: [virtio-comment] " Cornelia Huck
2023-11-28 12:23         ` Haixu Cui
2023-11-28 12:32       ` [virtio-dev] " Haixu Cui
2023-11-27 10:17 ` [virtio-dev] Re: [virtio-comment] " Viresh Kumar
2023-11-28 12:58   ` Haixu Cui
2023-11-29  7:30     ` Viresh Kumar
2023-11-29  8:19       ` Haixu Cui
2023-11-29  8:33         ` Cornelia Huck [this message]
2023-11-29  8:54           ` Haixu Cui
2023-11-29 10:00             ` Viresh Kumar
2023-11-29 10:31               ` Haixu Cui
2023-11-29 11:34                 ` Viresh Kumar
2023-11-29 12:42                   ` Cornelia Huck
2023-11-30  4:13                     ` Viresh Kumar
2023-11-30  7:36                       ` Haixu Cui
2023-11-30  7:32                     ` Haixu Cui
2023-11-30 16:43               ` Jonathon Reinhart
     [not found] ` <ZWCbm4pDET31Rn7z@finisterre.sirena.org.uk>
2023-11-27 12:20   ` [virtio-dev] " Haixu Cui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qc9x8k2.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=broonie@kernel.org \
    --cc=harald.mommer@opensynergy.com \
    --cc=qiang4.zhang@linux.intel.com \
    --cc=quic_haixcui@quicinc.com \
    --cc=quic_ztu@quicinc.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox