Re: 5.5.6 regression (stuck at boot) on devices using the sof_hda audio driver + fix

Greg KH
2020-02-28T07:13:46Z

On Thu, Feb 27, 2020 at 08:39:04PM +0100, Hans de Goede wrote:
> Hi All,
>
> I and various other Fedora users have noticed that Fedora's 5.5.6 build gets stuck
> at boot on a Lenovo X1 7th gen, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1772498
>
> This is caused by the addition of this commit to 5.5.6:
>
> 24c259557c45 ("ASoC: SOF: Intel: hda: Fix SKL dai count")
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.5.y&id=24c259557c45e817941d3843f82331a477c86a7e
>
> ###
> ASoC: SOF: Intel: hda: Fix SKL dai count
> [ Upstream commit a6947c9d86bcfd61b758b5693eba58defe7fd2ae ]
>
> With fourth pin added for iDisp for skl_dai, update SOF_SKL_DAI_NUM to
> account for the change. Without this, dais from the bottom of the list
> are skipped. In current state that's the case for 'Alt Analog CPU DAI'.
>
> Fixes: ac42b142cd76 ("ASoC: SOF: Intel: hda: Add iDisp4 DAI")
> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> Link: https://lore.kernel.org/r/20200113114054.9716-1-cezary.rojewski@intel.com
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ###
>
> Notice the "Fixes: ac42b142cd76 (...)", that commit-id actually
> does not exist, the correct commit-id which this fixes is:
>
> e68d6696575e ("ASoC: SOF: Intel: hda: Add iDisp4 DAI")
> and that commit is not in 5.5.6, which is causing the problem,
> the missing commit makes an array one larger and the fix for the
> missing fix which did end up in 5.5.6 and bumps a define which is
> used to walk over the array in some places by one so now the
> walking is going over the array boundary.
>
> For the Fedora kernels I've fixed this by adding the
> "ASoC: SOF: Intel: hda: Add iDisp4 DAI" commit as a downstream
> patch for our kernels. I believe that this is probably the best
> fix for 5.5.z too.

I've done that now too, thanks for catching this.

> p.s.
>
> I know that the stable series are partly based on automatically
> picking patches now. I wonder if the scripts doing that could be
> made smarter wrt rejecting patches with a Fixes tag where the
> fixed patch is not present, so where in essence a pre-requisite
> of the patch being added is missing ?

Looks like Sasaha's scripts has a bug in it :(