Re: [PATCH] platform/chrome: cros_kbd_led_backlight: enable probing through EC_FEATURE_PWM_KEYB

Thomas Weißschuh
2024-05-09T08:13:45Z

On 2024-05-09 12:25:01+0000, Tzung-Bi Shih wrote:
> On Mon, May 06, 2024 at 07:38:09PM +0200, Thomas Weißschuh wrote:
> > On 2024-05-05 08:42:21+0000, Mario Limonciello wrote:
> > > On 5/5/2024 04:41, Thomas Weißschuh wrote:
> > > > The ChromeOS EC used in Framework laptops supports the standard cros
> > > > keyboard backlight protocol.
> > > > However the firmware on these laptops don't implement the ACPI ID
> > > > GOOG0002 that is recognized by cros_kbd_led_backlight and they also
> > > > don't use device tree.
>
> If implementing ACPI ID GOOG0002 is not an option, how about adding a new ACPI
> ID? For the new ACPI ID, it can use EC PWM for setting the brightness.

Adding a new ACPI ID would be easier than a full-blown ACPI interface.
This would still need changes to the drivers probing setup, however.

What are the advantages of the ACPI ID aproach over EC_FEATURE_PWM_KEYB?
The EC feature also automatically works on device-tree platforms and
without any work from system vendors.

Adding ACPI ID only for signalling without using ACPI for
communication on the other hand seems weird.
Also with MFD the device hierarchy is much better.

> > > Something I'd wonder is if the GOOG0002 ACPI ID can go away entirely with
> > > this type of change. Presumably the Chromebooks with ChromeOS EC /also/
> > > advertise EC_FEATURE_PWM_KEYB.
> >
> > Sounds good to me in general. It would make the code cleaner.
> >
> > But I have no idea how CrOS kernels are set up in general.
> > If they are not using CONFIG_MFD_CROS_EC_DEV for some reason that
> > wouldn't work.
> >
> > If the CrOS folks agree with that aproach I'll be happy to implement it.
>
> I would say NO as some existing devices (with legacy firmware and kernel) may
> rely on it.

Ack, makes sense.

You mention legacy kernels, but these would not be affected.