All of lore.kernel.org
 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: 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.


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: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
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/


WARNING: multiple messages have this Message-ID (diff)
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:33 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24  7:20 [virtio-comment] [PATCH] [PATCH v5] virtio-spi: add the device specification Haixu Cui
2023-11-24  7:20 ` [virtio-dev] " Haixu Cui
2023-11-24 15:46 ` [virtio-comment] " Cornelia Huck
2023-11-24 15:46   ` [virtio-dev] " Cornelia Huck
2023-11-27 13:14   ` [virtio-comment] " Haixu Cui
2023-11-27 13:14     ` [virtio-dev] " Haixu Cui
2023-11-27 14:26     ` [virtio-comment] " Cornelia Huck
2023-11-27 14:26       ` [virtio-dev] " Cornelia Huck
2023-11-27 14:33       ` [virtio-comment] " Cornelia Huck
2023-11-27 14:33         ` [virtio-dev] " Cornelia Huck
2023-11-28 12:23         ` Haixu Cui
2023-11-28 12:23           ` [virtio-dev] " Haixu Cui
2023-11-28 12:32       ` Haixu Cui
2023-11-28 12:32         ` [virtio-dev] " Haixu Cui
2023-11-27 10:17 ` [virtio-comment] " Viresh Kumar
2023-11-27 10:17   ` [virtio-dev] " Viresh Kumar
2023-11-28 12:58   ` Haixu Cui
2023-11-28 12:58     ` [virtio-dev] " Haixu Cui
2023-11-29  7:30     ` Viresh Kumar
2023-11-29  7:30       ` [virtio-dev] " Viresh Kumar
2023-11-29  8:19       ` Haixu Cui
2023-11-29  8:19         ` [virtio-dev] " Haixu Cui
2023-11-29  8:33         ` Cornelia Huck [this message]
2023-11-29  8:33           ` Cornelia Huck
2023-11-29  8:54           ` Haixu Cui
2023-11-29  8:54             ` [virtio-dev] " Haixu Cui
2023-11-29 10:00             ` Viresh Kumar
2023-11-29 10:00               ` [virtio-dev] " Viresh Kumar
2023-11-29 10:31               ` Haixu Cui
2023-11-29 10:31                 ` [virtio-dev] " Haixu Cui
2023-11-29 11:34                 ` Viresh Kumar
2023-11-29 11:34                   ` [virtio-dev] " Viresh Kumar
2023-11-29 12:42                   ` Cornelia Huck
2023-11-29 12:42                     ` [virtio-dev] " Cornelia Huck
2023-11-30  4:13                     ` Viresh Kumar
2023-11-30  4:13                       ` [virtio-dev] " Viresh Kumar
2023-11-30  7:36                       ` Haixu Cui
2023-11-30  7:36                         ` [virtio-dev] " Haixu Cui
2023-11-30  7:32                     ` Haixu Cui
2023-11-30  7:32                       ` [virtio-dev] " Haixu Cui
2023-11-30 16:43               ` Jonathon Reinhart
     [not found] ` <ZWCbm4pDET31Rn7z@finisterre.sirena.org.uk>
2023-11-27 12:20   ` [virtio-comment] " Haixu Cui
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.