linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Winkler, Tomas" <tomas.winkler@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Usyskin, Alexander" <alexander.usyskin@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Wang, Yu1" <yu1.wang@intel.com>,
	"Liu, Shuo A" <shuo.a.liu@intel.com>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>
Subject: Re: [char-misc-next 13/13] mei: virtio: virtualization frontend driver
Date: Thu, 26 Nov 2020 04:58:35 -0500	[thread overview]
Message-ID: <20201126045340-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7f6181d8e80d4efb9464e9ec436800b7@intel.com>

On Wed, Nov 25, 2020 at 09:18:04PM +0000, Winkler, Tomas wrote:
> > 
> > On Tue, Aug 18, 2020 at 02:51:47PM +0300, Tomas Winkler wrote:
> > > +#ifndef VIRTIO_ID_MEI
> > > +#define VIRTIO_ID_MEI 0xFFFE /* virtio mei */ #endif
> > 
> > Just noticed now that this driver landed upstream.  Can I ask that you guys
> > please register IDs with the virtio TC and not just pick a number at random?
> > In particular this is way outside allowed range.
> > 
> > IDs should also be listed in include/uapi/linux/virtio_ids.h
> > 
> > If people just pick random numbers like this collistions are unavoidable.
> > 
> > List of IDs is part of virtio spec, chapter "Device Types".
> > 
> > Please do this change now before this goes out to production!
> Okay,  this was assigned by ACRN, my impression was it's already registered.
> Will take care of.
> Thanks
> Tomas

Found this:
https://projectacrn.github.io/latest/developer-guides/hld/hld-virtio-devices.html

Supported Virtio Devices
All the BE virtio drivers are implemented using the ACRN virtio APIs, and the FE drivers are reusing the standard Linux FE virtio drivers. For the devices with FE drivers available in the Linux kernel, they should use standard virtio Vendor ID/Device ID and Subsystem Vendor ID/Subsystem Device ID. For other devices within ACRN, their temporary IDs are listed in the following table.

Table 5 Virtio Devices without existing FE drivers in Linux
virtio device	Vendor ID	Device ID	Subvendor ID	Subdevice ID
RPMB	0x8086	0x8601	0x8086	0xFFFF
HECI	0x8086	0x8602	0x8086	0xFFFE
audio	0x8086	0x8603	0x8086	0xFFFD
IPU	0x8086	0x8604	0x8086	0xFFFC
TSN/AVB	0x8086	0x8605	0x8086	0xFFFB
hyper_dmabuf	0x8086	0x8606	0x8086	0xFFFA
HDCP	0x8086	0x8607	0x8086	0xFFF9
COREU	0x8086	0x8608	0x8086	0xFFF8
I2C	0x8086	0x860a	0x8086	0xFFF6
GPIO	0x8086	0x8609	0x8086	0xFFF7

so IIUC what you are using is a temporary ID which is fine for
experimentation but not for production.

Note it does take a couple of weeks for a TC to vote on reserving an ID
so pls do not delay this too much.

-- 
MST


  reply	other threads:[~2020-11-26  9:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 11:51 [char-misc-next 00/13] mei: add support for virtual tags Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 01/13] mei: hbm: add capabilities message Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 02/13] mei: restrict vtag support to hbm version 2.2 Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 03/13] mei: add vtag support bit in client properties Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 04/13] mei: add support for mei extended header Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 05/13] mei: bump hbm version to 2.2 Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 06/13] mei: add a spin lock to protect rd_completed queue Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 07/13] mei: add a vtag map for each client Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 08/13] mei: handle tx queue flushing for vtag connections Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 09/13] mei: bus: use zero vtag for bus clients Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 10/13] mei: bus: unconditionally enable clients with vtag support Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 11/13] mei: add connect with vtag ioctl Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 12/13] mei: docs: add vtag ioctl documentation Tomas Winkler
2020-08-18 11:51 ` [char-misc-next 13/13] mei: virtio: virtualization frontend driver Tomas Winkler
2020-11-25 21:08   ` Michael S. Tsirkin
2020-11-25 21:18     ` Winkler, Tomas
2020-11-26  9:58       ` Michael S. Tsirkin [this message]
2020-12-03 21:51       ` Michael S. Tsirkin
2020-12-03 22:01         ` Greg Kroah-Hartman
2020-12-05 19:40           ` Michael S. Tsirkin
2020-12-06  9:37             ` Greg Kroah-Hartman

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=20201126045340-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alexander.usyskin@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shuo.a.liu@intel.com \
    --cc=tomas.winkler@intel.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=yu1.wang@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).