From: Greg KH <gregkh@linuxfoundation.org>
To: "Ertman, David M" <david.m.ertman@intel.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"nhorman@redhat.com" <nhorman@redhat.com>,
"sassmann@redhat.com" <sassmann@redhat.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>,
"parav@mellanox.com" <parav@mellanox.com>,
"galpress@amazon.com" <galpress@amazon.com>,
"selvin.xavier@broadcom.com" <selvin.xavier@broadcom.com>,
"sriharsha.basavapatna@broadcom.com"
<sriharsha.basavapatna@broadcom.com>,
"benve@cisco.com" <benve@cisco.com>,
"bharat@chelsio.com" <bharat@chelsio.com>,
"xavier.huwei@huawei.com" <xavier.huwei@huawei.com>,
"yishaih@mellanox.com" <yishaih@mellanox.com>,
"leonro@mellanox.com" <leonro@mellanox.com>,
"mkalderon@marvell.com" <mkalderon@marvell.com>,
"aditr@vmware.com" <aditr@vmware.com>,
"ranjani.sridharan@linux.intel.com"
<ranjani.sridharan@linux.intel.com>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"Patil, Kiran" <kiran.patil@intel.com>,
"Bowers, AndrewX" <andrewx.bowers@intel.com>
Subject: Re: [net-next 1/9] Implementation of Virtual Bus
Date: Tue, 21 Apr 2020 08:52:23 +0200 [thread overview]
Message-ID: <20200421065223.GB347130@kroah.com> (raw)
In-Reply-To: <DM6PR11MB28418BEB2385E7E2929C2FF6DDD40@DM6PR11MB2841.namprd11.prod.outlook.com>
On Mon, Apr 20, 2020 at 10:59:12PM +0000, Ertman, David M wrote:
> > -----Original Message-----
> > From: Greg KH <gregkh@linuxfoundation.org>
> > Sent: Saturday, April 18, 2020 5:51 AM
> > To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> > Cc: davem@davemloft.net; Ertman, David M <david.m.ertman@intel.com>;
> > netdev@vger.kernel.org; linux-rdma@vger.kernel.org; nhorman@redhat.com;
> > sassmann@redhat.com; jgg@ziepe.ca; 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; Patil,
> > Kiran <kiran.patil@intel.com>; Bowers, AndrewX <andrewx.bowers@intel.com>
> > Subject: Re: [net-next 1/9] Implementation of Virtual Bus
> >
> > On Fri, Apr 17, 2020 at 10:10:26AM -0700, Jeff Kirsher wrote:
> > > @@ -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;
> >
> > struct device already has a name, why do you need another one?
>
> The name in dev is the base name appended with the id to make sure each device
> has unique name. The name in vdev is the abbreviated one (without the id) which
> will be used in the matching function, so that a driver can claim to support
> <name> and will be matched with all <name>.<id> devices for all id's.
>
> This is similar logic to platform_device's name field.
Don't treat platform_device as a good example of much :)
I still think this is duplicated stuff, but I'll let it go for now...
> > > + void (*release)(struct virtbus_device *);
> >
> > A bus should have the release function, not the actual device itself. A
> > device should not need function pointers.
> >
>
> The bus does have a release function, but it is a wrapper to call the release defined by
> the device.
odd. That is normally handled by the bus, not by the device itself.
> This is where the KO registering the virtbus_device is expected to clean up
> the resources allocated for this device (e.g. free memory, etc). Having the virtual_bus_release
> call a release callback in the virtual_device allows for extra cleanup from the originating KO
> if necessary.
>
> The memory model of virtual bus is for the originating KO to manage the lifespan of the
> memory for the virtual_device. The virtual_bus expects the KO defining the virtbus_device
> have the memory allocated before registering a virtbus_device and to clean up that memory
> when the release is called.
>
> The platform_device also has function pointers in it, by including a MFD object, but the
> platform_bus is managing the memory for the platform_bus_object that contains the
> platform_device which it why it using a generic kref_put to free memory.
Again, platform_devices are not good things to emulate, they have grown
into a total mess.
Ok, given that you are going to be putting lots of different things on
this "generic" type of bus, a release function for the device can make
sense. Still feels odd, I wonder if you should just do something with
the type of the device instead.
thanks,
greg k-h
next prev parent reply other threads:[~2020-04-21 6:52 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
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 [this message]
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=20200421065223.GB347130@kroah.com \
--to=gregkh@linuxfoundation.org \
--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=jeffrey.t.kirsher@intel.com \
--cc=jgg@ziepe.ca \
--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 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).