From: Jason Gunthorpe <jgg@ziepe.ca>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: davem@davemloft.net, gregkh@linuxfoundation.org,
Dave Ertman <david.m.ertman@intel.com>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
nhorman@redhat.com, sassmann@redhat.com, parav@mellanox.com,
galpress@amazon.com, selvin.xavier@broadcom.com,
sriharsha.basavapatna@broadcom.com, benve@cisco.com,
bharat@chelsio.com, xavier.huwei@huawei.com,
yishaih@mellanox.com, leonro@mellanox.com, mkalderon@marvell.com,
aditr@vmware.com, ranjani.sridharan@linux.intel.com,
pierre-louis.bossart@linux.intel.com,
Kiran Patil <kiran.patil@intel.com>,
Andrew Bowers <andrewx.bowers@intel.com>
Subject: Re: [net-next 1/9] Implementation of Virtual Bus
Date: Fri, 17 Apr 2020 16:51:48 -0300 [thread overview]
Message-ID: <20200417195148.GL26002@ziepe.ca> (raw)
In-Reply-To: <20200417171034.1533253-2-jeffrey.t.kirsher@intel.com>
On Fri, Apr 17, 2020 at 10:10:26AM -0700, Jeff Kirsher wrote:
> +/**
> + * virtbus_release_device - Destroy a virtbus device
> + * @_dev: device to release
> + */
> +static void virtbus_release_device(struct device *_dev)
> +{
> + struct virtbus_device *vdev = to_virtbus_dev(_dev);
> +
> + ida_simple_remove(&virtbus_dev_ida, vdev->id);
> + vdev->release(vdev);
This order should probably be swapped (store vdev->id on the stack)
> +/**
> + * virtbus_register_device - add a virtual bus device
> + * @vdev: virtual bus device to add
> + */
> +int virtbus_register_device(struct virtbus_device *vdev)
> +{
> + int ret;
> +
> + /* Do this first so that all error paths perform a put_device */
> + device_initialize(&vdev->dev);
> +
> + if (!vdev->release) {
> + ret = -EINVAL;
> + dev_err(&vdev->dev, "virtbus_device MUST have a .release callback that does something.\n");
> + goto device_pre_err;
This does put_device but the release() hasn't been set yet. Doesn't it
leak memory?
> + }
> +
> + /* All device IDs are automatically allocated */
> + ret = ida_simple_get(&virtbus_dev_ida, 0, 0, GFP_KERNEL);
> + if (ret < 0) {
> + dev_err(&vdev->dev, "get IDA idx for virtbus device failed!\n");
> + goto device_pre_err;
Do this before device_initialize()
> + }
> +
> +
> + vdev->dev.bus = &virtual_bus_type;
> + vdev->dev.release = virtbus_release_device;
And this immediately after
> +
> + vdev->id = ret;
> + dev_set_name(&vdev->dev, "%s.%d", vdev->name, vdev->id);
Missing check of return code
Can't understand why vdev->name is being passed in with the struct,
why not just a function argument?
> + dev_dbg(&vdev->dev, "Registering virtbus device '%s'\n",
> + dev_name(&vdev->dev));
> +
> + ret = device_add(&vdev->dev);
> + if (ret)
> + goto device_add_err;
This looks like it does ida_simple_remove twice, once in the goto and
once from the release function called by put_device.
> +/**
> + * virtbus_unregister_device - remove a virtual bus device
> + * @vdev: virtual bus device we are removing
> + */
> +void virtbus_unregister_device(struct virtbus_device *vdev)
> +{
> + device_del(&vdev->dev);
> + put_device(&vdev->dev);
> +}
> +EXPORT_SYMBOL_GPL(virtbus_unregister_device);
Just inline this as wrapper around device_unregister
> +/**
> + * __virtbus_register_driver - register a driver for virtual bus devices
> + * @vdrv: virtbus_driver structure
> + * @owner: owning module/driver
> + */
> +int __virtbus_register_driver(struct virtbus_driver *vdrv, struct module *owner)
> +{
> + if (!vdrv->probe || !vdrv->remove || !vdrv->shutdown || !vdrv->id_table)
> + return -EINVAL;
> +
> + vdrv->driver.owner = owner;
> + vdrv->driver.bus = &virtual_bus_type;
> + vdrv->driver.probe = virtbus_probe_driver;
> + vdrv->driver.remove = virtbus_remove_driver;
> + vdrv->driver.shutdown = virtbus_shutdown_driver;
> + vdrv->driver.suspend = virtbus_suspend_driver;
> + vdrv->driver.resume = virtbus_resume_driver;
> +
> + return driver_register(&vdrv->driver);
> +}
> +EXPORT_SYMBOL_GPL(__virtbus_register_driver);
> +
> +/**
> + * virtbus_unregister_driver - unregister a driver for virtual bus devices
> + * @vdrv: virtbus_driver structure
> + */
> +void virtbus_unregister_driver(struct virtbus_driver *vdrv)
> +{
> + driver_unregister(&vdrv->driver);
> +}
> +EXPORT_SYMBOL_GPL(virtbus_unregister_driver);
Also just inline this
> diff --git a/include/linux/virtual_bus.h b/include/linux/virtual_bus.h
> new file mode 100644
> index 000000000000..4df06178e72f
> +++ b/include/linux/virtual_bus.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * virtual_bus.h - lightweight software bus
> + *
> + * Copyright (c) 2019-20 Intel Corporation
> + *
> + * Please see Documentation/driver-api/virtual_bus.rst for more information
> + */
> +
> +#ifndef _VIRTUAL_BUS_H_
> +#define _VIRTUAL_BUS_H_
> +
> +#include <linux/device.h>
> +
> +struct virtbus_device {
> + struct device dev;
> + const char *name;
> + void (*release)(struct virtbus_device *);
> + int id;
id can't be negative
> +int virtbus_register_device(struct virtbus_device *vdev);
> +void virtbus_unregister_device(struct virtbus_device *vdev);
I continue to think the alloc/register pattern, eg as demonstrated by
vdpa_alloc_device() and vdpa_register_device() is easier for drivers
to implement correctly.
> +int
> +__virtbus_register_driver(struct virtbus_driver *vdrv, struct module *owner);
> +void virtbus_unregister_driver(struct virtbus_driver *vdrv);
> +
> +#define virtbus_register_driver(vdrv) \
> + __virtbus_register_driver(vdrv, THIS_MODULE)
> +
It is reasonable to also provide a module_driver() macro.
Jason
next prev parent reply other threads:[~2020-04-17 19:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 17:10 [net-next 0/9][pull request] 100GbE Intel Wired LAN Driver Updates 2020-04-17 Jeff Kirsher
2020-04-17 17:10 ` [net-next 1/9] Implementation of Virtual Bus Jeff Kirsher
2020-04-17 19:14 ` Pierre-Louis Bossart
2020-04-17 19:51 ` Jason Gunthorpe [this message]
2020-04-20 23:16 ` Ertman, David M
2020-04-21 0:44 ` Jason Gunthorpe
2020-04-21 23:27 ` Ertman, David M
2020-04-18 12:50 ` Greg KH
2020-04-20 22:59 ` Ertman, David M
2020-04-21 6:52 ` Greg KH
2020-04-20 23:46 ` Ranjani Sridharan
2020-04-17 17:10 ` [net-next 2/9] ice: Create and register virtual bus for RDMA Jeff Kirsher
2020-04-17 19:17 ` Jason Gunthorpe
2020-04-20 23:47 ` Kirsher, Jeffrey T
2020-04-17 23:49 ` Jason Gunthorpe
2020-04-17 17:10 ` [net-next 3/9] ice: Complete RDMA peer registration Jeff Kirsher
2020-04-17 17:10 ` [net-next 4/9] ice: Support resource allocation requests Jeff Kirsher
2020-04-17 17:10 ` [net-next 5/9] ice: Enable event notifications Jeff Kirsher
2020-04-17 17:10 ` [net-next 6/9] ice: Allow reset operations Jeff Kirsher
2020-04-17 17:10 ` [net-next 7/9] ice: Pass through communications to VF Jeff Kirsher
2020-04-17 17:10 ` [net-next 8/9] i40e: Move client header location Jeff Kirsher
2020-04-17 17:10 ` [net-next 9/9] i40e: Register a virtbus device to provide RDMA Jeff Kirsher
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=20200417195148.GL26002@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=aditr@vmware.com \
--cc=andrewx.bowers@intel.com \
--cc=benve@cisco.com \
--cc=bharat@chelsio.com \
--cc=davem@davemloft.net \
--cc=david.m.ertman@intel.com \
--cc=galpress@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=kiran.patil@intel.com \
--cc=leonro@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=mkalderon@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=parav@mellanox.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sassmann@redhat.com \
--cc=selvin.xavier@broadcom.com \
--cc=sriharsha.basavapatna@broadcom.com \
--cc=xavier.huwei@huawei.com \
--cc=yishaih@mellanox.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 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.