Messages in this thread | | | Date | Wed, 18 Sep 2019 15:53:02 +0200 | From | Greg KH <> | Subject | Re: [alsa-devel] [RFC PATCH 8/9] soundwire: intel: remove platform devices and provide new interface |
| |
On Wed, Sep 18, 2019 at 08:48:33AM -0500, Pierre-Louis Bossart wrote: > On 9/18/19 7:06 AM, Greg KH wrote: > > On Tue, Sep 17, 2019 at 09:29:52AM -0500, Pierre-Louis Bossart wrote: > > > On 9/17/19 12:55 AM, Greg KH wrote: > > > > On Mon, Sep 16, 2019 at 04:23:41PM -0500, Pierre-Louis Bossart wrote: > > > > > +/** > > > > > + * sdw_intel_probe() - SoundWire Intel probe routine > > > > > + * @parent_handle: ACPI parent handle > > > > > + * @res: resource data > > > > > + * > > > > > + * This creates SoundWire Master and Slave devices below the controller. > > > > > + * All the information necessary is stored in the context, and the res > > > > > + * argument pointer can be freed after this step. > > > > > + */ > > > > > +struct sdw_intel_ctx > > > > > +*sdw_intel_probe(struct sdw_intel_res *res) > > > > > +{ > > > > > + return sdw_intel_probe_controller(res); > > > > > +} > > > > > +EXPORT_SYMBOL(sdw_intel_probe); > > > > > + > > > > > +/** > > > > > + * sdw_intel_startup() - SoundWire Intel startup > > > > > + * @ctx: SoundWire context allocated in the probe > > > > > + * > > > > > + */ > > > > > +int sdw_intel_startup(struct sdw_intel_ctx *ctx) > > > > > +{ > > > > > + return sdw_intel_startup_controller(ctx); > > > > > +} > > > > > +EXPORT_SYMBOL(sdw_intel_startup); > > > > > > > > Why are you exporting these functions if no one calls them? > > > > > > They are used in the next series, see '[RFC PATCH 04/12] ASoC: SOF: Intel: > > > add SoundWire configuration interface' > > > > That wasn't obvious :) > > > > Also, why not EXPORT_SYMBOL_GPL()? :) > > Since the beginning of this SoundWire work, the intent what that the code > could be reused in non-GPL open-source circles, hence the dual license and > EXPORT_SYMBOL.
Hah, you _have_ talked to your lawyers about this, right?
You have a chance to do something like this for header files, for .c files, good luck. That's going to be a hard road to go down. Many have tried in the past, all but 1 have failed.
> That said, there are cases where the code only makes sense for Linux, or > relies on symbols that are exported with EXPORT_SYMBOL_GPL, in those cases > we rely on GPLv2 and EXPORT_SYMBOL_GPL. For this series I added a disclaimer > in the cover letter that those parts need to be reviewed further to make > sure there are no conflicts with GPL.
Please do that with your lawyers, do not require developers to do legal work for you, that's just mean :(
thanks,
greg k-h
| |