FAILED: patch "[PATCH] ALSA: hda/tas2781: Accept V1 calibration data without CRC" failed to apply to 6.6-stable tree

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x 408249089c48df1a4d23f60b831be3f3c311e6d1
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026101238-chrome-recount-a048@gregkh' --subject-prefix 'PATCH 6.6.y' 'HEAD^..'

Possible dependencies:

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 408249089c48df1a4d23f60b831be3f3c311e6d1 Mon Sep 17 00:00:00 2001
From: Mohamed Yassine Jebabli <[email protected]>
Date: Thu, 1 Oct 2026 12:24:42 +0200
Subject: [PATCH] ALSA: hda/tas2781: Accept V1 calibration data without CRC

Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H, SSID 17aa:38cd) store valid V1 calibration data in the CALI_DATA EFI variable but leave the TimeStamp and CRC fields zeroed. The driver rejects such data, so the amplifiers always run with default parameters on these machines.

The rejection was silent until
commit 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") turned it into "V1 CRC error".

The stored values are consistent (R0 = 3.82/3.83 ohm, 1/R0 matching within 1e-4), so accept V1 data when both TimeStamp and CRC are zero and the first device entry is non-zero, and emit a warning.

index b22f93424c62..e0da299df780 100644
@@ -139,9 +139,21 @@ static void tas2781_apply_calib(struct tasdevice_priv *p)
 		 */
 		crc = crc32(~0, data, 84) ^ ~0;
 		if (crc != tmp_val[21]) {
-			cali_data->total_sz = 0;
-			dev_err(p->dev, "%s: V1 CRC error\n", __func__);
-			return;
+			/*
+			 * Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H,
+			 * SSID 17aa:38cd) store valid V1 calibration data
+			 * but leave TimeStamp and CRC zeroed.
+			 */
+			if (!tmp_val[20] && !tmp_val[21] &&
+			    tmp_val[0] && tmp_val[1]) {
+				dev_warn(p->dev,
+					 "%s: V1 data without CRC, accepting\n",
+					 __func__);
+			} else {
+				cali_data->total_sz = 0;
+				dev_err(p->dev, "%s: V1 CRC error\n", __func__);
+				return;
+			}
 		}
 
 		for (j = p->ndev - 1; j >= 0; j--) {

From: Mohamed Yassine Jebabli <[email protected]>

[ Upstream commit 408249089c48df1a4d23f60b831be3f3c311e6d1 ]

Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H, SSID 17aa:38cd) store valid V1 calibration data in the CALI_DATA EFI variable but leave the TimeStamp and CRC fields zeroed. The driver rejects such data, so the amplifiers always run with default parameters on these machines.

The rejection was silent until
commit 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") turned it into "V1 CRC error".

The stored values are consistent (R0 = 3.82/3.83 ohm, 1/R0 matching within 1e-4), so accept V1 data when both TimeStamp and CRC are zero and the first device entry is non-zero, and emit a warning.

---
 sound/pci/hda/tas2781_hda_i2c.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

index 980e6104c2f3f..01765a6a00f2c 100644
@@ -479,7 +479,17 @@ static int tas2781_save_calibration(struct tasdevice_priv *tas_priv)
 	dev_dbg(tas_priv->dev, "cali crc 0x%08x PK tmp_val 0x%08x\n",
 		crc, tmp_val[21]);
 
-	if (crc == tmp_val[21]) {
+	/*
+	 * Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H,
+	 * SSID 17aa:38cd) store valid V1 calibration data
+	 * but leave TimeStamp and CRC zeroed.
+	 */
+	if (crc == tmp_val[21] ||
+	    (!tmp_val[20] && !tmp_val[21] && tmp_val[0] && tmp_val[1])) {
+		if (crc != tmp_val[21])
+			dev_warn(tas_priv->dev,
+				 "%s: V1 data without CRC, accepting\n",
+				 __func__);
 		time64_to_tm(tmp_val[20], 0, tm);
 		dev_dbg(tas_priv->dev, "%4ld-%2d-%2d, %2d:%2d:%2d\n",
 			tm->tm_year, tm->tm_mon, tm->tm_mday,

2.53.0