OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] Re: [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ


On Sun, Jun 11, 2023 at 08:17:56PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 11, 2023 4:09 PM
> 
> > > > It's not conformant to that statement then :( It's a SHOULD which
> > > > means if you know exactly what you are doing, there could be exceptions.
> > > > In this case it's a SHOULD because it was added after 1.0 and we did
> > > > not find a way to negotiate this requirement since it's the feature negotiation
> > itself.
> > >
> > > True. May be in future such device can update the revision id.
> > 
> > You can already change it but that doesn't imply anything at all, in 1.0 revisions
> > are vendor specific.
> 
> I was suggesting that when such a fundamental change is done which cannot be communicated via features bit or before the reset,
> a new revision and attaching more advance/different behavior.
> This way driver knows what difference to expect for new revision.

But you don't know which revision do existing devices use:
	Drivers MUST match any PCI Revision ID value.

we can come up with a mechanism, several ideas come to mind.
Before we bother, the actual need has to be understood.

-- 
MST



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]