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.
