Received-SPF: pass (google.com: domain of linux-kernel+bounces-120249-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Feedback-ID: i5ec1447f:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-328-gc998c829b7-fm-20240325.002-gc998c829
Precedence: bulk
MIME-Version: 1.0
Message-Id: <ea29c277-73cf-4574-8316-dff85a449f54@app.fastmail.com>
In-Reply-To: <13a24576-da89-95b8-4ed2-c24b5ba54a21@linux.intel.com>
References: <20240325054938.489732-1-luke@ljones.dev>
 <20240325054938.489732-2-luke@ljones.dev>
 <2cadcf26-7b99-3b32-8441-1b3939cf93b4@linux.intel.com>
 <9962eb39-23b8-470c-aab9-698f10c80358@app.fastmail.com>
 <13a24576-da89-95b8-4ed2-c24b5ba54a21@linux.intel.com>
Date: Wed, 27 Mar 2024 16:01:09 +1300
From: "Luke Jones" <luke@ljones.dev>
To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
Cc: "Hans de Goede" <hdegoede@redhat.com>, corentin.chary@gmail.com,
 platform-driver-x86@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/9] platform/x86: asus-wmi: add support for 2024 ROG Mini-LED
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, 27 Mar 2024, at 12:49 AM, Ilpo J=C3=A4rvinen wrote:
> On Tue, 26 Mar 2024, Luke Jones wrote:
> > On Tue, 26 Mar 2024, at 2:47 AM, Ilpo J=C3=A4rvinen wrote:
> > > On Mon, 25 Mar 2024, Luke D. Jones wrote:
> > >=20
> > > > Support the 2024 mini-led backlight and adjust the related funct=
ions
> > > > to select the relevant dev-id. Also add `available_mini_led_mode=
` to the
> > > > platform sysfs since the available mini-led levels can be differ=
ent.
> > > >=20
> > > > Signed-off-by: Luke D. Jones <luke@ljones.dev>
> > > > ---
>=20
> > > > @@ -2109,10 +2110,27 @@ static ssize_t mini_led_mode_show(struct=
 device *dev,
> > > >  struct asus_wmi *asus =3D dev_get_drvdata(dev);
> > > >  int result;
> > > > =20
> > > > - result =3D asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_M=
INI_LED_MODE);
> > > > - if (result < 0)
> > > > - return result;
> > > > + result =3D asus_wmi_get_devstate_simple(asus, asus->mini_led_d=
ev_id);
> > > > =20
> > > > + /* Remap the mode values to match previous generation mini-led.
> > > > + * Some BIOSes return -19 instead of 2, which is "mini-LED off"=
, this
> > > > + * appears to be a  BIOS bug.
> > > > + */
> > > > + if (asus->mini_led_dev_id =3D=3D ASUS_WMI_DEVID_MINI_LED_MODE2=
) {
> > > > + switch (result) {
> > > > + case 0:
> > > > + result =3D 1;
> > > > + break;
> > > > + case 1:
> > > > + result =3D 2;
> > > > + break;
> > > > + case 2:
> > > > + case -19:
> > >=20
> > > Can you confirm this -19 really does come from BIOS? Because I sus=
pect=20
> > > it's -ENODEV error code from from one of the functions on the driv=
er side
> > > (which is why I asked you to change it into -ENODEV).
> >=20
> > Yes it does. It is rather annoying. What happens in this case is tha=
t=20
> > `2` is written to the WMI endpoint to turn off the MINI-Led feature,=20
> > this works fine and it is turned off, there are no errors from the w=
rite=20
> > at all - verifying the accepted limits in dsdt also shows it is corr=
ect.=20
> >=20
> > However, after that, the read fails once.
>=20
> Hi,
>=20
> I'm left a bit unsure how to interpret your response. If "read fails",=
 it=20
> would indicate that -ENODEV originates from asus_wmi_evaluate_method3(=
),=20
> asus_wmi_get_devstate() or asus_wmi_get_devstate_bits(), not from BIOS=
? So=20
> which way it is?
>=20
> After reading some more code, I think I figured out the answer myself.
> However, that raises another question... So lets now take a step back =
and=20
> walk through the code:
>=20
> Your patch does:
> result =3D asus_wmi_get_devstate_simple(asus, asus->mini_led_dev_id);
>=20
> asus_wmi_get_devstate_simple() calls asus_wmi_get_devstate_bits() with
> ASUS_WMI_DSTS_STATUS_BIT mask that is 0x00000001.
>=20
> If there's no error, retval is masked with that ASUS_WMI_DSTS_STATUS_B=
IT=20
> forcing the return value to 0-1 range so:
>=20
> a) I don't think -19 can originate from BIOS but comes from kernel sid=
e.
> b) How can it ever return 2 (mini-LED off) ?????

You're right. *facepalm* *grumble*. Honestly if I were getting paid for =
this work I'd invest a bit more time in it and catch these silly little =
things myself.

I'll update the code with all feedback, including using a more appropria=
te WMI function whcih I really should have seen on my own.

Thank you for your time so far.