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: <8943a4f1-37af-4573-b778-90a52732e0f6@app.fastmail.com>
Date: Wed, 23 Apr 2025 08:12:38 -0600
From: "Lyndon Sanche" <lsanche@...deno.ca>
To: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 "Hans de Goede" <hdegoede@...hat.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 "Kurt Borja" <kuurtb@...il.com>,
 "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

On Wed, Apr 23, 2025, at 7:59 AM, Greg Kroah-Hartman wrote:
> On Wed, Apr 23, 2025 at 03:44:56PM +0200, Hans de Goede wrote:
>> 
>> 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 am curious to see what this would look like. If we can get away with not using a struct for this functionality I think that is a good way to keep it simple.

>
> If a device needs access to platform resources, then it is a platform
> device.  If not, then it is not.  Not too complex :)
>
> But (you knew there was a but), many drivers want to detach their
> ability to create a device, and have a driver bind to them, in a
> different "place" in the kernel.  For many of those, they have (ab)used
> the platform driver/device api to achieve this, despite them not being a
> platform device at all.  For these, we can't convert them directly to
> use faux bus, as it's not as simple of a conversion and in some places,
> doesn't work well.  So let's leave those alone for now, but not take any
> more of them going forward in the future.

Right now we are just using the platform device to register a platform profile handler. If we only need the faux bus for that then I think that is a good way to go. I will look into this new faux bus a bit more.

I'll see if I can find some time this evening to run this patch.

Thanks,

Lyndon