[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hW1B7XmU16PHRE2B6z2e-qs=X8m4v8qb--MUttiPuGqw@mail.gmail.com>
Date: Mon, 27 Mar 2023 18:16:41 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: rafael@...nel.org, amitk@...nel.org,
"open list:THERMAL" <linux-pm@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>, rui.zhang@...el.com
Subject: Re: [PATCH v1 09/11] thermal/core: Add a linked device parameter
On Tue, Mar 7, 2023 at 2:38 PM Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
>
> Some drivers want to create a link from the thermal zone to the device
> sysfs entry and vice versa.
Which device is this, exactly?
> That is the case of the APCI driver.
>
> Having a backpointer from the device to the thermal zone sounds akward
> as we can have the same device instantiating multiple thermal zones so
> there will be a conflict while creating the second link with the same
> name. Moreover, the userspace has enough information to build the
> dependency from the thermal zone device link without having this cyclic
> link from the device to thermal zone.
>
> Anyway, everything in its time.
>
> This change allows to create a these cyclic links tz <-> device as
> ACPI does and will allow to remove the code in the ACPI driver.
Well, I'd rather have it in the driver than in the core TBH.
If ACPI is the only user of this, let it do the dirty thing by itself.
There are two cases which would justify making this change:
1. There will be more users of it going forward (seems unlikely from
the description).
2. It gets in the way of some other changes somehow.
I kind of expect 2. to be the case, so how does it get in the way?
Powered by blists - more mailing lists