public inbox for virtualization@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Shunsuke Mie <mie@igel.co.jp>
Cc: "Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Frank Li" <Frank.Li@nxp.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	"Ren Zhijie" <renzhijie2@huawei.com>,
	"Jon Mason" <jdmason@kudzu.us>,
	"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [RFC PATCH v2 3/3] PCI: endpoint: Add EP function driver to provide virtio-console functionality
Date: Thu, 27 Apr 2023 13:09:06 -0500	[thread overview]
Message-ID: <20230427180906.GA261441@bhelgaas> (raw)
In-Reply-To: <20230427104428.862643-4-mie@igel.co.jp>

Random typos and trivial things.  No need to repost until somebody
does a more substantive review.

On Thu, Apr 27, 2023 at 07:44:28PM +0900, Shunsuke Mie wrote:
> Add a new PCIe endpoint function driver that works as a pci virtio-console
> device. The console connect to endpoint side console. It enables to
> communicate PCIe host and endpoint.

s/pci/PCI/

> Architecture is following:
> 
>  ┌────────────┐         ┌──────────────────────┬────────────┐
>  │virtioe     │         │                      │virtio      │
>  │console drv │         ├───────────────┐      │console drv │
>  ├────────────┤         │(virtio console│      ├────────────┤
>  │ virtio bus │         │ device)       │◄────►│ virtio bus │
>  ├────────────┤         ├---------------┤      └────────────┤
>  │            │         │ pci ep virtio │                   │
>  │  pci bus   │         │  console drv  │                   │
>  │            │  pcie   ├───────────────┤                   │
>  │            │ ◄─────► │  pci ep Bus   │                   │
>  └────────────┘         └───────────────┴───────────────────┘
>    PCIe Root              PCIe Endpoint

s/virtioe/virtio/
s/pci/PCI/
s/pcie/PCIe/
s/ep/EP/

> +config PCI_EPF_VCON
> +	tristate "PCI Endpoint virito-console driver"

s/virito/virtio/

> +	depends on PCI_ENDPOINT
> +	select VHOST_RING
> +	select PCI_EPF_VIRTIO
> +	help
> +	  PCIe Endpoint virtio-console function implementatino. This module
> +	  enables to show the virtio-console as pci device to PCIe host side, and
> +	  another virtual virtio-console device registers to endpoint system.
> +	  Those devices are connected virtually and can communicate each other.

s/implementatino/implementation/
s/pci/PCI/
s/can communicate/can communicate with/

> + * PCI Endpoint function driver to impliment virtio-console device
> + * functionality.

s/impliment/implement/

> +static int virtio_queue_size = 0x100;
> +module_param(virtio_queue_size, int, 0444);
> +MODULE_PARM_DESC(virtio_queue_size, "A length of virtqueue");

When and why would users need this parameter?  Where is it documented?

> +	/* To access virtqueus of local host driver */

s/virtqueus/virtqueues/

> +	/* To show a status whether this driver is ready and the remote is connected */

Make this fit in 80 columns.

> +	/* This is a minimum implementation. Doesn't support any features of
> +	 * virtio console. It means driver and device use just 2 virtuque for tx
> +	 * and rx.
> +	 */

Use common multi-line comment style:

  /*
   * This is ...
   */

s/virtuque/virtqueues/

> +static void epf_vcon_raise_irq_handler(struct work_struct *work)
> +{
> +	struct epf_vcon *vcon =
> +		container_of(work, struct epf_vcon, raise_irq_work);

Rewrap.

> +static int epf_vcon_setup_common(struct epf_vcon *vcon)
> +{
> +	vcon->features = 0;
> +	vcon->connected = false;
> +
> +	vcon->task_wq =
> +		alloc_workqueue("pci-epf-vcon/task-wq",

Looks like this would fit on the previous line?

> +				WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0);

> +static void epf_vcon_initialize_complete(void *param)
> +{
> +	struct epf_vcon *vcon = param;
> +
> +	pr_debug("Remote host has connected\n");

Is there any device info you could include here, e.g., with dev_dbg()?
It's nice if users have a little context.

> +static int epf_vcon_setup_ep_func(struct epf_vcon *vcon, struct pci_epf *epf)
> +{
> +	int err;
> +	struct epf_virtio *evio = &vcon->evio;
> +	unsigned int nvq = epf_vcon_get_nvq(vcon);
> +
> +	vcon->rdev_iovs =
> +		kmalloc_array(nvq, sizeof(vcon->rdev_iovs[0]), GFP_KERNEL);

Move the function name and as many parameters as fit in 80 columns to
the previous line to match prevailing style.

> +	/* There is no config for virtio console because this console device
> +	 * doesn't any support features
> +	 */

Multi-line comment style.

s/doesn't any support/doesn't support any/?  Is that what you mean?

> +	/* Do nothing because this console device doesn't any support features */

Same.

> +static void epf_vcon_vdev_set_status(struct virtio_device *vdev, u8 status)
> +{
> +	if (status & VIRTIO_CONFIG_S_FAILED)
> +		pr_debug("driver failed to setup this device\n");

dev_dbg() if possible.

> +		err = vringh_init_kern(&vcon->vdev_vrhs[i], vcon->features,
> +				       virtio_queue_size, false, vring->desc,
> +				       vring->avail, vring->used);
> +		if (err) {
> +			pr_err("failed to init vringh for vring %d\n", i);

dev_err() if possible.

> +static int epf_vcon_setup_vdev(struct epf_vcon *vcon, struct device *parent)
> +{
> +	int err;
> +	struct virtio_device *vdev = &vcon->vdev;
> +	const unsigned int nvq = epf_vcon_get_nvq(vcon);
> +
> +	vcon->vdev_vrhs =
> +		kmalloc_array(nvq, sizeof(vcon->vdev_vrhs[0]), GFP_KERNEL);

Rewrap.

> +	vcon->vdev_iovs =
> +		kmalloc_array(nvq, sizeof(vcon->vdev_iovs[0]), GFP_KERNEL);

Rewrap.

> +	vcon->vdev_vqs =
> +		kmalloc_array(nvq, sizeof(vcon->vdev_vrhs[0]), GFP_KERNEL);

Rewrap.

> +static void epf_vcon_cleanup_vdev(struct epf_vcon *vcon)
> +{
> +	unregister_virtio_device(&vcon->vdev);
> +	/* Cleanup struct virtio_device that has kobject, otherwise error occures when
> +	 * reregister the virtio device.
> +	 */

Multi-line style and rewrap to fit in 80 columns.

> +static int __init epf_vcon_init(void)
> +{
> +	int err;
> +
> +	err = pci_epf_register_driver(&epf_vcon_drv);
> +	if (err)
> +		pr_err("Failed to register PCI EP virtio-console function\n");

dev_err() if possible (doesn't look like it *is* possible).

Looks like this registers a *driver*, so maybe change the message from
"function" to "driver"?

Bjorn
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2023-04-27 18:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-27 10:44 [RFC PATCH v2 0/3] Introduce a PCIe endpoint virtio console Shunsuke Mie
2023-04-27 10:44 ` [RFC PATCH v2 1/3] PCI: endpoint: introduce a helper to implement pci ep virtio function Shunsuke Mie
2023-04-27 18:28   ` Bjorn Helgaas
2023-05-10  3:49     ` Shunsuke Mie
2023-05-08  3:57   ` Jason Wang
2023-04-27 10:44 ` [RFC PATCH v2 2/3] virtio_pci: add a definition of queue flag in ISR Shunsuke Mie
2023-05-08  3:59   ` Jason Wang
2023-05-10  3:18     ` Shunsuke Mie
2023-04-27 10:44 ` [RFC PATCH v2 3/3] PCI: endpoint: Add EP function driver to provide virtio-console functionality Shunsuke Mie
2023-04-27 18:09   ` Bjorn Helgaas [this message]
2023-05-10  1:25     ` Shunsuke Mie
2023-05-08  4:03   ` Jason Wang
2023-05-10  3:17     ` Shunsuke Mie
2023-05-18  9:54       ` Shunsuke Mie
2023-05-19  2:01         ` Jason Wang
2023-05-31 10:51           ` Shunsuke Mie
2023-04-27 17:52 ` [RFC PATCH v2 0/3] Introduce a PCIe endpoint virtio console Bjorn Helgaas

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=20230427180906.GA261441@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=jdmason@kudzu.us \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=mie@igel.co.jp \
    --cc=mst@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=renzhijie2@huawei.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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