[RFC,0/2] ACPI: Adding new acpi_driver type drivers ?

Hi Rafael,

I recently learned that some Dell AIOs (1) use a backlight controller board
connected to an UART. Canonical even submitted a driver for this in 2017:
https://lkml.org/lkml/2017/10/26/78

This UART has a DELL0501 HID with CID set to PNP0501 so that the UART is
still handled by 8250_pnp.c. Unfortunately there is no separate ACPI device
with an UartSerialBusV2() resource to model the backlight-controller.

The RFC patch 2/2 in this series uses acpi_quirk_skip_serdev_enumeration()
to still create a serdev for this for a backlight driver to bind to
instead of creating a /dev/ttyS0.

Like other cases where the UartSerialBusV2() resource is missing or broken
this will only create the serdev-controller device and the serdev-device
itself will need to be instantiated by the consumer (the backlight driver).

Unlike existing other cases which use DMI modaliases to load on a specific
board to work around brokeness of that board's specific ACPI tables, the
intend here is to have a single driver for all Dell AIOs using the DELL0501
HID for their UART, without needing to maintain a list of DMI matches.

This means that the dell-uart-backlight driver will need something to bind
to. The original driver from 2017 used an acpi_driver for this matching on
and binding to the DELL0501 acpi_device.

AFAIK you are trying to get rid of having drivers bind directly to
acpi_device-s so I assume that you don't want me to introduce a new one.
So to get a device to bind to without introducing a new acpi_driver
patch 2/2 if this series creates a platform_device for this.

The creation of this platform_device is why this is marked as RFC,
if you are ok with this solution I guess you can merge this series
already as is. With the caveat that the matching dell-uart-backlight
driver is still under development (its progressing nicely and the
serdev-device instantation + binding a serdev driver to it already
works).

If you have a different idea how to handle this I'm certainly open
to suggestions.

Regards,

Hans

1) All In One a monitor with a PC builtin


p.s.

I also tried this approach, but that did not work:

This was an attempt to create both a pdev from acpi_default_enumeration()
by making the PNP scan handler attach() method return 0 rather then 1;
and get a pnp_device created for the UART driver as well by
making acpi_is_pnp_device() return true.

This approach does not work due to the following code in pnpacpi_add_device():

	/* Skip devices that are already bound */
	if (device->physical_node_count)
		return 0;

 
Hans de Goede (2):
  ACPI: x86: Move acpi_quirk_skip_serdev_enumeration() out of
    CONFIG_X86_ANDROID_TABLETS
  ACPI: x86: Add DELL0501 handling to
    acpi_quirk_skip_serdev_enumeration()

 drivers/acpi/x86/utils.c | 38 ++++++++++++++++++++++++++++++++++----
 include/acpi/acpi_bus.h  | 22 +++++++++++-----------
 2 files changed, 45 insertions(+), 15 deletions(-)

Hi Hans,

On Sun, Feb 18, 2024 at 4:15 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Rafael,
>
> I recently learned that some Dell AIOs (1) use a backlight controller board
> connected to an UART. Canonical even submitted a driver for this in 2017:
> https://lkml.org/lkml/2017/10/26/78
>
> This UART has a DELL0501 HID with CID set to PNP0501 so that the UART is
> still handled by 8250_pnp.c. Unfortunately there is no separate ACPI device
> with an UartSerialBusV2() resource to model the backlight-controller.
>
> The RFC patch 2/2 in this series uses acpi_quirk_skip_serdev_enumeration()
> to still create a serdev for this for a backlight driver to bind to
> instead of creating a /dev/ttyS0.
>
> Like other cases where the UartSerialBusV2() resource is missing or broken
> this will only create the serdev-controller device and the serdev-device
> itself will need to be instantiated by the consumer (the backlight driver).
>
> Unlike existing other cases which use DMI modaliases to load on a specific
> board to work around brokeness of that board's specific ACPI tables, the
> intend here is to have a single driver for all Dell AIOs using the DELL0501
> HID for their UART, without needing to maintain a list of DMI matches.
>
> This means that the dell-uart-backlight driver will need something to bind
> to. The original driver from 2017 used an acpi_driver for this matching on
> and binding to the DELL0501 acpi_device.
>
> AFAIK you are trying to get rid of having drivers bind directly to
> acpi_device-s so I assume that you don't want me to introduce a new one.
> So to get a device to bind to without introducing a new acpi_driver
> patch 2/2 if this series creates a platform_device for this.
>
> The creation of this platform_device is why this is marked as RFC,
> if you are ok with this solution I guess you can merge this series
> already as is.

OK

> With the caveat that the matching dell-uart-backlight
> driver is still under development (its progressing nicely and the
> serdev-device instantation + binding a serdev driver to it already
> works).
>
> If you have a different idea how to handle this I'm certainly open
> to suggestions.

I agree with the approach, thanks!