> Subject: Re: [PATCH v2 1/6] Add ancillary bus support
>
> On Tue, Oct 06, 2020 at 10:18:07AM -0500, Pierre-Louis Bossart wrote:
> > 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.
>
> ok, so what are the variants?
> system bus (sysbus), sbsystem bus (subbus), crossbus ?
>
> >
> > [...]
> >
> > > > + 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?
>
> IMHO, it shouldn't be controlled by the drivers at all and need to have kernel
> module name hardwired. Users will use it later for various bind/unbind/autoprobe
> tricks and it will give predictability for them.
>
+1. This name is not used in the match. Having the bus hardwire the modname sounds like a good idea.
Shiraz
