Re: 5.5.y - apply "ASoC: intel/skl/hda - export number of digital microphones via control components"

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]