> -----Original Message----- > From: Pierre-Louis Bossart <[email protected]> > Sent: Tuesday, October 6, 2020 8:18 AM > To: Leon Romanovsky <[email protected]>; Ertman, David M > <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Williams, Dan J > <[email protected]>; Saleem, Shiraz <[email protected]>; > [email protected]; Patil, Kiran <[email protected]> > 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
