[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM6PR11MB2841D0D8CA291D94EFA4B701DD0A0@DM6PR11MB2841.namprd11.prod.outlook.com>
Date: Wed, 7 Oct 2020 20:18:47 +0000
From: "Ertman, David M" <david.m.ertman@...el.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
"Leon Romanovsky" <leon@...nel.org>
CC: "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
"parav@...lanox.com" <parav@...lanox.com>,
"tiwai@...e.de" <tiwai@...e.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ranjani.sridharan@...ux.intel.com"
<ranjani.sridharan@...ux.intel.com>,
"fred.oh@...ux.intel.com" <fred.oh@...ux.intel.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"dledford@...hat.com" <dledford@...hat.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"jgg@...dia.com" <jgg@...dia.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"kuba@...nel.org" <kuba@...nel.org>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"Saleem, Shiraz" <shiraz.saleem@...el.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"Patil, Kiran" <kiran.patil@...el.com>
Subject: RE: [PATCH v2 1/6] Add ancillary bus support
> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
> Sent: Tuesday, October 6, 2020 8:18 AM
> To: Leon Romanovsky <leon@...nel.org>; Ertman, David M
> <david.m.ertman@...el.com>
> Cc: alsa-devel@...a-project.org; parav@...lanox.com; tiwai@...e.de;
> netdev@...r.kernel.org; ranjani.sridharan@...ux.intel.com;
> fred.oh@...ux.intel.com; linux-rdma@...r.kernel.org;
> dledford@...hat.com; broonie@...nel.org; jgg@...dia.com;
> gregkh@...uxfoundation.org; kuba@...nel.org; Williams, Dan J
> <dan.j.williams@...el.com>; Saleem, Shiraz <shiraz.saleem@...el.com>;
> davem@...emloft.net; Patil, Kiran <kiran.patil@...el.com>
> Subject: Re: [PATCH v2 1/6] Add ancillary bus support
>
> Thanks for the review Leon.
>
> >> Add support for the Ancillary Bus, ancillary_device and ancillary_driver.
> >> It enables drivers to create an ancillary_device and bind an
> >> ancillary_driver to it.
> >
> > I was under impression that this name is going to be changed.
>
> It's part of the opens stated in the cover letter.
>
> [...]
>
> >> + const struct my_driver my_drv = {
> >> + .ancillary_drv = {
> >> + .driver = {
> >> + .name = "myancillarydrv",
> >
> > Why do we need to give control over driver name to the driver authors?
> > It can be problematic if author puts name that already exists.
>
> Good point. When I used the ancillary_devices for my own SoundWire test,
> the driver name didn't seem specifically meaningful but needed to be set
> to something, what mattered was the id_table. Just thinking aloud, maybe
> we can add prefixing with KMOD_BUILD, as we've done already to avoid
> collisions between device names?
>
> [...]
Since we have eliminated all IDA type things out of the bus infrastructure,
I like the idea of prefixing the driver name with KBUILD_MODNAME through
a macro front. Since a parent driver can register more than one ancillary driver,
this allow the parent to have an internally meaningful name while still ensuring
its uniqueness.
-DaveE
Powered by blists - more mailing lists