> -----Original Message----- > From: Dan Williams <[email protected]> > Sent: Thursday, November 5, 2020 2:00 PM > To: Ertman, David M <[email protected]> > Cc: [email protected]; Takashi Iwai <[email protected]>; Mark Brown > <[email protected]>; linux-rdma <[email protected]>; Jason > Gunthorpe <[email protected]>; Doug Ledford <[email protected]>; > Netdev <[email protected]>; David Miller <[email protected]>; > Jakub Kicinski <[email protected]>; Greg KH <[email protected]>; > Ranjani Sridharan <[email protected]>; Pierre-Louis Bossart > <[email protected]>; Fred Oh <[email protected]>; > Parav Pandit <[email protected]>; Saleem, Shiraz > <[email protected]>; Patil, Kiran <[email protected]>; Linux > Kernel Mailing List <[email protected]>; Leon Romanovsky > <[email protected]> > Subject: Re: [PATCH v3 01/10] Add auxiliary bus support > > On Thu, Nov 5, 2020 at 11:28 AM Ertman, David M > <[email protected]> wrote: > [..] > > > > Each auxiliary_device represents a part of its parent > > > > +functionality. The generic behavior can be extended and specialized as > > > needed > > > > +by encapsulating an auxiliary_device within other domain-specific > > > structures and > > > > +the use of .ops callbacks. Devices on the auxiliary bus do not share > > > > any > > > > +structures and the use of a communication channel with the parent is > > > > +domain-specific. > > > > > > Should there be any guidance here on when to use ops and when to just > > > export functions from parent driver to child. EXPORT_SYMBOL_NS() > seems > > > a perfect fit for publishing shared routines between parent and child. > > > > > > > I would leave this up the driver writers to determine what is best for them. > > I think there is a pathological case that can be avoided with a > statement like the following: > > "Note that ops are intended as a way to augment instance behavior > within a class of auxiliary devices, it is not the mechanism for > exporting common infrastructure from the parent. Consider > EXPORT_SYMBOL_NS() to convey infrastructure from the parent module to > the auxiliary module(s)." > > As for your other dispositions of the feedback, looks good to me.
I will add this in. -DaveE
