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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 Jun 2020 08:54:11 -0500
From:   Pierre-Louis Bossart <>
To:     Mark Brown <>,
        John Stultz <>
Cc:     Takashi Iwai <>, Liam Girdwood <>,
        Linux Kernel Mailing List <>,
        Bard Liao <>,
        Guennadi Liakhovetski <>,
        Srini Kandagatla <>,
        Vinod Koul <>,
        Amit Pundir <>
Subject: Re: [GIT PULL] sound fixes for 5.8-rc1

On 6/12/20 7:19 AM, Mark Brown wrote:
> On Thu, Jun 11, 2020 at 05:49:29PM -0700, John Stultz wrote:
>> On Thu, Jun 11, 2020 at 5:13 PM John Stultz <> wrote:
>>>   I've bisected it down to the following commit from this pull req:
> For the benefit of readers that's "ASoC: soc-pcm: dpcm: fix
> playback/capture checks".
>> I don't know the backgroun again, but would something like the
>> following make sense?
> That's a small out of tree test patch which has no changelog so I'm not
> entirely clear what the intent or motivation is but it looks like the
> goal is to change so that we only warn when a link says it supports
> playback/capture but some of the DAIs lack the capability instead of
> returning an error.  I'm not sure I understand how that helps, it seems
> like the link is still misconfigured and we still have a warning which
> isn't great?  Surely the issue is that we've flagged the link as
> supporting capture when it doesn't?

Indeed the addition of stricter checks will expose cases where the links 
are not well configured, probably for years. The patch "ASoC: soc-pcm: 
dpcm: fix playback/capture checks" did not add those checks, only fixed 
them for the multi-dai case.

I think that those configuration errors are the problem and should be 
fixed as a prerequisite to the removal of the duplication between 
dpcm_playback/dpcm_capture/playback_only/capture_only. it may be painful 
and generate noise for a while, but if we only throw a warning what are 
the odds all those configuration errors will eventually be fixed?

If we need more time for validation on all platforms, then maybe we can 
first relax the check for 5.8-rc1 as suggested by John, but re-add the 
-EINVAL on -next to give a target of 5.9 with all configurations fixed?

Powered by blists - more mailing lists