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

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

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