[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191112205958.GH5584@ziepe.ca>
Date: Tue, 12 Nov 2019 16:59:58 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc: davem@...emloft.net, gregkh@...uxfoundation.org,
Dave Ertman <david.m.ertman@...el.com>, netdev@...r.kernel.org,
linux-rdma@...r.kernel.org, nhorman@...hat.com,
sassmann@...hat.com, parav@...lanox.com,
Kiran Patil <kiran.patil@...el.com>
Subject: Re: [net-next 1/1] virtual-bus: Implementation of Virtual Bus
On Mon, Nov 11, 2019 at 11:22:19AM -0800, Jeff Kirsher wrote:
> From: Dave Ertman <david.m.ertman@...el.com>
>
> This is the initial implementation of the Virtual Bus,
> virtbus_device and virtbus_driver. The virtual bus is
> a software based bus intended to support lightweight
> devices and drivers and provide matching between them
> and probing of the registered drivers.
>
> Files added:
> drivers/bus/virtual_bus.c
> include/linux/virtual_bus.h
> Documentation/driver-api/virtual_bus.rst
>
> The primary purpose of the virual bus is to provide
> matching services and to pass the data pointer
> contained in the virtbus_device to the virtbus_driver
> during its probe call. This will allow two separate
> kernel objects to match up and start communication.
I think this is the 'multi_subsystem_device' idea I threw out in this
thread. ie pass an opaque void *pointer, done here by
virtbus_get_devdata():
https://lore.kernel.org/r/20191109084659.GB1289838@kroah.com
And Greg said 'Ick, no'..
So each driver should makes its own bus, and perhaps we should provide
some helper stuff for the repeating code, like PM function reflection?
Jason
Powered by blists - more mailing lists