OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [PATCH] virtio-rpmb: fix the description for multi-block reads



> -----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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]