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
next prev parent 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