Hi Takashi, Hi Stuart (and of course, all others in here),
would you mind to evaluate this small (pseudo-)patch to be harmless? (concerning the blow-up theory the first answer in this converstion)
I won't push it upstream right now but I want to know if this patch might be harmfull. I'm owning a GA402XY myself and we digged out that the initial setting of the cr3551 can be done via:
diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index 75020edd39e7..eaa06751bd48 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -1243,6 +1243,12 @@ static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, struct device *physd hw_cfg->bst_type = CS35L41_EXT_BOOST; hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH; hw_cfg->gpio1.valid = true; + } else if (strncmp(hid, "CSC3551", 7) == 0 && strcmp(cs35l41-
acpi_subsystem_id, "10431463") == 0) {
+ // TESTING - (Hook for GA402X) + dev_warn(cs35l41->dev, "Warning: ASUS didn't provide the needed ACPI _DSD properties for GA402X series, using defaults.."); + hw_cfg->bst_type = CS35L41_EXT_BOOST; + hw_cfg->gpio1.func = CS35l41_VSPK_SWITCH; + hw_cfg->gpio1.valid = true; } else { /* * Note: CLSA010(0/1) are special cases which use a slightly different design.
--
Which for our devices(GA402XY) enables the DAC to be used (it's still quiet, as we don't know/set the right limits for boost/ind/cap at the moment).
The above will be called in our HDA_Quirk (sound/pci/hda/patch_realtek.c)
```pseudo [ALC285_FIXUP_ASUS_GA402XY] = { .type = HDA_FIXUP_FUNC, .v.func = cs35l41_fixup_i2c_two, // .... }, ```
The cs3551 init be loaded by the above quirk wich is bound to and checks its ID internally again(acpi_subsystem_id):
```pseudo SND_PCI_QUIRK(0x1043, 0x1463, "Asus Zephyrus G14 2023", ALC285_FIXUP_ASUS_GA402XY), ```
Many thanks in advance!
Best regards Armas
On Thu, 2023-05-25 at 09:30 +1200, Luke Jones wrote:
On Wed, 2023-05-24 at 17:36 +0100, Stuart Henderson wrote:
The problem is that this can really easily blow up your machine if some incorrect bit is applied. And more easily applicable, more chance to break by novice users, simply by believing what a chat bot speaks :) That's the very reason why this kind of change should be via ACPI table officially set up by the vendor. That said, the question is only who and how can be responsible for this kind of change. It's no technical issue, per se.
If BIOS can't be updated, at least, the configuration change has to be confirmed by ASUS people. If ASUS still ignores the inquires and requests, we may put the quirk but with a bit fat warning (and maybe complaints to ASUS) to be shown in the log as a very last resort.
Let's see what happens.
Thanks Takashi.
Just a note to say we're not ignoring this and are investigating the best way to support released laptops with ACPI incompatible with Linux. We're hoping this is going to be less of an issue going forward. Please bear with us while we look into this.
This is great news, thank you Stuart. If you need testing done at all on a wide range please reach out to me and I will enlist the help of those with the affected laptops I mentioned.