On Wed, Mar 04, 2020 at 11:17:41AM -0600, Pierre-Louis Bossart wrote: > > That's not the question I asked - have these platforms ever worked with > > older kernel versions? > Yes in that digital microphones have been enabled for a very long time (5.2 > if I am not mistaken). > No in that the automatic selection of the SOF driver was only enabled for > v5.5. In other words before 5.5 the user or distro needed to blacklist the > legacy snd-hda-intel HDAudio driver to get DMICs to work. Ugh, so it is actually fixing a regression since older releases would have been using snd-hda-audio? > This patch also removes the need for userspace configuration, pulseaudio now > directly receives the information on the number of microphones. It was > provided days after the merge window was opened, but the intent was that > v5.5 was the first release where users don't need to muck with configuration > files. If you're sending patches after the merge window has opened you've obviously missed the boat, things need to be in -next before the merge window. If that's a problem for your schedules that's unfortunate for you but not really relevant upstream, you need to ensure that people know that getting features depends on upstream review which definitely isn't going to happen if you don't post the patches before the merge window. If things are important you should ensure they're out there well before the merge window in case there's any issues with review or the merge window opens sooner than expected for some reason. > > It's partly the principle of the thing, if it were just patches that > > had individually been identified as being good for stable by someone > > with some understanding of the code (like this one :/ ) that were being > > backported I'd be a lot less concerned but the automated selections are > > missing dependencies or other context and people are reporting problems > > with them so I'm inclined to push back on things. > You are correct that the process can appear confusing, mainly since the > initial patch was contributed after the merge window on November 26. I'm sorry but I'm unclear what process confusion you're referring to? > Looking back at the emails, I didn't see any objections but somehow the > patch never landed in 5.5 updates. Jaroslav's intentions and work are not > without merit, we really appreciate his ucm2 work, and I support this > integration on v5.5-y to make the life of downstream distros simpler. If something is a fix you need to clearly identify it as a fix when you submit it upstream. This thread is the first suggestion I've seen that this is any kind of bug fix. There's no Fixes tag and the patch description itself sounds like it's adding a new feature to enable new functionality in userspace (autodetection by UCM) and it was posted as part of a series "ASoC: SOF: initial cleanup for DT and multi-client support" which again doesn't give any indication that this might be supposed to be a bug fix. It looks perfectly fine as a new feature so of course there were no objections. > Would it help if we provide a Tested-by tag with 5.5-y + this patch applied? It won't hurt but that's not really the point here. Lots of new features don't actually break things if they're backported.
Attachment:
signature.asc
Description: PGP signature
