Hi Broislav and Andrew, I removed these exported function and submitted v3 PATCH.
Thanks, Troy Lee > -----Original Message----- > From: Borislav Petkov <[email protected]> > Sent: Thursday, December 3, 2020 2:24 AM > To: Andrew Jeffery <[email protected]> > Cc: Troy Lee <[email protected]>; Joel Stanley <[email protected]>; open > list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > <[email protected]>; Tony Luck <[email protected]>; Ryan Chen > <[email protected]>; James Morse <[email protected]>; > moderated list:ARM/ASPEED MACHINE SUPPORT > <[email protected]>; open list <[email protected]>; > Robert Richter <[email protected]>; [email protected]; Rob Herring > <[email protected]>; Stefan M Schaeckeler <[email protected]>; Mauro > Carvalho Chehab <[email protected]>; moderated list:ARM/ASPEED > MACHINE SUPPORT <[email protected]>; open > list:EDAC-CORE <[email protected]> > Subject: Re: [PATCH v2 3/3] edac: Supporting AST2400 and AST2600 edac > driver > > On Thu, Dec 03, 2020 at 01:32:44AM +1030, Andrew Jeffery wrote: > > On Wed, 2 Dec 2020, at 19:11, Troy Lee wrote: > > > Hi Joel, > > > > > > Thanks for the suggestion, I'll fix the review and create an new > > > patch against latest Linux branch. Those exported function will be > > > referenced in other driver yet to be upstream, so should I move > > > those exported functions out of this patch? > > > > > > > Yes, let's leave the exports out of this patch, and add them in when > > you send the patch that depends on them. > > And when you do, almost all new exports are EXPORT_SYMBOL_GPL - not > EXPORT_SYMBOL. > > Also, I'd like to see how those exports are going to be used. An EDAC driver > function exported to another driver sounds strange. We have only one other > case like this in the EDAC tree: > > drivers/edac/amd64_edac.c:554:EXPORT_SYMBOL_GPL(amd64_get_dram_hol > e_info); > > and even that is not really needed... > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
