[BUG] tas2781: V1 CRC error on Lenovo 16IRP8 (83C0) — calibration data valid, CRC field never populated

Swac <[email protected]>
Newsgroups org.alsa-project.alsa-devel
Message-ID <6eBGKHDUJnThj09kdjSKBK9773Pa4XZzsT6YNba7mX73uKQ1UpEDrGf3NdZn-Re-92ilEQD0H7Adh0aeE7g-f3_ZzQfzwd06W8s1BGdg2ik=@proton.me>
Hardware: Lenovo Slim Pro 9i; 16IRP8 (DMI 83C0)
Kernel: 7.1.8-arch1
Chip: TAS2781, 4 devices, i2c

dmesg (before fix):
tas2781-hda i2c-TIAS2781:00: tas2781_apply_calib: V1 CRC error

The CALI_DATA UEFI variable (GUID 1f52d2a1-bb3a-457d-bc09-43a3f4310a92) contains valid, correctly-structured calibration data (4 devices x 20 bytes + 4-byte timestamp), used successfully by the Windows driver on the same hardware. The CRC field at offset 84-87, however, was left as 0x00000000 rather than being populated by whatever factory tool wrote this variable.

tas2781_apply_calib() treats this the same as a genuine CRC mismatch and refuses to apply calibration.

Manually computing crc32() over bytes 0-83 and writing the result (0x6519f15e) into the CRC field resolves the issue with zero other changes — full before/after hex dumps and diff attached, showing exactly one 4-byte field changed.

diff before.txt after.txt
6c6
< 00000050: 0000 2030 0000 0000 0000 0000 0000 0000 .. 0............
---> 00000050: 0000 2030 0000 0000 5ef1 1965 0000 0000 .. 0....^..e....

After the patch, calibration applies successfully, and speaker output quality now matches Windows.

Suggest distinguishing "CRC field unset (0x00000000)" from a genuine mismatch on populated data — the former looks like a factory provisioning gap rather than actual corruption, and currently both are treated identically as fatal.

Please CC me on replies; I'm not subscribed.
after.txt (text/plain, 600 B)
00000000: 0700 0000 81d5 6720 3377 991f 24ad c318  ......g 3w..$...
00000010: c928 c600 0000 2030 45b6 b621 a096 5f1e  .(.... 0E..!.._.
00000020: 1197 c319 19f0 bf00 0000 2030 168e 1021  .......... 0...!
00000030: 9b38 f81e ea9c 4419 0c2a c800 0000 2030  .8....D..*.... 0
00000040: 41da e322 826e 591d c3b8 a91a f841 c300  A..".nY......A..
00000050: 0000 2030 0000 0000 5ef1 1965 0000 0000  .. 0....^..e....
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000                                ....
before.txt (text/plain, 600 B)
00000000: 0700 0000 81d5 6720 3377 991f 24ad c318  ......g 3w..$...
00000010: c928 c600 0000 2030 45b6 b621 a096 5f1e  .(.... 0E..!.._.
00000020: 1197 c319 19f0 bf00 0000 2030 168e 1021  .......... 0...!
00000030: 9b38 f81e ea9c 4419 0c2a c800 0000 2030  .8....D..*.... 0
00000040: 41da e322 826e 591d c3b8 a91a f841 c300  A..".nY......A..
00000050: 0000 2030 0000 0000 0000 0000 0000 0000  .. 0............
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000                                ....
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.