[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4c202b2-ab29-e2aa-b141-0c967b2c1645@opensource.cirrus.com>
Date: Wed, 24 May 2023 17:36:04 +0100
From: Stuart Henderson <stuarth@...nsource.cirrus.com>
To: Takashi Iwai <tiwai@...e.de>, Luke Jones <luke@...nes.dev>
CC: <linux-kernel@...r.kernel.org>, <tiwai@...e.com>,
<sbinding@...nsource.cirrus.com>, <perex@...ex.cz>,
<tangmeng@...ontech.com>, <andy.chi@...onical.com>,
<p.jungkamp@....net>, <kasper93@...il.com>,
<yangyuchi66@...il.com>, <armas@...ux.tech>, <ealex95@...il.com>,
<james.schulman@...rus.com>, <david.rhodes@...rus.com>,
<tanureal@...nsource.cirrus.com>, <rf@...nsource.cirrus.com>,
<patches@...nsource.cirrus.com>, <alsa-devel@...a-project.org>
Subject: Re: CSC3551 and devices missing related _DSD bits
> 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.
Powered by blists - more mailing lists