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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 Jan 2021 21:31:40 +0100 From: Arnd Bergmann <arnd@...nel.org> To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com> Cc: Takashi Iwai <tiwai@...e.de>, ALSA Development Mailing List <alsa-devel@...a-project.org>, Kai Vehmanen <kai.vehmanen@...ux.intel.com>, Arnd Bergmann <arnd@...db.de>, "linux-kernel @ vger . kernel . org" <linux-kernel@...r.kernel.org>, Takashi Iwai <tiwai@...e.com>, YueHaibing <yuehaibing@...wei.com>, Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>, Mark Brown <broonie@...nel.org>, Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>, Daniel Baluta <daniel.baluta@....com>, sound-open-firmware@...a-project.org Subject: Re: [Sound-open-firmware] [PATCH] ASoC: SOF: Intel: avoid reverse module dependency On Tue, Jan 12, 2021 at 9:17 PM Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com> wrote: > > > >> Since this is going to be a really invasive change, and past > >> experience shows that mucking with Kconfigs will invariably raise a > >> number of broken corner cases, if there is support from > >> Mark/Takashi/Jaroslav on this idea, we should first test it in the SOF > >> tree so that we get a good test coverage and don't break too many eggs > >> in Mark's tree. We would also need to concurrently change our CI > >> scripts which are dependent on module names. > > > > I'm in favor of the way Arnd proposed. It's more straightforward and > > less code. > > Thanks Takashi for the feedback. > > Since yesterday I looked at another problem where we can have unmet > dependencies between SoundWire (m) and SOF (y), so we probably need to > rethink all this. We had similar issue with SOF and HDaudio before, it's > time to revisit all this. I think I ran into the same thing yesterday, and came up with a patch for that one as well. I think it should be independent of the other one but I did not try it by itself. I'll send it along with a fixed version of the one in this thread, together the have now survived a few hundred randconfig builds. Arnd
Powered by blists - more mailing lists