[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4jP9nFAGdvB7agg3x7Y7moHGcxLd5=f5=5CXnJRUf3n9w@mail.gmail.com>
Date: Wed, 4 Nov 2020 15:21:23 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: gregkh <gregkh@...uxfoundation.org>
Cc: Leon Romanovsky <leon@...nel.org>,
Doug Ledford <dledford@...hat.com>,
Leon Romanovsky <leonro@...dia.com>,
Jakub Kicinski <kuba@...nel.org>,
Jason Wang <jasowang@...hat.com>,
linux-rdma <linux-rdma@...r.kernel.org>,
"Michael S. Tsirkin" <mst@...hat.com>,
Netdev <netdev@...r.kernel.org>, Parav Pandit <parav@...dia.com>,
Roi Dayan <roid@...dia.com>,
Saeed Mahameed <saeedm@...dia.com>,
virtualization@...ts.linux-foundation.org,
alsa-devel@...a-project.org, Takashi Iwai <tiwai@...e.de>,
Mark Brown <broonie@...nel.org>,
"David S . Miller" <davem@...emloft.net>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Fred Oh <fred.oh@...ux.intel.com>,
"Saleem, Shiraz" <shiraz.saleem@...el.com>,
"Patil, Kiran" <kiran.patil@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David M Ertman <david.m.ertman@...el.com>,
Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to
auxiliary bus
On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe <jgg@...pe.ca> wrote:
[..]
> > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > +
> > +static struct auxiliary_driver mlx5v_driver = {
> > + .name = "vnet",
> > + .probe = mlx5v_probe,
> > + .remove = mlx5v_remove,
> > + .id_table = mlx5v_id_table,
> > +};
>
> It is hard to see from the diff, but when this patch is applied the
> vdpa module looks like I imagined things would look with the auxiliary
> bus. It is very similar in structure to a PCI driver with the probe()
> function cleanly registering with its subsystem. This is what I'd like
> to see from the new Intel RDMA driver.
>
> Greg, I think this patch is the best clean usage example.
>
> I've looked over this series and it has the right idea and
> parts. There is definitely more that can be done to improve mlx5 in
> this area, but this series is well scoped and cleans a good part of
> it.
Greg?
I know you alluded to going your own way if the auxiliary bus patches
did not shape up soon, but it seems they have and the stakeholders
have reached this consensus point.
Were there any additional changes you wanted to see happen? I'll go
give the final set another once over, but David has been diligently
fixing up all the declared major issues so I expect to find at most
minor incremental fixups.
Powered by blists - more mailing lists