On Tue, Jul 27 2021, Srivatsa Vaddagiri <[email protected]> wrote:
>> > > 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 I don't think we can have the device return NEEDS_RESET in that case; that status is supposed to indicate "that the device has experienced an error from which it can’t recover" -- which is not the case here, especially since the driver has already initiated a reset. > 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
