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: <2025042314-grub-savage-3894@gregkh>
Date: Wed, 23 Apr 2025 15:59:16 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Kurt Borja <kuurtb@...il.com>, 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

On Wed, Apr 23, 2025 at 03:44:56PM +0200, 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'm not saying this is wrong, but feel I'm a bit just lost where the 
> > dividing line is.
> 
> In this case it seems to be clear that this is a faux device,
> but I do agree that sometimes the line can be a bit blurry.

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.

hope this helps,

greg k-h