Received-SPF: pass (google.com: domain of linux-kernel+bounces-117942-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: i5ec1447f:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940
Precedence: bulk
MIME-Version: 1.0
Message-Id: <9962eb39-23b8-470c-aab9-698f10c80358@app.fastmail.com>
In-Reply-To: <2cadcf26-7b99-3b32-8441-1b3939cf93b4@linux.intel.com>
References: <20240325054938.489732-1-luke@ljones.dev>
 <20240325054938.489732-2-luke@ljones.dev>
 <2cadcf26-7b99-3b32-8441-1b3939cf93b4@linux.intel.com>
Date: Tue, 26 Mar 2024 09:35:44 +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 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 functions
> > to select the relevant dev-id. Also add `available_mini_led_mode` to=
 the
> > platform sysfs since the available mini-led levels can be different.
> >=20
> > Signed-off-by: Luke D. Jones <luke@ljones.dev>
> > ---
> >  .../ABI/testing/sysfs-platform-asus-wmi       |  8 ++
> >  drivers/platform/x86/asus-wmi.c               | 74 ++++++++++++++++=
+--
> >  include/linux/platform_data/x86/asus-wmi.h    |  1 +
> >  3 files changed, 76 insertions(+), 7 deletions(-)
> >=20
> > diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Doc=
umentation/ABI/testing/sysfs-platform-asus-wmi
> > index 8a7e25bde085..61a745d2476f 100644
> > --- a/Documentation/ABI/testing/sysfs-platform-asus-wmi
> > +++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi
> > @@ -126,6 +126,14 @@ Description:
> >  Change the mini-LED mode:
> >  * 0 - Single-zone,
> >  * 1 - Multi-zone
> > + * 2 - Multi-zone strong (available on newer generation mini-led)
> > +
> > +What: /sys/devices/platform/<platform>/available_mini_led_mode
> > +Date: Jun 2023
> > +KernelVersion: 6.10
> > +Contact: "Luke Jones" <luke@ljones.dev>
> > +Description:
> > + List the available mini-led modes.
> > =20
> >  What: /sys/devices/platform/<platform>/ppt_pl1_spl
> >  Date: Jun 2023
> > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/=
asus-wmi.c
> > index 18be35fdb381..54ce0fb26f42 100644
> > --- a/drivers/platform/x86/asus-wmi.c
> > +++ b/drivers/platform/x86/asus-wmi.c
> > @@ -297,6 +297,7 @@ struct asus_wmi {
> > =20
> >  bool panel_overdrive_available;
> >  bool mini_led_mode_available;
> > + u32 mini_led_dev_id;
> > =20
> >  struct hotplug_slot hotplug_slot;
> >  struct mutex hotplug_lock;
> > @@ -2109,10 +2110,27 @@ static ssize_t mini_led_mode_show(struct dev=
ice *dev,
> >  struct asus_wmi *asus =3D dev_get_drvdata(dev);
> >  int result;
> > =20
> > - result =3D asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_MINI_=
LED_MODE);
> > - if (result < 0)
> > - return result;
> > + result =3D asus_wmi_get_devstate_simple(asus, asus->mini_led_dev_i=
d);
> > =20
> > + /* Remap the mode values to match previous generation mini-led.
> > + * Some BIOSes return -19 instead of 2, which is "mini-LED off", th=
is
> > + * 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 suspect=20
> it's -ENODEV error code from from one of the functions on the driver s=
ide
> (which is why I asked you to change it into -ENODEV).

Yes it does. It is rather annoying. What happens in this case is that `2=
` is written to the WMI endpoint to turn off the MINI-Led feature, this =
works fine and it is turned off, there are no errors from the write at a=
ll - verifying the accepted limits in dsdt also shows it is correct.

However, after that, the read fails once. And only if that `2` was writt=
en. `0` and `1` write fine, and read fine also. I hope I've managed to d=
escribe and clarify what I'm seeing here.

I'm happy to change -ENODEV. No problem, queued on my todo list.

Cheers,
Luke.