linux-kernel - Re: [BUG] hda/tas2781: ASUS ROG Xbox Ally X audio issues with default firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <CAGwozwEJRDq96ZUQv+8H5fiXBVQ2jFvvuK48WpDqZ0eQ_NB+NA@mail.gmail.com>
Date: Fri, 2 Jan 2026 19:12:57 +0200
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Matthew Schwartz <matthew.schwartz@...ux.dev>
Cc: Baojun Xu <baojun.xu@...com>, Shenghao Ding <shenghao-ding@...com>,
 linux-sound@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, tiwai@...e.de
Subject: Re: [BUG] hda/tas2781: ASUS ROG Xbox Ally X audio issues with default
 firmware

On Tue, 30 Dec 2025 at 22:44, Matthew Schwartz
<matthew.schwartz@...ux.dev> wrote:
>
>
>
> > On Dec 8, 2025, at 8:00 PM, Matthew Schwartz <matthew.schwartz@...ux.dev> wrote:
> >
>- snip
> > 2.52.0
>
> After reading the TI E2E forums, it seems these calibration tuning configurations are only meant to be used during a calibration process.

A source would be good here, a link or two

> Instead, something else I found that works is not overriding the firmware file calibration data with the UEFI calibration data:

I did not look into the source code, do you have any reference in the
ACPI TAS code that r0_buf is prefilled with UEFI data?

It could be that there is a specific priority, where UEFI data is
supposed to be loaded after the firmware code, replacing the
calibration data from the file, or that is what is done in Windows.
But here it is done the other way. In that case, it might be more
appropriate to set a dummy var such as bool uefi_calib that becomes 1
when loading calibration from UEFI, and skip loading from the fw file
if available.

But links, etc. Here, this would affect all TAS devices too, so it is
more major.

Happy new year,
Antheas

> diff --git a/sound/soc/codecs/tas2781-fmwlib.c b/sound/soc/codecs/tas2781-fmwlib.c
> index 78fd0a5dc6f2..1e768e6187da 100644
> --- a/sound/soc/codecs/tas2781-fmwlib.c
> +++ b/sound/soc/codecs/tas2781-fmwlib.c
> @@ -2377,6 +2377,7 @@ static void tasdev_load_calibrated_data(struct tasdevice_priv *priv, int i)
>         unsigned char *data = cali_data->data;
>         struct tasdevice_calibration *cal;
>         int k = i * (cali_data->cali_dat_sz_per_dev + 1);
> +       unsigned char r0_buf[4];
>         int rc;
>
>         /* Load the calibrated data from cal bin file */
> @@ -2389,6 +2390,20 @@ static void tasdev_load_calibrated_data(struct tasdevice_priv *priv, int i)
>         }
>         if (!priv->is_user_space_calidata)
>                 return;
> +
> +       /*
> +        * Check if the DSP config already set the calibration registers.
> +        * Some tuning configs contain their own calibration data which should
> +        * not be overwritten by user space calibration data.
> +        */
> +       rc = tasdevice_dev_bulk_read(priv, i, p->r0_reg, r0_buf, 4);
> +       if (rc >= 0 && (r0_buf[0] | r0_buf[1] | r0_buf[2] | r0_buf[3])) {
> +               dev_dbg(priv->dev,
> +                       "%s: dev %d r0_reg already set by config, skipping calibration\n",
> +                       __func__, i);
> +               return;
> +       }
> +
>         /* load calibrated data from user space */
>         if (data[k] != i) {
>                 dev_err(priv->dev, "%s: no cal-data for dev %d from usr-spc\n",
>
> Is this more suitable to be upstreamed?
>
> Thanks,
> Matt
> <snip>
>