Re: [PATCH v2] content: Reserve ID 52 for QPSFI device

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 22, 2026 at 03:49:51PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: 22 October 2026 09:12 PM
> > 
> > On Thu, Oct 22, 2026 at 03:35:51PM +0000, Parav Pandit wrote:
> > >
> > > > From: Cornelia Huck <cohuck@redhat.com>
> > > > Sent: 22 October 2026 08:35 PM
> > > >
> > > > On Thu, Oct 22 2026, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > > >
> > > > > Let's define some standard way for the vendors to declare that this
> > > > > device is "Qualcomm", "NXP" or "hobbyist which doesn't own PCI or USB id
> > > > > block".
> > > >
> > > > Are we able to use the first <n> bytes of config space for that? I guess
> > > > that is the only way that can possibly work for any transport.
> > > >
> > > > Then, maybe something like one or two bytes for a vendor id (including
> > > > one for "testing purposes" or so), and the rest to be used in a
> > > > vendor-specific way.
> > > >
> > > device ids are independent of the transport.
> > >
> > > but Peter already announced that:
> > > " Reserve a device ID for QPSFI devices (Qualcomm Platform Subsystem
> > > Firmware Interface). QPSFI devices expose functionality across SoC
> > > subsystems through a common Virtio-based protocol. There are no plans to
> > > standardize the devices."
> > >
> > > So, I am unable to understand why should it be part of vendor agnostic virtio spec?
> > > Why a vendor specific implementation of device and driver is not sufficient?
> > 
> > I don't really think we should vendors burn up device IDs every
> > times they want something non standard. Reserving ID 52 as
> > "vendor specific" so vendors can go wild sounds good,
> > but a bit more needs to be done than just reserving:
> > document what is expected, e.g. no auto load based on ID
> > alone.
> 
> First, you indicate to open virtio to vendor specific extension. This is huge in itself.

Not as such.  It's just reserving an id. People always do things like
implement some crazy spec saying "we will upstream later" and later they
do not.
And then the ID conflicts with a standard one. Suboptimal.

So if we can tell everyone "always use this ID, and use platform
specific tool dor discovery, until your device is in the spec"
then that's not too bad.



> that should be first discussed.
> If you suggest this, may be every device type should be able to extend, and not just demux at device id level.
> 
> Second, one reserved id is not enough, because a given system may have multiple such different vendors devices installed.

I don't think we should care.

> So why to bend things so much and re-invent the wheel?
> Why for say PCI transport's any vendor and device id are not sufficient to indicate a vendor and device?
> 
> and if so, why to even document it in the virtio spec?
> 
> I guess, I am missing the basic motivation part.

For the virtio spec? Above. For Qualcomm since they decided never to
upstream - donnu. Don't care much, either...