linux-kernel - Re: [PATCH 3/3] platform/x86: dell-pc: Transition to faux device

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ae149b5-a936-45b4-8887-eb7cde1ee4b0@redhat.com>
Date: Wed, 23 Apr 2025 19:05:47 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Kurt Borja <kuurtb@...il.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Lyndon Sanche <lsanche@...deno.ca>,
 Mario Limonciello <mario.limonciello@....com>,
 platform-driver-x86@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] platform/x86: dell-pc: Transition to faux device

Hi Kurt,

On 23-Apr-25 6:14 PM, Kurt Borja wrote:
> Hi all,
> 
> On Wed Apr 23, 2025 at 10:44 AM -03, Hans de Goede wrote:
>> Hi Ilpo,
>>
>> On 23-Apr-25 3:27 PM, Ilpo Järvinen wrote:
>>> On Fri, 11 Apr 2025, Kurt Borja wrote:
>>>
>>>> Use a faux device parent for registering the platform_profile instead of
>>>> a "fake" platform device.
>>>>
>>>> The faux bus is a minimalistic, single driver bus designed for this
>>>> purpose.
>>>
>>> Hi Kurt, Hans & Greg,
>>>
>>> I'm not sure about this change. So dell-pc not a platform device but
>>> a "fake".
>>
>> Arguably the dell-pc driver does not need a struct device at all,
>> since it just exports /sys/firmware/acpi/platform_profile sysfs
>> interface by using the relevant Dell SMBIOS interfaces for this.
>>
>> As such maybe we should just completely get rid of the whole
>> struct device here?
>>
>> If we do decide to keep the struct device, then since the struct device
>> seems to just be there to tie the lifetime of the platform_profile
>> handler to, I guess that calling it a faux device is fair.
> 
> I think it's important to mention that a parent device is required to
> register a platform profile, see [1].

Ah ok, that is new, I guess that was changed with the new support
for registering multiple platform-profile handlers.

> I guess we could get away with removing the device altogether from here,
> but that would require to find another suitable parent device. The
> obvious choice would be the `dell-smbios` device, however that would
> require exporting it in the first place.
> 
> For some reason, exporting devices doesn't seem right to me, so IMO a
> faux device is a good choice here.

Agreed.

> Another solution that would make more sense, lifetime wise, is to turn
> this into an aux driver and let `dell-smbios` create the matching aux
> device. I could do this, but I think it's overly complicated.

Yes that does seem overly complicated, lets just go with the faux
device.

Regards,

Hans




>>> Is it just because this driver only happens to call
>>> dell_send_request(), etc., not contains that low-level access code within? 
>>> Or is that dell-smbios "fake" too?
> 
> IMO `dell-smbios` is "fake" too? It is there only to expose either the
> WMI or the SMM backend through a single sysfs interface.
> 
> I think a more natural design for `dell-smbios` would be an aux driver
> that exposed it's interface through a class device. Maybe I'm wrong in
> this regard though.
> 
> [1] https://elixir.bootlin.com/linux/v6.15-rc3/source/drivers/acpi/platform_profile.c#L556
>