+Kai
-----Original Message----- From: Hans de Goede hdegoede@redhat.com Sent: Thursday, February 27, 2020 11:39 AM To: stable@vger.kernel.org; Nujella, Sathyanarayana sathyanarayana.nujella@intel.com; Rojewski, Cezary cezary.rojewski@intel.com; Jaroslav Kysela perex@perex.cz Subject: 5.5.6 regression (stuck at boot) on devices using the sof_hda audio driver + fix
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=l... nux-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.
Regards,
Hans
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 ?