linux-kernel - Re: [alsa-devel] [GIT PULL] sound updates for 4.15-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <355efb61-f59d-05c3-3715-86e56df1ee7f@linux.intel.com>
Date:   Wed, 15 Nov 2017 10:19:09 -0600
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Vinod Koul <vinod.koul@...el.com>, Takashi Iwai <tiwai@...e.de>
Cc:     alsa-devel@...a-project.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [alsa-devel] [GIT PULL] sound updates for 4.15-rc1

On 11/15/17 9:24 AM, Vinod Koul wrote:
> On Wed, Nov 15, 2017 at 12:58:40PM +0100, Takashi Iwai wrote:
>> On Wed, 15 Nov 2017 12:37:42 +0100,
>> Mark Brown wrote:
>>>
>>> On Wed, Nov 15, 2017 at 08:34:09AM +0100, Takashi Iwai wrote:
>>>
>>>> And I believe there are a few more possible cleanups / fixes in the
>>>> messy Intel ASoC Kconfigs.  For example, SND_SOC_INTEL_SST is almost
>>>> always set.  The only exception is via SND_SST_ATOM_HIFI2_PLATFORM.
>>>> But all machine drivers using Atom Hifi2 do set SND_SST_IPC_ACPI,
>>>> which also requires SND_SOC_INTEL_SST.
>>>
>>> I'm not 100% convinced that the recent changes away from just having the
>>> only user selectable options be the board ones have really helped that
>>> much.
>>
>> Yeah, now it resulted in a mixture of selects and depends, which is a
>> bad sign.  I'm not against this kind of reorganization but we need to
>> sort out more.
>>
>>> Though transitioning back would probably just create more misery.
>>> It's a real shame that ACPI doesn't have standards for the machine
>>> descriptions here like DT does, it'd cut down on the amount of stuff
>>> that needs configuring.
>>
>> True.  Although I don't think ACPI is the center of the mess in this
>> case, but rather too many kconfigs is it.
>>
>> In soc/intel/*, we have the following entries:
>>
>> as non-selectable ones:
>> - SND_SST_IPC
>> - SND_SST_IPC_PCI
>> - SND_SST_IPC_ACPI
>> - SND_SOC_INTEL_COMMON
>> - SND_SOC_INTEL_SST
>> - SND_SOC_INTEL_SST_FIRMWARE
>> - SND_SOC_INTEL_SST_ACPI
>> - SND_SOC_ACPI_INTEL_MATCH
>>
>> and the selectable ones:
>> - SND_SOC_INTEL_SST_TOPLEVEL
>> - SND_SOC_INTEL_HASWELL
>> - SND_SOC_INTEL_BAYTRAIL
>> - SND_SST_ATOM_HIFI2_PLATFORM
>> - SND_SOC_INTEL_SKYLAKE
>>
>> And yet, there are tons of machine drivers as selectable kconfigs:
>> - SND_SOC_INTEL_MACH
> 
> this will be top level menu entry no select/default here as Takashi
> suggested.
> 
>> - SND_MFLD_MACHINE
> 
> this would be a lone ranger
> 
>> - SND_SOC_INTEL_HASWELL_MACH
>> - SND_SOC_INTEL_BDW_RT5677_MACH
>> - SND_SOC_INTEL_BROADWELL_MACH
> 
> we can bucket this in SND_SOC_INTEL_HSW_MACHS
> 
>> - SND_SOC_INTEL_BYT_MAX98090_MACH
>> - SND_SOC_INTEL_BYT_RT5640_MACH
> 
> SND_SOC_INTEL_LEGACY_BYT
> 
>> - SND_SOC_INTEL_BYTCR_RT5640_MACH
>> - SND_SOC_INTEL_BYTCR_RT5651_MACH
>> - SND_SOC_INTEL_CHT_BSW_RT5672_MACH
>> - SND_SOC_INTEL_CHT_BSW_RT5645_MACH
>> - SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
>> - SND_SOC_INTEL_BYT_CHT_DA7213_MACH
>> - SND_SOC_INTEL_BYT_CHT_ES8316_MACH
>> - SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH

this last one should not be enabled by default, it's for people who have 
a development platform with a connector (e.g. MinnowBoard), not for 
commercial products.

> 
> SND_SOC_INTEL_BYT_MACHS
> 
>> - SND_SOC_INTEL_SKL_RT286_MACH
>> - SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH
>> - SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH
>> - SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH
>> - SND_SOC_INTEL_BXT_RT298_MACH
>> - SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH
>> - SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH
> 
> SND_SOC_INTEL_SKL_MACHS
> 
> This set is growing and will keep growing. One machine is already posted and
> it's cousins should follow soon. I don't see a point in having options for
> these ad distro's would be enabling all of them and having all of them
> enabled works fine for me

I disagree. We should leave the ability to take out what you don't need.

The bucketization you are talking about is already implemented in 
practice, when you select the SOC options you have a set of machine 
drivers that show up in the menu options. It should be the distros' job 
to select which ones they want rather than us making decisions on their 
behalf. E.g. a Gallium distro running on Chromebooks should be able to 
select the relevant machine drivers and not the ones which will never be 
used.

> 
>> We should begin with thinking of which entries (and layer) to be
>> selectable, and which not.
> 
> Trickier part is non selectable ones, I am going to take a stab at them and
> see if we can merge few which can help is making lesser options and clean
> that part a bit, maybe a common SST_IPC symbol which adds IPC, MATCH etc.

I agree this is where things are complicated, but this is really for the 
Intel side of things and unrelated to machine driver options.