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@xxxxxxxxx> > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > Link: https://lore.kernel.org/r/20200113114054.9716-1-cezary.rojewski@xxxxxxxxx > Signed-off-by: Mark Brown <broonie@xxxxxxxxxx> > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > ### > > 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 :(
