All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
	Demi Marie Obenour <demiobenour@gmail.com>,
	Peter Hilber <peter.hilber@oss.qualcomm.com>,
	"virtio-comment@lists.linux.dev" <virtio-comment@lists.linux.dev>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Trilok Soni <trilok.soni@oss.qualcomm.com>
Subject: Re: [PATCH v2] content: Reserve ID 52 for QPSFI device
Date: Thu, 22 Oct 2026 11:41:52 -0400	[thread overview]
Message-ID: <20261022114028-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <SJ0PR12MB6806C8FCEDA2E3D40CA82EB6DC652@SJ0PR12MB6806.namprd12.prod.outlook.com>

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.


-- 
MST


  reply	other threads:[~2026-10-22 15:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 18:00 [PATCH v2] content: Reserve ID 52 for QPSFI device Peter Hilber
2026-10-21 19:25 ` Demi Marie Obenour
2026-10-21 19:50   ` Michael S. Tsirkin
2026-10-22  4:35     ` Cornelia Huck
2026-10-22  7:07       ` Demi Marie Obenour
2026-10-22  7:24         ` Michael S. Tsirkin
2026-10-22  8:41           ` Manos Pitsidianakis
2026-10-22 13:19             ` Michael S. Tsirkin
2026-10-22 14:07               ` Dmitry Baryshkov
2026-10-22 15:05                 ` Cornelia Huck
2026-10-22 15:35                   ` Parav Pandit
2026-10-22 15:41                     ` Michael S. Tsirkin [this message]
2026-10-22 15:49                       ` Parav Pandit
2026-10-22 16:02                         ` Michael S. Tsirkin
2026-10-22 16:20                           ` Parav Pandit
2026-10-22 16:29                             ` Michael S. Tsirkin
2026-10-22 22:39                               ` Peter Hilber
2026-10-22 23:28                                 ` Michael S. Tsirkin
2026-10-23  3:32                                 ` Parav Pandit
2026-10-23  5:37                                 ` Manos Pitsidianakis
2026-10-23  5:40                                   ` Demi Marie Obenour
2026-10-23 20:56                                     ` Peter Hilber
2026-10-23 23:47                                       ` Michael S. Tsirkin
2026-10-26 14:31                                       ` Cornelia Huck
2026-10-28 14:22                                         ` Peter Hilber
2026-10-22 15:44                 ` Michael S. Tsirkin
2026-10-22 14:50               ` Zelong Ren
2026-10-21 19:41 ` Michael S. Tsirkin
2026-10-22 13:56 ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261022114028-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=demiobenour@gmail.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=parav@nvidia.com \
    --cc=peter.hilber@oss.qualcomm.com \
    --cc=stefanha@redhat.com \
    --cc=trilok.soni@oss.qualcomm.com \
    --cc=virtio-comment@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.