Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, broonie@kernel.org
Subject: Re: [alsa-devel] [PATCH] ASoC: SOF: Intel: add PCI ID for CometLake-S
Date: Wed, 18 Dec 2019 10:42:24 -0600	[thread overview]
Message-ID: <a90e86ce-b468-28b2-f0a8-30f66429d921@linux.intel.com> (raw)
In-Reply-To: <s5hbls57g43.wl-tiwai@suse.de>



On 12/18/19 10:28 AM, Takashi Iwai wrote:
> On Wed, 18 Dec 2019 16:21:22 +0100,
> Pierre-Louis Bossart wrote:
>>
>>>>> Also, can we reduce even the ifdef around sof_dev_desc definitions by
>>>>> __maybe_unused atttribute?
>>>>
>>>> Sorry, I am not following your suggestion. I would really like to keep
>>>> the ifdefs for now, and while it can be seen as overkill to have
>>>> descriptors that are identical in some cases the past experience shows
>>>> it's useful when we have to add quirks for specific 'hardware
>>>> recommended programming sequences'.
>>>
>>> What I suggested was simple, just dropping ifdef by something like
>>>
>>> diff --git a/sound/soc/sof/sof-pci-dev.c b/sound/soc/sof/sof-pci-dev.c
>>> index bbeffd932de7..297632a54f1b 100644
>>> --- a/sound/soc/sof/sof-pci-dev.c
>>> +++ b/sound/soc/sof/sof-pci-dev.c
>>> @@ -36,8 +36,7 @@ MODULE_PARM_DESC(sof_pci_debug, "SOF PCI debug options (0x0 all off)");
>>>      #define SOF_PCI_DISABLE_PM_RUNTIME BIT(0)
>>>    -#if IS_ENABLED(CONFIG_SND_SOC_SOF_APOLLOLAKE)
>>> -static const struct sof_dev_desc bxt_desc = {
>>> +static const struct sof_dev_desc __maybe_unused bxt_desc = {
>>>    	.machines		= snd_soc_acpi_intel_bxt_machines,
>>>    	.resindex_lpe_base	= 0,
>>>    	.resindex_pcicfg_base	= -1,
>>> @@ -52,10 +51,8 @@ static const struct sof_dev_desc bxt_desc = {
>>>    	.ops = &sof_apl_ops,
>>>    	.arch_ops = &sof_xtensa_arch_ops
>>>    };
>>> -#endif
>>>    -#if IS_ENABLED(CONFIG_SND_SOC_SOF_GEMINILAKE)
>>> -static const struct sof_dev_desc glk_desc = {
>>> +static const struct sof_dev_desc __maybe_unused glk_desc = {
>>>    	.machines		= snd_soc_acpi_intel_glk_machines,
>>>    	.resindex_lpe_base	= 0,
>>>    	.resindex_pcicfg_base	= -1,
>>> @@ -70,10 +67,8 @@ static const struct sof_dev_desc glk_desc = {
>>>    	.ops = &sof_apl_ops,
>>>    	.arch_ops = &sof_xtensa_arch_ops
>>>    };
>>> -#endif
>>> .....
>>>    
>>>
>>> Then the issue I pointed above can be solved as well.
>>
>> The ifdefs are still needed in the PCI IDs tables
> 
> Yes, but it halves the messes :)

I wish it was true :-)

In reality having buildbots play with kconfig options does help identify 
issues at the code level, just like the namespace use helped identify 
the .arch_ops just above did not belong here.
I find it's a constant battle to avoid accumulated crud in the wrong 
places when dealing with multiple platforms, and when looking at patches 
it's very hard (at least for me) to realize where the code gets added 
and the implications.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-12-18 18:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 14:14 [alsa-devel] [PATCH] ASoC: SOF: Intel: add PCI ID for CometLake-S Pierre-Louis Bossart
2019-11-26 14:23 ` Takashi Iwai
2019-12-18  0:50   ` Pierre-Louis Bossart
2019-12-18  6:32     ` Takashi Iwai
2019-12-18 15:21       ` Pierre-Louis Bossart
2019-12-18 16:28         ` Takashi Iwai
2019-12-18 16:42           ` Pierre-Louis Bossart [this message]
2019-12-18 18:45             ` Takashi Iwai
2019-12-18 19:01               ` Pierre-Louis Bossart
2019-12-18 20:02                 ` Takashi Iwai
2019-12-18 20:07                   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a90e86ce-b468-28b2-f0a8-30f66429d921@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox