Hi Hans, On Sun, Feb 18, 2024 at 4:15 PM Hans de Goede <hdegoede@xxxxxxxxxx> 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!
