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

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

On Thu, Oct 22, 2026 at 11:41:17AM +0300, Manos Pitsidianakis wrote:
> On Thu, Oct 22, 2026 at 10:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Oct 22, 2026 at 03:07:41AM -0400, Demi Marie Obenour wrote:
> > > On 10/22/26 00:35, Cornelia Huck wrote:
> > > > On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > >
> > > >> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
> > > >>> On 10/21/26 14:00, Peter Hilber wrote:
> > > >>>> 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.
> > > >>>>
> > > >>>> The Linux DCP display driver series is planned as the first user of this
> > > >>>> device ID:
> > > >>>>
> > > >>>> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> > > >>>>
> > > >>>> Device ID 51 is already reserved for the Virtio HAB device:
> > > >>>>
> > > >>>> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> > > >>>>
> > > >>>> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > > >>>> ---
> > > >>>>
> > > >>>>     v2:
> > > >>>>
> > > >>>>     - Rename the device from "Snapdragon device" to "QPSFI device".
> > > >>>>
> > > >>>>     - Refer to DCP Linux driver patch as planned first QPSFI user.
> > > >>>>
> > > >>>>     v1:
> > > >>>>
> > > >>>>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
> > > >>>>
> > > >>>>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> > > >>>>
> > > >>>>  content.tex | 2 ++
> > > >>>>  1 file changed, 2 insertions(+)
> > > >>>>
> > > >>>> diff --git a/content.tex b/content.tex
> > > >>>> index 243ce2dde36b..7416939e67d3 100644
> > > >>>> --- a/content.tex
> > > >>>> +++ b/content.tex
> > > >>>> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > > >>>>  \hline
> > > >>>>  50         &   Video encoder/decoder device \\
> > > >>>>  \hline
> > > >>>> +52         &   QPSFI device \\
> > > >>>> +\hline
> > > >>>>  \end{longtable}
> > > >>>>
> > > >>>>  Some of the devices above are unspecified by this document,
> > > >>>
> > > >>> I think it would be best to have a single ID for vendor-specific devices.
> > > >>> I believe most of the ID space has already been used, at least for virtio-PCI.
> > > >>> --
> > > >>> Sincerely,
> > > >>> Demi Marie Obenour (she/her/hers)
> > > >>
> > > >> Sounds like a good idea to me. And then qualcomm can do what they
> > > >> want, like check subsystem id for pci or whatever?
> > > >> Only issue is there is no way to distinguish for mmio/ccw.
> > > >> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
> > > >> Peter?
> > > >
> > > > Using some information in the config space looks like the most flexible
> > > > way to me. Are we still happy with how the device ids are organized in
> > > > general (i.e. when do we want a new one, and when do we want to extend
> > > > an existing device?)
> > >
> > > For a platform device like this, I'd prefer to pass the information out
> > > of band.  After all, this device will only ever be found on Qualcomm
> > > SoCs, and presumably the kernel knows exactly which PCI device is
> > > supposed to be the QPSFI device.  This means that the kernel can just
> > > special-case it.
> >
> > Yes but we are discussing making this id a general "vendor specific
> > device", as opposed to a "qualcomm device".
> 
> Is there a reason why a generic VIRTIO_ID_VENDOR wouldn't work?
> 
> Instead of adding more and more IDs for different devices that will
> never been upstreamed.
> 
> Then, a kernel can discover all vendor devices when enumerating the
> transport, ignore them unless it knows specifically about them through
> ACPI or device tree.
> 
> It doesn't make sense to me that HAB/QPSFI need an ID when they are
> unusable to anyone except for qualcomm kernel drivers so maybe we
> should require that an ID allocation always needs an explicit
> justification (i.e. "the spec will be upstreamed", or "we cannot use
> VIRTIO_ID_VENDOR because X/Y/Z").

Right so let's just reserve ID 52 as VIRTIO_ID_VENDOR for now.
And document precisely what you are saying.

And let's add a chapter for it please:

"A driver is not automatically loaded based on VIRTIO_ID_VENDOR alone,
 instead, the platform probes the device, verifies it is the
 correct vendor specific driver and loads it, all in
 a platform specific way".

and conformance clauses stating the same.

-- 
MST