On Wed, Sep 27, 2017 at 12:06:35PM -0500, Pierre-Louis Bossart wrote: > On 9/27/17 4:45 AM, Vinod Koul wrote: > >On Tue, Sep 26, 2017 at 02:13:23PM -0500, Pierre-Louis Bossart wrote: > >>On 9/25/17 11:23 PM, Vinod Koul wrote: > >>>On Fri, Sep 08, 2017 at 03:56:58PM -0500, Pierre-Louis Bossart wrote: > >>>>+extern struct snd_soc_acpi_mach snd_soc_acpi_intel_haswell_machines[]; > >>>>+extern struct snd_soc_acpi_mach snd_soc_acpi_intel_broadwell_machines[]; > >>>>+extern struct snd_soc_acpi_mach snd_soc_acpi_intel_baytrail_legacy_machines[]; > >>>>+extern struct snd_soc_acpi_mach snd_soc_acpi_intel_baytrail_machines[]; > >>>>+extern struct snd_soc_acpi_mach snd_soc_acpi_intel_cherrytrail_machines[]; > >>> > >>>so the header is just for externs, not a pretty thing, can we avoid these > >>>somehow. Do they need to be in common file, why not keep then in respective > >>>byt/hsw file. > >> > >>Because they will be shared between drivers, that's the whole point. > >>I can't put a common table in either of sound/soc/sof or > >>sound/soc/intel/atom. I didn't find a better solution than a module with > >>just tables + matching functions in it. > > > >yes but shared between byt family or hsw family, maybe a common byt-tables.c > >hsw-tables.c and we can move skl ones out to skl-tables.c > > oh, if you are talking about splitting the tables in different files yes > this is no issue. I thought you objected to the declaration of the tables > themselves. Yes. I would like to avoid an endless file for externs. Let the respective platform build those into that driver -- ~Vinod _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
