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