Bug 213297

Created attachment 297075 [details]
dmesg boot log

Created attachment 297077 [details]
DSDT.dsl

As for /sys/firmware/acpi/platform_profile, the issue is very possible the same as https://bugzilla.kernel.org/show_bug.cgi?id=212985 , that is, the driver only supports DYTC 5 and above, but it seems from the DSDT that version 4 is available on that machine.

As for the keyboard backlight, it's not available because the driver only supports and older version of the keyboard backlight control interface which does not seem to be available.

As for "LUK2019" and "IDEA2004", those devices don't seem to be that interesting (I might be wrong though) at first glance since they seem to contain more or less nothing as far as I can see:

            Device (HKDV)
            {
                Name (_HID, "LHK2019")  // _HID: Hardware ID
                Name (_UID, Zero)  // _UID: Unique ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    Return (0x0F)
                }
            }

            ...

            Scope (^^EC0)
            {
                Device (ITSD)
                {
                    Name (_HID, "IDEA2004")  // _HID: Hardware ID
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        Return (0x0F)
                    }
                }
            }

As for the, I assume, screen backlight and Fn keys, unfortunately I cannot help.

(In reply to Barnabás Pőcze from comment #3)
> As for /sys/firmware/acpi/platform_profile, the issue is very possible the
> same as https://bugzilla.kernel.org/show_bug.cgi?id=212985 , that is, the
> driver only supports DYTC 5 and above, but it seems from the DSDT that
> version 4 is available on that machine.
> 
> As for the keyboard backlight, it's not available because the driver only
> supports and older version of the keyboard backlight control interface which
> does not seem to be available.
> 
> As for "LUK2019" and "IDEA2004", those devices don't seem to be that
> interesting (I might be wrong though) at first glance since they seem to
> contain more or less nothing as far as I can see:
> 
>             Device (HKDV)
>             {
>                 Name (_HID, "LHK2019")  // _HID: Hardware ID
>                 Name (_UID, Zero)  // _UID: Unique ID
>                 Method (_STA, 0, NotSerialized)  // _STA: Status
>                 {
>                     Return (0x0F)
>                 }
>             }
> 
>             ...
> 
>             Scope (^^EC0)
>             {
>                 Device (ITSD)
>                 {
>                     Name (_HID, "IDEA2004")  // _HID: Hardware ID
>                     Method (_STA, 0, NotSerialized)  // _STA: Status
>                     {
>                         Return (0x0F)
>                     }
>                 }
>             }
> 
> As for the, I assume, screen backlight and Fn keys, unfortunately I cannot
> help.

Thank you for your help! I thought mentioning LHK2019 and IDEA2004 might be relevant as both platforms load Lenovo-specific drivers in Windows 10, thus I assumed that they are supposed to do the same in Linux. 
May I ask how you were able to determine the DYTC version on my machine? I have been unsuccessfully trying to figure it out myself for the last few days. Thanks!

The DSDT contains the following:

Method (DYTC, 1, Serialized)
{
    Local0 = Arg0
    DYTP = Local0
    Local1 = Zero
    Switch (ToInteger ((Local0 & 0x01FF)))
    {
        Case (Zero)
        {
            Local1 = 0x0100
            Local1 |= 0x40000000
            Local1 |= Zero
            Local1 |= One
        }
...


and you can also see that the DYTC method returns "Local1", which is set to 0x40000101 (I think - but the important part is the 0x40...). And you can also determine from the driver that the version is in bits 28-31 of the return value of the DYTC method when called with 0 as its first argument. And those bits are exactly 4.

(In reply to Barnabás Pőcze from comment #5)
> The DSDT contains the following:
> 
> Method (DYTC, 1, Serialized)
> {
>     Local0 = Arg0
>     DYTP = Local0
>     Local1 = Zero
>     Switch (ToInteger ((Local0 & 0x01FF)))
>     {
>         Case (Zero)
>         {
>             Local1 = 0x0100
>             Local1 |= 0x40000000
>             Local1 |= Zero
>             Local1 |= One
>         }
> ...
> 
> 
> and you can also see that the DYTC method returns "Local1", which is set to
> 0x40000101 (I think - but the important part is the 0x40...). And you can
> also determine from the driver that the version is in bits 28-31 of the
> return value of the DYTC method when called with 0 as its first argument.
> And those bits are exactly 4.

Finally, I understand! Thank you very much!

I came across this issue, and I checked the ideapad-acpi source code and for some reason it now allows DYTC version 4, but only for 1 laptop model. 
https://github.com/torvalds/linux/blob/ca1fdab7fd27eb069df1384b2850dcd0c2bebe8d/drivers/platform/x86/ideapad-laptop.c#L871

(In reply to Luis O from comment #7)
> I came across this issue, and I checked the ideapad-acpi source code and for
> some reason it now allows DYTC version 4, but only for 1 laptop model. 
> https://github.com/torvalds/linux/blob/
> ca1fdab7fd27eb069df1384b2850dcd0c2bebe8d/drivers/platform/x86/ideapad-laptop.
> c#L871

Right, this is done because we don't know if DYTC version 4 will work on all models. The ideapad platform-profile code was based on the ThinkPad code contibuted by Lenovo and that was for version 5.

So for now we only allow using v4 on tested devices.

What would be good is to add a module parameter to allow using the platform-profile code on v4 devices for easier testing. If you can submit a patch to do that that would be great.

Or if you're not into writing kernel patches, I can write such a patch and then you can test it on your model. Note this will require you to build your own kernel from source.

And if the testing of the patch also shows that your model works correctly, then your model can also be added to the list of devices on which using v4 DYTC support is allowed (and eventually if that list becomes quite big we may choose to enable this by default).

Created attachment 301253 [details]
attachment-26511-0.html

1. indeed, that kernel module will make testing much easier for other people
2. please write the patch, and I'll test it. I'm on fedora 36 if that helps.

thank you!

Sent from Proton Mail mobile

-------- Original Message --------
On Jun 22, 2022, 3:51 AM, wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=213297 Hans de Goede
> (jwrdegoede@fedoraproject.org) changed: What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |jwrdegoede@fedoraproject.or | |g --- Comment #8 from Hans de Goede
> (jwrdegoede@fedoraproject.org) --- (In reply to Luis O from comment #7) > I
> came across this issue, and I checked the ideapad-acpi source code and for >
> some reason it now allows DYTC version 4, but only for 1 laptop model. >
> https://github.com/torvalds/linux/blob/ >
> ca1fdab7fd27eb069df1384b2850dcd0c2bebe8d/drivers/platform/x86/ideapad-laptop.
> > c#L871 Right, this is done because we don't know if DYTC version 4 will
> work on all models. The ideapad platform-profile code was based on the
> ThinkPad code contibuted by Lenovo and that was for version 5. So for now we
> only allow using v4 on tested devices. What would be good is to add a module
> parameter to allow using the platform-profile code on v4 devices for easier
> testing. If you can submit a patch to do that that would be great. Or if
> you're not into writing kernel patches, I can write such a patch and then you
> can test it on your model. Note this will require you to build your own
> kernel from source. And if the testing of the patch also shows that your
> model works correctly, then your model can also be added to the list of
> devices on which using v4 DYTC support is allowed (and eventually if that
> list becomes quite big we may choose to enable this by default). -- You may
> reply to this email to add a comment. You are receiving this mail because:
> You are on the CC list for the bug.

Created attachment 301262 [details]
[PATCH] platform: x86: ideapad-laptop: Add allow_v4_dytc module parameter

Ok, here is a patch adding the discussed module parameter. Please give this a try.

If platform-profiles work after enabling them with the parameter, please also provide dmidecode output so that your laptop model can be added to the ideapad_dytc_v4_allow_table[].

Created attachment 301264 [details]
dmidecode of the ideapad 5 15itl05 laptop

Indeed, it does work! Thank you! I don't know if this is ok to ask here, but any chance for this to *also* be included on the stock fedora kernel?

(In reply to Luis O from comment #11)
> Created attachment 301264 [details]
> dmidecode of the ideapad 5 15itl05 laptop
> 
> Indeed, it does work! Thank you! I don't know if this is ok to ask here, but
> any chance for this to *also* be included on the stock fedora kernel?

Thanks. I've also written a patch to update the DMI table and I've added both patches to the plaform-drivers-x86 fixes branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=fixes

I plan to send a pull-request with these fixes to Linus soon, once this has landed in Linus' tree these will get added to the 5.18.y stable series soon afterwards. So these should show up in a Fedora 5.18.y kernel update soon-ish.