From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Mark Gross <mgross@linux.intel.com>,
Ike Panhc <ike.pan@canonical.com>,
Mark Pearson <markpearson@lenovo.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] IdeaPad platform profile support
Date: Mon, 4 Jan 2021 21:58:09 +0100 [thread overview]
Message-ID: <6a29f338-d9e4-150c-81dd-2ffb54f5bc35@redhat.com> (raw)
In-Reply-To: <CAJZ5v0jcCD3qWUJQcS+nFVJWSCQEbq2eN3i07mN8yFr3WZD9dg@mail.gmail.com>
Hi,
On 1/4/21 9:33 PM, Rafael J. Wysocki wrote:
> On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 1/1/21 1:56 PM, Jiaxun Yang wrote:
>>> Tested on Lenovo Yoga-14SARE Chinese Edition.
>>>
>>> Jiaxun Yang (2):
>>> ACPI: platform-profile: Introduce data parameter to handler
>>> platform/x86: ideapad-laptop: DYTC Platform profile support
>>>
>>> drivers/acpi/platform_profile.c | 4 +-
>>> drivers/platform/x86/Kconfig | 1 +
>>> drivers/platform/x86/ideapad-laptop.c | 281 ++++++++++++++++++++++++++
>>> include/linux/platform_profile.h | 5 +-
>>> 4 files changed, 287 insertions(+), 4 deletions(-)
>>
>>
>> Thank you for your series, unfortunately the
>> "ACPI: platform-profile: Introduce data parameter to handler"
>> patch causes a conflict with the pending:
>> "[PATCH v8 3/3] platform/x86: thinkpad_acpi: Add platform profile support"
>> patch.
>>
>> But I do agree that adding that data parameter makes sense, so
>> it might be best to merge:
>>
>> "ACPI: platform-profile: Introduce data parameter to handler"
>>
>> First and then rebase the thinkpad_acpi patch on top.
>>
>> Rafael, do you think you could add:
>>
>> "ACPI: platform-profile: Introduce data parameter to handler"
>>
>> To the 2 ACPI: platform-profile patches which you already have pending for 5.11-rc# ?
>
> I'm not sure why that patch is needed at all, because whoever
> registers a platform profile handler needs to have access to the
> original handler object anyway.
True, I was actually thinking that instead of the data argument, we might
pass a pointer to the original handler object like this:
@@ -64,7 +64,7 @@ static ssize_t platform_profile_show(struct device *dev,
return -ENODEV;
}
- err = cur_profile->profile_get(&profile);
+ err = cur_profile->profile_get(cur_profile, &profile);
mutex_unlock(&profile_lock);
if (err)
return err;
And then the driver which has registered the cur_profile, can get to
its own data by using container of on the cur_profile pointer.
With the code currently in your bleeding-edge branch, there is no way
for any driver-code to get to its own (possibly/likely dynamically
allocated) driver-data struct.
E.g. a typical driver using only dynamic data tied to device_get_drvdata,
might have this:
struct driver_data {
...
struct platform_profile_handler profile_handler;
...
};
int probe(...) {
struct driver_data *my_data;
my_data = devm_kzalloc(dev, sizeof(*my_data), GFP_KERNEL);
...
ret = platform_profile_register(&my_data->profile_handler);
...
}
And with the change which I suggest above would then be able to
get the struct driver_data *my_data back from the profile_get callback by
using container_of on the struct platform_profile_handler *profile_handler
argument added to the profile_get callback.
I know that the platform_profile stuff is intended to only have a
single provider, so this could use global variables, but some
drivers which may be a provider use 0 global variables (other then
module_params) atm and it would be a lot cleaner from the pov
of the design of these drivers to be able to do something like the
pseudo code above. Which is why I added my Reviewed-by to patch 1/2
of the series from this thread.
Patch 1/2 does use a slightly different approach then I suggest above,
thinking more about this it would be cleaner IMHO to just pass the
cur_profile pointer to the callbacks as the pseudo-code patch which I
wrote above does. Drivers which use globals can then just ignore
the extra argument (and keep the platform_profile_handler struct const)
where as drivers which use dynamic allocation can embed the struct in
their driver's data-struct.
> Also, on a somewhat related note, I'm afraid that it may not be a good
> idea to push this series for 5.11-rc in the face of recent objections
> against new material going in after the merge window.
That is fine with me, since this did not make rc1 (nor rc2) I'm not entirely
comfortable with sending out a late pull-req for the pdx86 side of this
either, so lets postpone this to 5.12 (sorry Mark).
Rafael, once we have the discussion with the passing a pointer back to
the drivers data thing resolved (and a patch merged for that if we go
that route) can you provide me with an immutable branch to merge into
pdx86/for-next so that I can then merge the pdx86 bits on top ?
Note this does not need to be done right now around say rc4 would be fine,
so that we have some time for the patches currently in bleeding-edge to
settle a bit.
Regards,
Hans
next prev parent reply other threads:[~2021-01-04 20:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-01 12:56 [PATCH 0/2] IdeaPad platform profile support Jiaxun Yang
2021-01-01 12:56 ` [PATCH 1/2] ACPI: platform-profile: Introduce data parameter to handler Jiaxun Yang
2021-01-04 14:34 ` Hans de Goede
2021-01-01 12:56 ` [PATCH 2/2] platform/x86: ideapad-laptop: DYTC Platform profile support Jiaxun Yang
2021-01-04 14:34 ` [PATCH 0/2] IdeaPad platform " Hans de Goede
2021-01-04 20:33 ` Rafael J. Wysocki
2021-01-04 20:58 ` Hans de Goede [this message]
2021-01-04 21:58 ` [External] " Mark Pearson
2021-01-05 6:24 ` Jiaxun Yang
2021-01-05 16:53 ` Mark Pearson
2021-01-05 10:28 ` Hans de Goede
2021-01-05 17:18 ` Rafael J. Wysocki
2021-01-06 9:17 ` Hans de Goede
2021-01-07 13:50 ` Rafael J. Wysocki
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=6a29f338-d9e4-150c-81dd-2ffb54f5bc35@redhat.com \
--to=hdegoede@redhat.com \
--cc=ike.pan@canonical.com \
--cc=jiaxun.yang@flygoat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markpearson@lenovo.com \
--cc=mgross@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).