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

[Cornelia Huck <cohuck@redhat.com>]

On Fri, Oct 23 2026, Peter Hilber <peter.hilber@oss.qualcomm.com> wrote:

> Qualcomm's intent is to upstream a Linux kernel Virtio driver for a
> non-standardized device using a Virtio transport [1]. It should be able
> to work in a vanilla Linux kernel. I think this requires a new
> "vendor-specific" or similar device. The driver needs to avoid
> collisions with other devices and must not take an unassigned ID.
>
> I think "vendor-specific" does not capture all possible use cases for
> such a device, though. It could be a "self-assigned" device, e.g. for
> prototypes to be standardized later.
>
> In the discussion, it was proposed to distinguish "vendor-specific"
> devices through common configuration space fields. I would suggest to
> use a UUID at the start of the configuration space of the new device 52
> to distinguish "vendor-specific"/"self-assigned" devices. Everybody can
> generate a UUID when needed. This would
>
> - allow everybody to create new devices without ID collisions due to
>   using unregistered IDs
>
> - allow using UUIDs for prototyping, with a new one available for each
>   breaking change

I would prefer to have a namespace for this kind of experimentation,
i.e. <testing prefix><uuid>, with vendor or purpose-specific devices
using <vendor/purpose prefix><uuid>, so that...

>
> - be a way to resolve the device ID scarcity

...this would still hold (I think the most limiting factor for this is
actually ccw? not sure how much we care about implementing new devices
on ccw, though), and...

>
> - relieve Virtio TC from some device ID registration work.

...this would also still somewhat hold (no need to reserve an ID for
everything, but if you're serious, get a vendor-or-purpose prefix.)
I'd still want to encourage everyone creating a serious device to go and
try to standardize it.