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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aaa3f184-bcd5-70fd-b8fa-e6e361253ede@linux.intel.com>
Date:   Fri, 12 Apr 2019 09:17:35 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        alsa-devel@...a-project.org
Cc:     linux-kernel@...r.kernel.org, tiwai@...e.de, broonie@...nel.org,
        vkoul@...nel.org, gregkh@...uxfoundation.org,
        liam.r.girdwood@...ux.intel.com, jank@...ence.com, joe@...ches.com
Subject: Re: [alsa-devel] [PATCH 0/2] soundwire: fix Kconfig select/depend
 issues



On 4/12/19 5:06 AM, Srinivas Kandagatla wrote:
> 
> 
> On 11/04/2019 20:28, Pierre-Louis Bossart wrote:
>> 0-day/Kbuild starts complaining about missed module dependencies and
>> compilation issues. Since codecs and soc drivers need to be compilable
>> independently, let's fix this using the following model:
>>
>> SOUNDWIRE_INTEL ---- select -----------
>>                                        |
>>                       v
>> REGMAP_SOUNDWIRE --- select ---> SOUNDWIRE_BUS
>>
> 
> Last time when I looked at this, Kconfig symbols SOUNDWIRE_BUS and 
> SOUNDWIRE looked totally redundant and bit over done.
> 
> Removing SOUNDWIRE_BUS Kconfig did clean it up and made it bit more 
> align with others

Good point, but no. This is intentional and follows the Kconfig pattern 
pattern described by Takashi at https://lkml.org/lkml/2017/11/17/47

yes, this SOUNDWIRE is overkill for now, but let's assume there is a 
second non-intel implementation (which I understand as very likely given 
all the threads on ARM64 support). In that case you'd really want a 
top-level selector option that has no actual compilation impact - not 
used in any Makefile or code - but enables the sub-options and let 
users/distros select the platforms they care about.

SOUNDWIRE_BUS is really the lowest-common denominator that will be used 
by all drivers at the end.

> regarding REGMAP_SOUNDWIRE, It should be selected by the codec/soundwire 
> slave drivers isn't it?

yes, that was the intent.
Thanks
-Pierre

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ