[PATCH] ALSA: hda: avoid write to STATESTS if controller is in reset

[PATCH] ALSA: hda: avoid write to STATESTS if controller is in reset

[Kai Vehmanen]

The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
before performing controller reset. This code dates back to an old
bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
codec probing robustness"). Originally the code was added to
azx_reset().

The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
into controller object") and ended up to snd_hdac_bus_reset_link() and
called primarily via snd_hdac_bus_init_chip().

The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
called when controller is not in reset. In this case, STATESTS can be
cleared. This can be useful e.g. when forcing a controller reset to retry
codec probe. A normal non-power-on reset will not clear the bits.

However, this old logic is problematic when controller is already in
reset. The HDA specification states that controller must be taken out of
reset before writing to registers other than GCTL.CRST (1.0a spec,
3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
if the controller is already in reset per the HDA specification mentioned.

This has been harmless on older hardware. On newer generation of Intel
PCIe based HDA controllers, if configured to report issues, this write
will emit an unsupported request error. If ACPI Platform Error Interface
(APEI) is enabled in kernel, this will end up to kernel log.

Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
the function is called when controller is not in reset. Otherwise
clearing the bits is not possible and should be skipped.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
---
 sound/hda/hdac_controller.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c
index 062da7a7a586..f7bd6e2db085 100644
--- a/sound/hda/hdac_controller.c
+++ b/sound/hda/hdac_controller.c
@@ -421,8 +421,9 @@ int snd_hdac_bus_reset_link(struct hdac_bus *bus, bool full_reset)
 	if (!full_reset)
 		goto skip_reset;
 
-	/* clear STATESTS */
-	snd_hdac_chip_writew(bus, STATESTS, STATESTS_INT_MASK);
+	/* clear STATESTS if not in reset */
+	if (snd_hdac_chip_readb(bus, GCTL) & AZX_GCTL_RESET)
+		snd_hdac_chip_writew(bus, STATESTS, STATESTS_INT_MASK);
 
 	/* reset controller */
 	snd_hdac_bus_enter_link_reset(bus);

base-commit: 0fc27129ed268b619135b99d365ce44daaf85602
-- 
2.33.0

Re: [PATCH] ALSA: hda: avoid write to STATESTS if controller is in reset

[Takashi Iwai]

On Tue, 12 Oct 2021 16:29:35 +0200,
Kai Vehmanen wrote:
> 
> The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
> before performing controller reset. This code dates back to an old
> bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
> codec probing robustness"). Originally the code was added to
> azx_reset().
> 
> The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
> into controller object") and ended up to snd_hdac_bus_reset_link() and
> called primarily via snd_hdac_bus_init_chip().
> 
> The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
> called when controller is not in reset. In this case, STATESTS can be
> cleared. This can be useful e.g. when forcing a controller reset to retry
> codec probe. A normal non-power-on reset will not clear the bits.
> 
> However, this old logic is problematic when controller is already in
> reset. The HDA specification states that controller must be taken out of
> reset before writing to registers other than GCTL.CRST (1.0a spec,
> 3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
> if the controller is already in reset per the HDA specification mentioned.
> 
> This has been harmless on older hardware. On newer generation of Intel
> PCIe based HDA controllers, if configured to report issues, this write
> will emit an unsupported request error. If ACPI Platform Error Interface
> (APEI) is enabled in kernel, this will end up to kernel log.
> 
> Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
> the function is called when controller is not in reset. Otherwise
> clearing the bits is not possible and should be skipped.
> 
> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Do we have a bug reference?  I guess it worth to be pushed to 5.15-rc
and Cc-to-stable, if this is hitting already on the recent machines.


thanks,

Takashi

Re: [PATCH] ALSA: hda: avoid write to STATESTS if controller is in reset

[Kai Vehmanen]

Hi,

On Tue, 12 Oct 2021, Takashi Iwai wrote:

> > The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
> > before performing controller reset. This code dates back to an old
> > bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
> > codec probing robustness"). Originally the code was added to
> > azx_reset().
[...]
> Do we have a bug reference?  I guess it worth to be pushed to 5.15-rc
> and Cc-to-stable, if this is hitting already on the recent machines.

I unfortunately don't have a public bug reference to share. This will 
impact PCIe based Intel hardware like DG1. The DRM support is quite 
recent for these, so in practise this only affects 5.15-rc and newer.

And even on these, the functionality will be ok, it's just the warnings 
that fill the kernel log that are a problem.

Br, Kai

Re: [PATCH] ALSA: hda: avoid write to STATESTS if controller is in reset

[Takashi Iwai]

On Tue, 12 Oct 2021 17:48:12 +0200,
Kai Vehmanen wrote:
> 
> Hi,
> 
> On Tue, 12 Oct 2021, Takashi Iwai wrote:
> 
> > > The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
> > > before performing controller reset. This code dates back to an old
> > > bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
> > > codec probing robustness"). Originally the code was added to
> > > azx_reset().
> [...]
> > Do we have a bug reference?  I guess it worth to be pushed to 5.15-rc
> > and Cc-to-stable, if this is hitting already on the recent machines.
> 
> I unfortunately don't have a public bug reference to share. This will 
> impact PCIe based Intel hardware like DG1. The DRM support is quite 
> recent for these, so in practise this only affects 5.15-rc and newer.
> 
> And even on these, the functionality will be ok, it's just the warnings 
> that fill the kernel log that are a problem.

OK, then I'll push this without Cc to stable.


thanks,

Takashi