On Mon, 12 Oct 2020 10:26:17 +0200, Hans de Goede wrote: > > FWIW (since that this is already merged) I'm fine with removing the > quite old Bay Trail support from common/sst-acpi.c, at least Fedora > has been using the medium-old (with SOF being the new thing) > CONFIG_SND_SST_IPC_ACPI support for Bay Trail audio support for > quite some time now. The same for openSUSE. Since CONFIG_SND_SOC_INTEL_BAYTRAIL is exclusive against SOF and other modern codes, I guess it's quite unlikely that any recent distros enable it. > This is not just about Bay Trail And Cherry Trail devices though, > this series also makes changes impacting Haswell and Broadwell devices. > > The commit removing this support claims that at least for Haswell the > new sound/soc/intel/catpt replaces it, but I do not see that code in > 5.9, so that means that in one cycle we are both introducing the > replacement and dropping the old code ? I'm not sure if that is such > a great idea, what is the fallback plan if testing does find significant > issues with the new catpt code ? I find the action a bit too rushing, too. OTOH, the old code wasn't well maintained, honestly speaking. So, from another perspective, switching to a new code can be seen as a better chance to fix any bugs. Of course, we could keep two stuff parallel, but it's rather confusing. And, the HSW/BDW devices that need SST are quite rare and old, so the impact is limited, I guess. In anyway, let's cross fingers, and feed back to Cezary ASAP when we get a regression. thanks, Takashi
