* [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads
@ 2021-07-22 11:09 Alex Bennée
2021-07-23 0:49 ` [virtio-comment] " Huang, Yang
2021-07-27 15:45 ` [virtio-comment] " Cornelia Huck
0 siblings, 2 replies; 6+ messages in thread
From: Alex Bennée @ 2021-07-22 11:09 UTC (permalink / raw)
To: virtio-comment
Cc: maxim.uvarov, joakim.bech, ulf.hansson, ilias.apalodimas, arnd,
ruchika.gupta, tomas.winkler, yang.huang, bing.zhu, Matti.Moell,
hmo, Alex Bennée
Previously the text said we fail if block count is set to 1 despite
language elsewhere in the text referring to:
"For RPMB read request, one virtio buffer including request command
and the subsequent [block_count] virtio buffers for response data
are placed in the queue."
and the existence of both max_wr_cnt and max_rd_cnt configuration
variables certainly implying devices should be able to handle
multi-block reads just like writes.
Fix the description as well as format the steps as an enumerated list
to match the style of the previous section describing write handling.
Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
virtio-rpmb.tex | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex
index dfecc3c..1dae3fd 100644
--- a/virtio-rpmb.tex
+++ b/virtio-rpmb.tex
@@ -239,22 +239,24 @@ \subsubsection{Device Operation: Request Queue}\label{sec:Device Types / RPMB De
\devicenormative{\paragraph}{Device Operation: Data Read}{Device Types / RPMB Device / Device Operation / Device Operation: Data Read}
-If the authentication key is not yet programmed then VIRTIO_RPMB_RES_NO_AUTH_KEY
-SHOULD be returned in \field{result}.
+\begin{enumerate}
+\item If the authentication key is not yet programmed then
+ VIRTIO_RPMB_RES_NO_AUTH_KEY SHOULD be returned in \field{result}.
-If block count has not been set to 1 then VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be
-responded as \field{result}.
+\item If block count is zero or greater than \field{max_rd_cnt} then
+ VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as \field{result}.
-If there is an error in the address (out of range) then the \field{result} SHOULD
-be set to VIRTIO_RPMB_RES_ADDR_FAILURE.
+\item If there is an error in the address (out of range) then the
+ \field{result} SHOULD be set to VIRTIO_RPMB_RES_ADDR_FAILURE.
-If data fetch from addressed location inside the device fails then the \field{result}
-SHOULD be VIRTIO_RPMB_RES_READ_FAILURE.
+\item If data fetch from addressed location inside the device fails
+ then the \field{result} SHOULD be VIRTIO_RPMB_RES_READ_FAILURE.
-If some other error occurs during the read procedure then the \field{result}
-SHOULD be VIRTIO_RPMB_RES_GENERAL_FAILURE.
+\item If some other error occurs during the read procedure then the
+ \field{result} SHOULD be VIRTIO_RPMB_RES_GENERAL_FAILURE.
-The \field{req_resp} value VIRTIO_RPMB_RESP_DATA_READ SHOULD be responded.
+\item The device SHOULD respond with \field{block_count} frames containing the data and \field{req_resp} value set to VIRTIO_RPMB_RESP_DATA_READ.
+\end{enumerate}
\devicenormative{\paragraph}{Device Operation: Result Read}{Device Types / RPMB Device / Device Operation / Device Operation: Result Read}
--
2.20.1
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/
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [virtio-comment] RE: [PATCH] virtio-rpmb: fix the description for multi-block reads
2021-07-22 11:09 [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads Alex Bennée
@ 2021-07-23 0:49 ` Huang, Yang
2021-07-27 15:45 ` [virtio-comment] " Cornelia Huck
1 sibling, 0 replies; 6+ messages in thread
From: Huang, Yang @ 2021-07-23 0:49 UTC (permalink / raw)
To: Alex Bennée, virtio-comment
Cc: maxim.uvarov, joakim.bech, ulf.hansson, ilias.apalodimas, arnd,
ruchika.gupta, Winkler, Tomas, Zhu, Bing, Matti.Moell, hmo
> -----Original Message-----
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Thursday, July 22, 2021 7:09 PM
> To: virtio-comment@lists.oasis-open.org
> Cc: maxim.uvarov@linaro.org; joakim.bech@linaro.org; ulf.hansson@linaro.org;
> ilias.apalodimas@linaro.org; arnd@linaro.org; ruchika.gupta@linaro.org;
> Winkler, Tomas <tomas.winkler@intel.com>; Huang, Yang
> <yang.huang@intel.com>; Zhu, Bing <bing.zhu@intel.com>;
> Matti.Moell@opensynergy.com; hmo@opensynergy.com; Alex Bennée
> <alex.bennee@linaro.org>
> Subject: [PATCH] virtio-rpmb: fix the description for multi-block reads
>
> Previously the text said we fail if block count is set to 1 despite language
> elsewhere in the text referring to:
>
> "For RPMB read request, one virtio buffer including request command
> and the subsequent [block_count] virtio buffers for response data
> are placed in the queue."
>
> and the existence of both max_wr_cnt and max_rd_cnt configuration variables
> certainly implying devices should be able to handle multi-block reads just like
> writes.
>
> Fix the description as well as format the steps as an enumerated list to match
> the style of the previous section describing write handling.
>
> Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> virtio-rpmb.tex | 24 +++++++++++++-----------
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/virtio-rpmb.tex b/virtio-rpmb.tex index dfecc3c..1dae3fd 100644
> --- a/virtio-rpmb.tex
> +++ b/virtio-rpmb.tex
> @@ -239,22 +239,24 @@ \subsubsection{Device Operation: Request
> Queue}\label{sec:Device Types / RPMB De
>
> \devicenormative{\paragraph}{Device Operation: Data Read}{Device Types /
> RPMB Device / Device Operation / Device Operation: Data Read}
>
> -If the authentication key is not yet programmed then
> VIRTIO_RPMB_RES_NO_AUTH_KEY -SHOULD be returned in \field{result}.
> +\begin{enumerate}
> +\item If the authentication key is not yet programmed then
> + VIRTIO_RPMB_RES_NO_AUTH_KEY SHOULD be returned in \field{result}.
>
> -If block count has not been set to 1 then
> VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be -responded as \field{result}.
> +\item If block count is zero or greater than \field{max_rd_cnt} then
> + VIRTIO_RPMB_RES_GENERAL_FAILURE SHOULD be responded as
> \field{result}.
Reviewed. Thank you for the correction.
> -If there is an error in the address (out of range) then the \field{result} SHOULD -
> be set to VIRTIO_RPMB_RES_ADDR_FAILURE.
> +\item If there is an error in the address (out of range) then the
> + \field{result} SHOULD be set to VIRTIO_RPMB_RES_ADDR_FAILURE.
>
> -If data fetch from addressed location inside the device fails then the
> \field{result} -SHOULD be VIRTIO_RPMB_RES_READ_FAILURE.
> +\item If data fetch from addressed location inside the device fails
> + then the \field{result} SHOULD be VIRTIO_RPMB_RES_READ_FAILURE.
>
> -If some other error occurs during the read procedure then the \field{result} -
> SHOULD be VIRTIO_RPMB_RES_GENERAL_FAILURE.
> +\item If some other error occurs during the read procedure then the
> + \field{result} SHOULD be VIRTIO_RPMB_RES_GENERAL_FAILURE.
>
> -The \field{req_resp} value VIRTIO_RPMB_RESP_DATA_READ SHOULD be
> responded.
> +\item The device SHOULD respond with \field{block_count} frames containing
> the data and \field{req_resp} value set to VIRTIO_RPMB_RESP_DATA_READ.
> +\end{enumerate}
>
> \devicenormative{\paragraph}{Device Operation: Result Read}{Device Types /
> RPMB Device / Device Operation / Device Operation: Result Read}
>
> --
> 2.20.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads
2021-07-22 11:09 [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads Alex Bennée
2021-07-23 0:49 ` [virtio-comment] " Huang, Yang
@ 2021-07-27 15:45 ` Cornelia Huck
2021-08-02 7:09 ` Alex Bennée
1 sibling, 1 reply; 6+ messages in thread
From: Cornelia Huck @ 2021-07-27 15:45 UTC (permalink / raw)
To: Alex Bennée, virtio-comment
Cc: maxim.uvarov, joakim.bech, ulf.hansson, ilias.apalodimas, arnd,
ruchika.gupta, tomas.winkler, yang.huang, bing.zhu, Matti.Moell,
hmo, Alex Bennée
On Thu, Jul 22 2021, Alex Bennée <alex.bennee@linaro.org> wrote:
> Previously the text said we fail if block count is set to 1 despite
> language elsewhere in the text referring to:
>
> "For RPMB read request, one virtio buffer including request command
> and the subsequent [block_count] virtio buffers for response data
> are placed in the queue."
>
> and the existence of both max_wr_cnt and max_rd_cnt configuration
> variables certainly implying devices should be able to handle
> multi-block reads just like writes.
>
> Fix the description as well as format the steps as an enumerated list
> to match the style of the previous section describing write handling.
>
> Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> virtio-rpmb.tex | 24 +++++++++++++-----------
> 1 file changed, 13 insertions(+), 11 deletions(-)
Do you want to request a vote for this?
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads
2021-07-27 15:45 ` [virtio-comment] " Cornelia Huck
@ 2021-08-02 7:09 ` Alex Bennée
2021-08-02 8:25 ` Cornelia Huck
0 siblings, 1 reply; 6+ messages in thread
From: Alex Bennée @ 2021-08-02 7:09 UTC (permalink / raw)
To: Cornelia Huck
Cc: virtio-comment, maxim.uvarov, joakim.bech, ulf.hansson,
ilias.apalodimas, arnd, ruchika.gupta, tomas.winkler, yang.huang,
bing.zhu, Matti.Moell, hmo
Cornelia Huck <cohuck@redhat.com> writes:
> On Thu, Jul 22 2021, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>> Previously the text said we fail if block count is set to 1 despite
>> language elsewhere in the text referring to:
>>
>> "For RPMB read request, one virtio buffer including request command
>> and the subsequent [block_count] virtio buffers for response data
>> are placed in the queue."
>>
>> and the existence of both max_wr_cnt and max_rd_cnt configuration
>> variables certainly implying devices should be able to handle
>> multi-block reads just like writes.
>>
>> Fix the description as well as format the steps as an enumerated list
>> to match the style of the previous section describing write handling.
>>
>> Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>> virtio-rpmb.tex | 24 +++++++++++++-----------
>> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> Do you want to request a vote for this?
Sure - I think it's a clarification rather than a "new" feature but
whatever is needed to get it merged ;-)
--
Alex Bennée
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads
2021-08-02 7:09 ` Alex Bennée
@ 2021-08-02 8:25 ` Cornelia Huck
2021-08-03 15:38 ` Alex Bennée
0 siblings, 1 reply; 6+ messages in thread
From: Cornelia Huck @ 2021-08-02 8:25 UTC (permalink / raw)
To: Alex Bennée
Cc: virtio-comment, maxim.uvarov, joakim.bech, ulf.hansson,
ilias.apalodimas, arnd, ruchika.gupta, tomas.winkler, yang.huang,
bing.zhu, Matti.Moell, hmo
On Mon, Aug 02 2021, Alex Bennée <alex.bennee@linaro.org> wrote:
> Cornelia Huck <cohuck@redhat.com> writes:
>
>> On Thu, Jul 22 2021, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>> Previously the text said we fail if block count is set to 1 despite
>>> language elsewhere in the text referring to:
>>>
>>> "For RPMB read request, one virtio buffer including request command
>>> and the subsequent [block_count] virtio buffers for response data
>>> are placed in the queue."
>>>
>>> and the existence of both max_wr_cnt and max_rd_cnt configuration
>>> variables certainly implying devices should be able to handle
>>> multi-block reads just like writes.
>>>
>>> Fix the description as well as format the steps as an enumerated list
>>> to match the style of the previous section describing write handling.
>>>
>>> Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> ---
>>> virtio-rpmb.tex | 24 +++++++++++++-----------
>>> 1 file changed, 13 insertions(+), 11 deletions(-)
>>
>> Do you want to request a vote for this?
>
> Sure - I think it's a clarification rather than a "new" feature but
> whatever is needed to get it merged ;-)
Yes, I think it is slightly over the line of things I would merge as an
editorial update, so please open a github issue.
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads
2021-08-02 8:25 ` Cornelia Huck
@ 2021-08-03 15:38 ` Alex Bennée
0 siblings, 0 replies; 6+ messages in thread
From: Alex Bennée @ 2021-08-03 15:38 UTC (permalink / raw)
To: Cornelia Huck
Cc: virtio-comment, maxim.uvarov, joakim.bech, ulf.hansson,
ilias.apalodimas, arnd, ruchika.gupta, tomas.winkler, yang.huang,
bing.zhu, Matti.Moell, hmo
Cornelia Huck <cohuck@redhat.com> writes:
> On Mon, Aug 02 2021, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>> Cornelia Huck <cohuck@redhat.com> writes:
>>
>>> On Thu, Jul 22 2021, Alex Bennée <alex.bennee@linaro.org> wrote:
>>>
>>>> Previously the text said we fail if block count is set to 1 despite
>>>> language elsewhere in the text referring to:
>>>>
>>>> "For RPMB read request, one virtio buffer including request command
>>>> and the subsequent [block_count] virtio buffers for response data
>>>> are placed in the queue."
>>>>
>>>> and the existence of both max_wr_cnt and max_rd_cnt configuration
>>>> variables certainly implying devices should be able to handle
>>>> multi-block reads just like writes.
>>>>
>>>> Fix the description as well as format the steps as an enumerated list
>>>> to match the style of the previous section describing write handling.
>>>>
>>>> Reported-by: Ruchika Gupta <ruchika.gupta@linaro.org>
>>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>>> ---
>>>> virtio-rpmb.tex | 24 +++++++++++++-----------
>>>> 1 file changed, 13 insertions(+), 11 deletions(-)
>>>
>>> Do you want to request a vote for this?
>>
>> Sure - I think it's a clarification rather than a "new" feature but
>> whatever is needed to get it merged ;-)
>
> Yes, I think it is slightly over the line of things I would merge as an
> editorial update, so please open a github issue.
Done:
https://github.com/oasis-tcs/virtio-spec/issues/113
--
Alex Bennée
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-08-03 15:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-22 11:09 [virtio-comment] [PATCH] virtio-rpmb: fix the description for multi-block reads Alex Bennée
2021-07-23 0:49 ` [virtio-comment] " Huang, Yang
2021-07-27 15:45 ` [virtio-comment] " Cornelia Huck
2021-08-02 7:09 ` Alex Bennée
2021-08-02 8:25 ` Cornelia Huck
2021-08-03 15:38 ` Alex Bennée
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.