linux-kernel - Re: Re: [PATCH] ALSA: hda/realtek: Fix internal speakers for Legion Y9000X 2022 IAH7

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:
 <TYCP286MB25356BFBD3D67D4E1FD09732C4092@TYCP286MB2535.JPNP286.PROD.OUTLOOK.COM>
Date: Tue, 16 Apr 2024 00:49:41 +0800
From: ArcticLampyrid <ArcticLampyrid@...look.com>
To: sbinding@...nsource.cirrus.com
Cc: ArcticLampyrid@...look.com,
	david.rhodes@...rus.com,
	james.schulman@...rus.com,
	linux-kernel@...r.kernel.org,
	linux-sound@...r.kernel.org,
	patches@...nsource.cirrus.com,
	rf@...nsource.cirrus.com,
	stable@...r.kernel.org
Subject: Re: Re: [PATCH] ALSA: hda/realtek: Fix internal speakers for Legion Y9000X 2022 IAH7

> According to the ACPI that I have access to, this is not correct - the
> Speaker ID is on index 2 not index 1.
> Index 1 has a reference to the interrupt line. Therefore this should be:
>
> 	{ "17AA386E", 2, EXTERNAL, { CS35L41_LEFT, CS35L41_RIGHT, 0, 0 }, 0, 2, -1, 0, 0, 0 },

Sorry, but I'm unable to retrieve the speaker ID index from my BIOS.
Please tell me how to check it, thanks.

I've tried using `spkid_gpio_index = 2`, but haven't noticed any changes.

> The reason for any issue you see may be
> because you have assigned the speaker id for the interrupt gpio in ACPI
> as mentioned above.

Despite changing `spkid_gpio_index` to 2, it hasn't worked with `generic_dsd_config`.

The journal logs show:
```log
kernel: Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 I2C devices.
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Adding DSD properties for 17AA386E
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Using extra _DSD properties, bypassing _DSD in ACPI
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Adding DSD properties for 17AA386E
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Using extra _DSD properties, bypassing _DSD in ACPI
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
kernel: genirq: Flags mismatch irq 58. 00002088 (cs35l41 IRQ1 Controller) vs. 00002088 (cs35l41 IRQ1 Controller)
kernel:  cs35l41_hda_probe+0x94b/0x9d0 [snd_hda_scodec_cs35l41 5706d5af6d4d4abb9d294b49d5cd4cc8a51aad9d]
kernel:  ? __pfx_cs35l41_i2c_driver_init+0x10/0x10 [snd_hda_scodec_cs35l41_i2c 8858b01ad506c8ac36ad9a656c7cb71d39d6ec09]
kernel: cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Failed to request IRQ 58 for cs35l41 IRQ1 Controller: -16
kernel: cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -16
```

I believe this error might be caused by the configuration of the same IRQ multiple times.

Additionally, I checked the Cirrus SmartAMP driver on Windows, which appears to use only one IRQ (ID 58) on my device.
Therefore, I don't believe there is a need to configure two IRQs on my device.

The message `Flags mismatch 00002088 vs. 00002088` is confusing.
Further investigation reveals that the following check in `__setup_irq` failed:
```c
if (irqd_trigger_type_was_set(&desc->irq_data)) {
    oldtype = irqd_get_trigger_type(&desc->irq_data);
} else {
    oldtype = new->flags & IRQF_TRIGGER_MASK;
    irqd_set_trigger_type(&desc->irq_data, oldtype);
}

if (!((old->flags & new->flags) & IRQF_SHARED) ||
    (oldtype != (new->flags & IRQF_TRIGGER_MASK)))
    goto mismatch;
```

While the previous request used flags `0x00002088 = IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_LOW`,
the `oldtype` was actually `IRQF_TRIGGER_RISING` (0x1) rather than `IRQF_TRIGGER_LOW` (0x8), leading to the mismatch.

I am new to Linux Kernel, not sure if this is expected behavior or a bug for `IRQF_SHARED`.
Ideally, a clearer message may be provided to facilitate understanding.

Sorry to bother you if I make some foolish mistakes.