From: Xinxin Wan xinxin.wan@intel.com
[ Upstream commit 19f971057b2d7b99c80530ec1052b45de236a8da ]
To be more resilient to codec-detection failures when the hardware powers on slowly, add retry mechanism to the device verification check. Similar pattern is found throughout a number of Realtek codecs. Our tests show that 60ms delay is sufficient to address readiness issues on rt5640 chip.
Reviewed-by: Amadeusz Sławiński amadeuszx.slawinski@linux.intel.com Reviewed-by: Cezary Rojewski cezary.rojewski@intel.com Signed-off-by: Xinxin Wan xinxin.wan@intel.com Signed-off-by: Cezary Rojewski cezary.rojewski@intel.com Link: https://patch.msgid.link/20250530142120.2944095-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my detailed analysis:
## Analysis of the Commit
### 1. Bug Fix Nature This commit fixes a real-world hardware detection issue where the RT5640 codec device ID verification fails on systems where the hardware powers on slowly. The failure results in the driver returning `-ENODEV` and the audio codec not being initialized, causing complete audio failure.
### 2. Small and Contained Change The fix is minimal and highly contained: - Only adds 3 lines of code - The change is isolated to the probe function's device ID verification logic - No architectural changes or new features introduced - The retry logic is simple: if initial ID read doesn't match, wait 60-100ms and retry once
### 3. Clear Purpose with No Major Side Effects The code change: ```c regmap_read(rt5640->regmap, RT5640_VENDOR_ID2, &val); +if (val != RT5640_DEVICE_ID) { + usleep_range(60000, 100000); + regmap_read(rt5640->regmap, RT5640_VENDOR_ID2, &val); +} ``` - Only adds a single retry with delay if the first read fails - The delay (60-100ms) is reasonable for probe-time initialization - No impact on normal operation when hardware is ready
### 4. Follows Established Pattern The commit message mentions "Similar pattern is found throughout a number of Realtek codecs," and the probe function already contains a 400ms delay after enabling LDO1 (line 3004), showing that power-on delays are expected for this hardware.
### 5. Minimal Risk of Regression - The retry only occurs when device ID verification would have failed anyway - In the worst case, it adds a 60-100ms delay to failed probe attempts - Systems where the codec is ready immediately continue to work without delay - The pattern is conservative: only one retry attempt
### 6. Important User Impact Without this fix, affected systems experience: - Complete audio failure on boot - No audio codec detection - Requires manual intervention or multiple reboots to get audio working
### 7. Stable Tree Suitability This fix meets all stable kernel criteria: - Fixes a real bug affecting users - Minimal change with clear purpose - No new features or APIs - Low risk of introducing new issues - Self-contained within a single driver
The commit represents a classic hardware quirk fix that improves reliability without adding complexity, making it an ideal candidate for stable backport.
sound/soc/codecs/rt5640.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 37ea4d854cb5..3185bf13dc42 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -3026,6 +3026,11 @@ static int rt5640_i2c_probe(struct i2c_client *i2c) }
regmap_read(rt5640->regmap, RT5640_VENDOR_ID2, &val); + if (val != RT5640_DEVICE_ID) { + usleep_range(60000, 100000); + regmap_read(rt5640->regmap, RT5640_VENDOR_ID2, &val); + } + if (val != RT5640_DEVICE_ID) { dev_err(&i2c->dev, "Device with ID register %#x is not rt5640/39\n", val);