[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v1] virtio-mmio: Specify wait needed in driver during reset
在 2021/7/27 上午3:03, Michael S. Tsirkin 写道:
On Mon, Jul 26, 2021 at 02:17:08PM +0000, Srivatsa Vaddagiri wrote:On Mon, Jul 26, 2021 at 01:36:56PM +0200, Cornelia Huck wrote:On Mon, Jul 26 2021, Srivatsa Vaddagiri<svaddagi@qti.qualcomm.com> wrote:+indicated by a read of \field{Status} returning 0. Such a device MUSTalsofail to accept +FEATURES_OK bit if driver does not negotiateVIRTIO_F_MMIO_RESET_WAIT.So, this basically means that an older driver that does not know the new feature bit will not work with devices offering this bit, even if it did poll? This seems acceptable, I just wanted to spell it out.Yes I believe that's the desired result. Device has no way to know ifdriverwill poll for reset completion or not unless it accepts the feature. Are you suggesting we explicitly put in some text in spec to that effect?Not sure whether it is needed (do others have an opinion?), but probably not.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? - vatsaHmm. that doesn't sound too good. Makes using feature negotiation for this kind of useless ...
Yes, the tricky part is that the reset happens before the features negotiation.
Device can actually detect a read from status, right?
I'm not sure if MMIO can always behave like a register. E.g can area just plain DRAM?
Maybe if it sees status was not read it can just stay in reset state and not exit it?
Or I wonder we can use increase the version instead. Thanks
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]