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

[Pierre-Louis Bossart]

On 9/27/17 12:31 PM, Vinod Koul wrote:
> 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

I don't get what you are suggesting and what an 'endless' file is.