* [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset
@ 2021-07-22 9:19 Srivatsa Vaddagiri
2021-07-22 9:26 ` Jason Wang
0 siblings, 1 reply; 6+ messages in thread
From: Srivatsa Vaddagiri @ 2021-07-22 9:19 UTC (permalink / raw)
To: mst, jasowang, virtio-dev; +Cc: Trilok Soni, Pratik Patel
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
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
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>
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.
+
Drivers not expecting shared memory MUST NOT use the shared
memory registers.
---
Qualcomm Innovation Center, Inc. is submitting the attached "feedback" as a non-member to the virtio-dev mailing list for consideration and inclusion.
[-- Attachment #2: Type: text/html, Size: 3555 bytes --]
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset
2021-07-22 9:19 [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset Srivatsa Vaddagiri
@ 2021-07-22 9:26 ` Jason Wang
2021-07-22 10:57 ` Cornelia Huck
2021-07-22 11:09 ` Srivatsa Vaddagiri
0 siblings, 2 replies; 6+ messages in thread
From: Jason Wang @ 2021-07-22 9:26 UTC (permalink / raw)
To: Srivatsa Vaddagiri, mst, virtio-dev; +Cc: Trilok Soni, Pratik Patel
在 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.
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.
> +
> Drivers not expecting shared memory MUST NOT use the shared
> memory registers.
>
>
> ---
>
> Qualcomm Innovation Center, Inc. is submitting the attached "feedback"
> as a non-member to the virtio-dev mailing list for consideration and
> inclusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset
2021-07-22 9:26 ` Jason Wang
@ 2021-07-22 10:57 ` Cornelia Huck
2021-07-22 12:53 ` Jason Wang
2021-07-22 11:09 ` Srivatsa Vaddagiri
1 sibling, 1 reply; 6+ messages in thread
From: Cornelia Huck @ 2021-07-22 10:57 UTC (permalink / raw)
To: Jason Wang, Srivatsa Vaddagiri, mst, virtio-dev; +Cc: Trilok Soni, Pratik Patel
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset
2021-07-22 9:26 ` Jason Wang
2021-07-22 10:57 ` Cornelia Huck
@ 2021-07-22 11:09 ` Srivatsa Vaddagiri
1 sibling, 0 replies; 6+ messages in thread
From: Srivatsa Vaddagiri @ 2021-07-22 11:09 UTC (permalink / raw)
To: Jason Wang, mst, virtio-dev; +Cc: Trilok Soni, Pratik Patel
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
> > 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.
I see this as fixing a bug in spec/code rather than adding any new feature, so
perhaps no.
- vatsa
---
Qualcomm Innovation Center, Inc. is submitting the attached "feedback" as a non-member to the virtio-dev mailing list for consideration and inclusion.
[-- Attachment #2: Type: text/html, Size: 2612 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset
2021-07-22 10:57 ` Cornelia Huck
@ 2021-07-22 12:53 ` Jason Wang
2021-07-22 15:41 ` Srivatsa Vaddagiri
0 siblings, 1 reply; 6+ messages in thread
From: Jason Wang @ 2021-07-22 12:53 UTC (permalink / raw)
To: Cornelia Huck, Srivatsa Vaddagiri, mst, virtio-dev
Cc: Trilok Soni, Pratik Patel
在 2021/7/22 下午6:57, Cornelia Huck 写道:
> 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.
The (hardware) device can refuse the feature negotiation if driver
doesn't support the feature.
This makes sure the driver is not broken by the device.
Thanks
>
>>
>> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset
2021-07-22 12:53 ` Jason Wang
@ 2021-07-22 15:41 ` Srivatsa Vaddagiri
0 siblings, 0 replies; 6+ messages in thread
From: Srivatsa Vaddagiri @ 2021-07-22 15:41 UTC (permalink / raw)
To: Jason Wang, Cornelia Huck, mst, virtio-dev; +Cc: Trilok Soni, Pratik Patel
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
> >> 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.
>
>
> The (hardware) device can refuse the feature negotiation if driver
> doesn't support the feature.
>
> This makes sure the driver is not broken by the device.
Let me send the next patch with a new feature bit added. I guess I can use bit
40 for it (VIRTIO_F_MMIO_RESET_WAIT)?
- vatsa
---
Qualcomm Innovation Center, Inc. is submitting the attached "feedback" as a
non-member to the virtio-dev mailing list for consideration and inclusion.
[-- Attachment #2: Type: text/html, Size: 1400 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-22 15:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-22 9:19 [virtio-dev] [PATCH] virtio-mmio: Specify wait needed in driver during reset Srivatsa Vaddagiri
2021-07-22 9:26 ` Jason Wang
2021-07-22 10:57 ` Cornelia Huck
2021-07-22 12:53 ` Jason Wang
2021-07-22 15:41 ` Srivatsa Vaddagiri
2021-07-22 11:09 ` Srivatsa Vaddagiri
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.