Re: equest to upstream: ALC287_FIXUP_TXNW2781_I2C quirk for ASUS Strix Gxx5 family (CachyOS commit 20313d76)

On Fri, 15 May 2026 14:52:00 +0200,
Eric Naim wrote:
> 
> On 5/15/26 8:40 PM, Eric Naim wrote:
> > On 5/15/26 5:04 PM, Takashi Iwai wrote:
> >> On Wed, 13 May 2026 11:24:00 +0200,
> >> Eric Naim wrote:
> >>>
> >>> On 5/12/26 9:50 PM, Rob Blake wrote:
> >>>> Hi all,
> >>>>
> >>>> I'm writing to ask whether the small fixup-table change below can be picked up
> >>>> for mainline. It's already in CachyOS's downstream tree since 2026-03-06 and
> >>>> is reported to restore speaker audio on an
> >>>> entire family of recent ASUS ROG Strix laptops, including mine.
> >>>>
> >>>> The relevant commit is by Eric Naim <[email protected]>:
> >>>>
> >>>>   CachyOS commit 20313d767be2e5abdb88295b7c724634e1937a4f
> >>>>   "ALSA: hda/realtek: Use ALC287_FIXUP_TXNW2781_I2C for ASUS Strix Gxx5"
> >>>> https://github.com/CachyOS/linux/commit/20313d767be2e5abdb88295b7c724634e1937a4f
> >>>>
> >>>> The change is a six-line edit to sound/hda/codecs/realtek/alc269.c: the
> >>>> affected SSIDs are currently mapped to ALC287_FIXUP_TAS2781_I2C but actually
> >>>> need ALC287_FIXUP_TXNW2781_I2C. The wrong quirk leaves the I²C interrupt
> >>>> config inconsistent with the ACPI TXNW2781 entry, so serial-multi-instantiate
> >>>> fails to resolve IRQ index 0 for each of the three amp channels, and only the
> >>>> first channel binds.
> >>>>
> >>>> SSIDs affected (per Eric's patch):
> >>>>   0x1043 0x3ee0  ASUS Strix G815_JHR_JMR_JPR
> >>>>   0x1043 0x3ef0  ASUS Strix G635LR_LW_LX
> >>>>   0x1043 0x3f00  ASUS Strix G815LH_LM_LP
> >>>>   0x1043 0x3f10  ASUS Strix G835LR_LW_LX
> >>>>   0x1043 0x3f20  ASUS Strix G615LR_LW   <-- my machine
> >>>>   0x1043 0x3f30  ASUS Strix G815LR_LW
> >>>>
> >>>> On my G615LW (SSID 1043:3f20) running kernel 6.19.14-101.fc44, the
> >>>> broken state matches Eric's commit log exactly:
> >>>>
> >>>>   Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO:
> >>>> IRQ index 0 not found
> >>>>   Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO:
> >>>> IRQ index 0 not found
> >>>>   Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO:
> >>>> IRQ index 0 not found
> >>>>   Serial bus multi instantiate pseudo device driver TXNW2781:00: Instantiated
> >>>> 3 I2C devices.
> >>>>
> >>>> with .0 binding to tas2781-hda and .1/.2 staying at driver=NONE.
> >>>> Speakers are silent. Headphones work (they're on a separate codec pin and
> >>>> don't involve TAS2781).
> >>>>
> >>>> I've ruled out asusd as the cause — I rebooted with asusd masked and the
> >>>> failure is identical, so this is purely codec-quirk-table business.
> >>>>
> >>>> Original upstream report:
> >>>> https://lore.kernel.org/
> >>>> CACB9z7kjs8rhLstEc8fV29BCTb5dd881JwGozoKdO5cwCb=YwQ@mail.gmail.com
> >>>>
> >>>> CachyOS issue with discussion:
> >>>>   https://github.com/CachyOS/linux-cachyos/issues/752
> >>>>
> >>>> I'm not a kernel developer and don't feel qualified to submit Eric's patch on
> >>>> his behalf. Could one of you (or Eric, if you're on this list) take a look and
> >>>> consider sending it for inclusion? It's a self-contained six-line change that
> >>>> fixes audio for a sizeable family of shipping laptops, and the patch is
> >>>> already authored and signed-off.
> >>>>
> >>>> Happy to test patches against my G615LW.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Rob
> >>>>
> >>>
> >>> Hi Rob,
> >>>
> >>> I've sent this patch 2 months ago [1]. I never got a reply from Baojun so I
> >>> myself am unsure as to how to proceed, cc'ing them here to hopefully get a reply.
> >>>
> >>> [1] https://lore.kernel.org/linux-sound/[email protected]/
> >>
> >> Indeed.  If no further followup appears, I'm going to pick up Eric's
> >> v2 patch in the next week.
> >>
> >>
> > 
> > Glad to hear that! I haven't sent any v2, but I will do so in the next few
> > days. I assume here the v2 will only cover the 2 confirmed misbehaving devices
> > instead of the full 6 in the first iteration, yes?
> 
> As luck would have it, I just got a report from another distro maintainer that
> PID 0x3f30 also needs the fix, in addition to the confirmed 0x3f20 and 0x3ef0.
> 
> This makes me think that the original patch should be kept as-is. Thoughts?

Whatever you prefer.  Just send the latest versions to be picked up.


thanks,

Takashi