[alsa-devel] [RFC PATCH 4/8] ASoC: Intel: move all ACPI match tables to common module

[Vinod Koul]

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