linux-kernel - Re: [PATCH 2/6] platform/x86/uniwill: Handle more WMI events required for TUXEDO devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <eb66f09f-6f14-43c9-a319-8f2bc745e055@tuxedocomputers.com>
Date: Mon, 24 Nov 2025 19:40:44 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Armin Wolf <W_Armin@....de>, hansg@...nel.org,
 ilpo.jarvinen@...ux.intel.com
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] platform/x86/uniwill: Handle more WMI events required
 for TUXEDO devices

Hi

Am 20.11.25 um 01:53 schrieb Armin Wolf:
> [snip]
>
> Anyway, i attached the patch with the device descriptor infrastructure. The 
> callback called during probe cannot modify
> the feature bitmap anymore, but i suggest that you simply set the limit for 
> cTGP to zero. The code responsible for
> initializing cTGP support can then check if the cTGP limit is zero and return 
> early. 

Looked into it: whats the reason for the "__ro_after_init" in "static struct 
uniwill_device_descriptor device_descriptor __ro_after_init;"?

The thing Ilpo wrote sounded like just .driver_data itself should be read only, 
but as soon as it has an indirection, like here being copied over to a static 
variable, read/write is ok.

Also: Why not just copy the device_descriptor over to uniwill_data instead of a 
static variable?

And do I get that correctly: All you can do during the init callback is doing 
more sophisticated DMI matching?

Best regards,

Werner

> [snip]