From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Kurt Borja <kuurtb@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Lyndon Sanche <lsanche@lyndeno.ca>,
Mario Limonciello <mario.limonciello@amd.com>,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] platform/x86: dell-pc: Transition to faux device
Date: Thu, 24 Apr 2025 14:57:01 +0300 (EEST) [thread overview]
Message-ID: <310fae71-d3b7-51b8-6012-c73b2ba7e282@linux.intel.com> (raw)
In-Reply-To: <3ae149b5-a936-45b4-8887-eb7cde1ee4b0@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]
On Wed, 23 Apr 2025, Hans de Goede wrote:
> On 23-Apr-25 6:14 PM, Kurt Borja wrote:
> > On Wed Apr 23, 2025 at 10:44 AM -03, Hans de Goede wrote:
> >> 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.
Well, that was what caused part of my confusion / uncertainty here as
I could see that aux bus between these two drivers. Obviously, it's not
there currently but conceptually this relationship looks what full-blown
aux bus was supposed to solve.
The other part was that as per Greg's simple classification, certainly
this driver needs to access platform resources. BUT, that access is routed
through another driver which is a case his answer/classification did not
cover.
> > I could do this, but I think it's overly complicated.
>
> Yes that does seem overly complicated, lets just go with the faux
> device.
Okay. In part, this was also to check whether replacing full-blown aux bus
with faux should be considered another kind of "abuse". I've no problem
with accepting faux for cases like this as I see these as policy /
convention decision more than one being right and another wrong. :-)
Thanks to all who answered.
--
i.
next prev parent reply other threads:[~2025-04-24 11:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 14:36 [PATCH 0/3] platform/x86: dell-pc: Transition to faux device Kurt Borja
2025-04-11 14:36 ` [PATCH 1/3] platform/x86: dell-pc: Propagate errors when detecting feature support Kurt Borja
2025-04-11 14:36 ` [PATCH 2/3] platform/x86: dell-pc: Use non-atomic bitmap operations Kurt Borja
2025-04-11 14:36 ` [PATCH 3/3] platform/x86: dell-pc: Transition to faux device Kurt Borja
2025-04-23 13:27 ` Ilpo Järvinen
2025-04-23 13:44 ` Hans de Goede
2025-04-23 13:59 ` Greg Kroah-Hartman
2025-04-23 14:12 ` Lyndon Sanche
2025-04-23 16:14 ` Kurt Borja
2025-04-23 17:05 ` Hans de Goede
2025-04-24 11:57 ` Ilpo Järvinen [this message]
2025-04-25 7:48 ` Kurt Borja
2025-04-25 11:50 ` Ilpo Järvinen
2025-04-24 14:06 ` [PATCH 0/3] " Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=310fae71-d3b7-51b8-6012-c73b2ba7e282@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=kuurtb@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lsanche@lyndeno.ca \
--cc=mario.limonciello@amd.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.