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

[Srivatsa Vaddagiri <svaddagi@qti.qualcomm.com>]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

> > > What about resets before FEATURES_OK? How are these handled?
> >
> > From device perspective, it's reset logic will always be same, independent of
> > when reset was performed by driver (before or after feature negotiation). A
> > driver that does not wait for reset completion will see undefined behavior
> > after
> > reset until it discovers that feature negotiation has failed?
>
> Hmm. that doesn't sound too good. Makes using
> feature negotiation for this kind of useless ...
> Device can actually detect a read from status, right?
> Maybe if it sees status was not read it can just
> stay in reset state and not exit it?

Thinking on those lines, I am wondering if we can avoid the feature bit
all together based on that logic.

1) Driver writes 0 to status register - device initiates reset sequence
2) Driver reads status - return 0x40 (VIRTIO_CONFIG_S_NEEDS_RESET)
   if reset sequence is in progress, otherwise return 0
3) Driver writes status (ACKNOWLEDGE Bit) - if this happened before reset
   sequence completed and before we returned 0 for status read, then reject
   further initialization by setting VIRTIO_CONFIG_S_NEEDS_RESET (until next
   reset that is)

This should let device detect if we have a driver polling on reset completion or
not?

---

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: 2288 bytes --]