From: Hans de Goede <hdegoede@redhat.com>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
linux-acpi@vger.kernel.org, AceLan Kao <acelan.kao@canonical.com>
Subject: Re: [RFC 0/2] ACPI: Adding new acpi_driver type drivers ?
Date: Sun, 12 May 2024 17:58:02 +0200 [thread overview]
Message-ID: <3fdb7491-5073-4145-9874-a038e1c4b76a@redhat.com> (raw)
In-Reply-To: <CAAd53p4r=+fUkmUm9dQWDm4uYhm7rgMESTtv=zZer5RB5oiHRw@mail.gmail.com>
Hi Kai-Heng Feng,
On 5/8/24 6:42 AM, Kai-Heng Feng wrote:
> [+Cc AceLan]
>
> Hi Hans,
>
> On Wed, Apr 24, 2024 at 5:58 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi Kai-Heng Feng,
>>
>> On 4/24/24 10:04 AM, Kai-Heng Feng wrote:
>>> Hi Hans,
>>>
>>> On Sun, Feb 18, 2024 at 11: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. 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).
>>>
>>> I was about to work on this and found you're already working on it.
>>>
>>> Please add me to Cc list when the driver is ready to be tested, thanks!
>>
>> I hope you have access to actual hw with such a backlight device ?
>>
>> The driver actually has been ready for testing for quite a while now,
>> but the person who reported this backlight controller not being
>> supported to me has been testing this on a AIO of a friend of theirs
>> and this has been going pretty slow.
>>
>> So if you can test the driver (attached) then that would be great :)
>>
>> I even wrote an emulator to test it locally and that works, so
>> assuming I got the protocol right from the original posting of
>> the driver for this years ago then things should work.
>>
>> Note this depends on the kernel also having the patches from this
>> RFC (which Rafael has already merged) applied.
>
> There are newer AIO have UID other than 0, like "SIOBUAR2".
>
> Once change the "0" to NULL in 'get_serdev_controller("DELL0501", "0",
> 0, "serial0");', everything works perfectly.
>
> With that change,
> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Great thank you for testing. Luck has it that the user for who's
Dell AOI I started working on this also just reported back that
the driver works for them :)
So I'm going to send out the patch series for this now with
the following diff squashed in vs what I send you:
diff --git a/drivers/platform/x86/dell/dell-uart-backlight.c b/drivers/platform/x86/dell/dell-uart-backlight.c
index da4a640c0d88..3882bb7d6c71 100644
--- a/drivers/platform/x86/dell/dell-uart-backlight.c
+++ b/drivers/platform/x86/dell/dell-uart-backlight.c
@@ -352,7 +352,7 @@ static int dell_uart_bl_pdev_probe(struct platform_device *pdev)
struct device *ctrl_dev;
int ret;
- ctrl_dev = get_serdev_controller("DELL0501", "0", 0, "serial0");
+ ctrl_dev = get_serdev_controller("DELL0501", NULL, 0, "serial0");
if (IS_ERR(ctrl_dev))
return PTR_ERR(ctrl_dev);
Regards,
Hans
prev parent reply other threads:[~2024-05-12 15:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-18 15:15 [RFC 0/2] ACPI: Adding new acpi_driver type drivers ? Hans de Goede
2024-02-18 15:15 ` [RFC 1/2] ACPI: x86: Move acpi_quirk_skip_serdev_enumeration() out of CONFIG_X86_ANDROID_TABLETS Hans de Goede
2024-02-18 18:39 ` Andy Shevchenko
2024-02-19 10:19 ` Hans de Goede
2024-02-18 15:15 ` [RFC 2/2] ACPI: x86: Add DELL0501 handling to acpi_quirk_skip_serdev_enumeration() Hans de Goede
2024-02-22 10:10 ` [RFC 0/2] ACPI: Adding new acpi_driver type drivers ? Rafael J. Wysocki
2024-04-24 8:04 ` Kai-Heng Feng
2024-04-24 9:58 ` Hans de Goede
2024-05-08 4:42 ` Kai-Heng Feng
2024-05-08 9:43 ` Andy Shevchenko
2024-05-08 10:41 ` Kai-Heng Feng
2024-05-12 15:55 ` Hans de Goede
2024-05-12 15:58 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3fdb7491-5073-4145-9874-a038e1c4b76a@redhat.com \
--to=hdegoede@redhat.com \
--cc=acelan.kao@canonical.com \
--cc=andy@kernel.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-acpi@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).