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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

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


Subject: Re: [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset


On Thu, Jul 22 2021, Jason Wang <jasowang@redhat.com> wrote:

> å 2021/7/22 äå5:19, Srivatsa Vaddagiri åé:
>> This is following up on the discussion we had earlier on MMIO reset 
>> behavior:
>>
>> https://lists.oasis-open.org/archives/virtio-dev/202107/msg00012.html 
>> <https://lists.oasis-open.org/archives/virtio-dev/202107/msg00012.html>
>>
>> Suggesting below change to spec to make it explicit what's expected in 
>> driver. If this is accepted, I will follow up with a patch to Linux 
>> driver.
>>
>> ===
>>
>> Device reset is accomplished by writing 0 to Status register. 
>> Explicitly note
>> that a driver needs to wait on Status register read returning 0 before 
>> assuming that
>> device reset operation is complete.
>> Signed-off-by: Srivatsa Vaddagiri <svaddagi@qti.qualcomm.com>
>
>
>
> I wonder if it deserves a feature bit.

Not sure what that feature bit should govern; if it is not negotiated,
the device must assume that the driver considers the reset to be
complete right after writing? I'm not sure what the device is supposed
to do then.

>
>
> Thanks
>
>
>>
>> diff --git a/content.tex b/content.tex
>> index 5c70a3c..7631be4 100644
>> --- a/content.tex
>> +++ b/content.tex
>> @@ -1985,6 +1985,10 @@ \subsubsection{Device 
>> Initialization}\label{sec:Virtio Transport Options / Virti
>> Âand if its value is zero (0x0) MUST abort initialization and
>> ÂMUST NOT access any other register.
>> +After writing 0 to \field{Status}, the driver MUST wait for a read of
>> +\field{Status} to return 0 before proceeding with the remaining steps of
>> +initializing the device.

Maybe move this to the "MMIO Device Register Layout" driver normative
section.

Should that have a companion device normative statement (just as for
PCI)?

>> +
>> ÂDrivers not expecting shared memory MUST NOT use the shared
>> Âmemory registers.



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