All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.