public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Mario Limonciello" <mario.limonciello@amd.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	"Len Brown" <lenb@kernel.org>,
	"Maximilian Luz" <luzmaximilian@gmail.com>,
	"Lee Chun-Yi" <jlee@suse.com>,
	"Shyam Sundar S K" <Shyam-sundar.S-k@amd.com>,
	"Corentin Chary" <corentin.chary@gmail.com>,
	"Luke D . Jones" <luke@ljones.dev>,
	"Ike Panhc" <ike.pan@canonical.com>,
	"Henrique de Moraes Holschuh" <hmh@hmh.eng.br>,
	"Alexis Belmonte" <alexbelm48@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Ai Chao" <aichao@kylinos.cn>, "Gergo Koteles" <soyer@irl.hu>,
	"open list" <linux-kernel@vger.kernel.org>,
	"open list:ACPI" <linux-acpi@vger.kernel.org>,
	"open list:MICROSOFT SURFACE PLATFORM PROFILE DRIVER"
	<platform-driver-x86@vger.kernel.org>,
	"open list:THINKPAD ACPI EXTRAS DRIVER"
	<ibm-acpi-devel@lists.sourceforge.net>,
	"Mark Pearson" <mpearson-lenovo@squebb.ca>,
	"Matthew Schwartz" <matthew.schwartz@linux.dev>
Subject: Re: [PATCH 7/8] ACPI: platform_profile: Add support for multiple handlers
Date: Sat, 26 Oct 2024 12:30:02 +0200	[thread overview]
Message-ID: <bcf83d6a-2e8d-4829-9c38-17459a2687ed@redhat.com> (raw)
In-Reply-To: <20241025193055.2235-8-mario.limonciello@amd.com>

Hi Mario,

On 25-Oct-24 9:30 PM, Mario Limonciello wrote:
> Multiple drivers may attempt to register platform profile handlers,
> but only one may be registered and the behavior is non-deterministic
> for which one wins.  It's mostly controlled by probing order.
> 
> This can be problematic if one driver changes CPU settings and another
> driver notifies the EC for changing fan curves.
> 
> Modify the ACPI platform profile handler to let multiple drivers
> register platform profile handlers and abstract this detail from userspace.
> 
> From userspace perspective the user will see profiles available across
> both drivers.  However to avoid chaos only allow changing to profiles
> that are common in both drivers.
> 
> If any problems occur when changing profiles for any driver, then revert
> back to the previous profile.
> 
> Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
>  drivers/acpi/platform_profile.c | 203 ++++++++++++++++++--------------
>  1 file changed, 117 insertions(+), 86 deletions(-)
> 
> diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c
> index 091ca6941a925..915e3c49f0b5f 100644
> --- a/drivers/acpi/platform_profile.c
> +++ b/drivers/acpi/platform_profile.c
> @@ -9,7 +9,6 @@
>  #include <linux/platform_profile.h>
>  #include <linux/sysfs.h>
>  
> -static struct platform_profile_handler *cur_profile;
>  static LIST_HEAD(platform_profile_handler_list);
>  static DEFINE_MUTEX(profile_lock);
>  
> @@ -36,26 +35,26 @@ static ssize_t platform_profile_choices_show(struct device *dev,
>  					struct device_attribute *attr,
>  					char *buf)
>  {
> +	struct platform_profile_handler *handler;
> +	unsigned long seen = 0;
>  	int len = 0;
> -	int err, i;
> -
> -	err = mutex_lock_interruptible(&profile_lock);
> -	if (err)
> -		return err;
> -
> -	if (!cur_profile) {
> -		mutex_unlock(&profile_lock);
> -		return -ENODEV;
> +	int i;
> +
> +	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
> +		list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +			for_each_set_bit(i, handler->choices, PLATFORM_PROFILE_LAST) {
> +				if (seen & BIT(i))
> +					continue;
> +				if (len == 0)
> +					len += sysfs_emit_at(buf, len, "%s", profile_names[i]);
> +				else
> +					len += sysfs_emit_at(buf, len, " %s", profile_names[i]);
> +				seen |= BIT(i);
> +			}
> +		}
>  	}

Since only choices that are available in all registered handlers will be accepted,
should the output not be limited to only those choices ?

E.g.:

	unsigned long choices = 0;
	bool first = true;

	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
		list_for_each_entry(handler, &platform_profile_handler_list, list) {
			if (first) {
				choices = handler->choices;
				first = false;
			} else {
				choices &= handler->choices;
			}
		}
	}

	for_each_set_bit(i, choices, PLATFORM_PROFILE_LAST) {
		if (len == 0)
			len += sysfs_emit_at(buf, len, "%s", profile_names[i]);
		else
			len += sysfs_emit_at(buf, len, " %s", profile_names[i]);
	}
  	len += sysfs_emit_at(buf, len, "\n");
  	return len;
}

?

Also this means that choices can change now as drivers get loaded /
removed. I believe that power-profiles-daemon matches has some hotplug
handling for the sysfs files showing up? How would that work with choices
changing ?

Or am I misremembering and does p-p-d simply assume all drivers are loaded
when it starts ?

> @@ -64,22 +63,20 @@ static ssize_t platform_profile_show(struct device *dev,
>  					char *buf)
>  {
>  	enum platform_profile_option profile = PLATFORM_PROFILE_BALANCED;
> +	struct platform_profile_handler *handler;
>  	int err;
>  
> -	err = mutex_lock_interruptible(&profile_lock);
> -	if (err)
> -		return err;
>  
> -	if (!cur_profile) {
> -		mutex_unlock(&profile_lock);
> -		return -ENODEV;
> +	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
> +		if (!platform_profile_is_registered())
> +			return -ENODEV;
> +		list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +			err = handler->profile_get(handler, &profile);
> +			if (err)
> +				return err;
> +		}
>  	}

Hmm this just goes with the platform returned by the last handler
called ?

Maybe compare results and log some warning if there are different
results between handlers ?

And maybe also:

1. New patch enforcing that all handlers must support plain balanced
at registration time.

2. Check that all handlers agree when a new handler gets registered
and if not then force all handlers to balanced, together with
a sysfs_notify() ?


>  
> -	err = cur_profile->profile_get(cur_profile, &profile);
> -	mutex_unlock(&profile_lock);
> -	if (err)
> -		return err;
> -
>  	/* Check that profile is valid index */
>  	if (WARN_ON((profile < 0) || (profile >= ARRAY_SIZE(profile_names))))
>  		return -EIO;
> @@ -91,37 +88,48 @@ static ssize_t platform_profile_store(struct device *dev,
>  			    struct device_attribute *attr,
>  			    const char *buf, size_t count)
>  {
> +	struct platform_profile_handler *handler;
> +	enum platform_profile_option profile;
>  	int err, i;
>  
> -	err = mutex_lock_interruptible(&profile_lock);
> -	if (err)
> -		return err;
> -
> -	if (!cur_profile) {
> -		mutex_unlock(&profile_lock);
> -		return -ENODEV;
> -	}
> -
>  	/* Scan for a matching profile */
>  	i = sysfs_match_string(profile_names, buf);
>  	if (i < 0) {
> -		mutex_unlock(&profile_lock);
>  		return -EINVAL;
>  	}
>  
> -	/* Check that platform supports this profile choice */
> -	if (!test_bit(i, cur_profile->choices)) {
> -		mutex_unlock(&profile_lock);
> -		return -EOPNOTSUPP;
> +	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
> +		if (!platform_profile_is_registered())
> +			return -ENODEV;
> +
> +		/* Check that all handlers support this profile choice */
> +		list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +			if (!test_bit(i, handler->choices))
> +				return -EOPNOTSUPP;
> +
> +			/* save the profile so that it can be reverted if necessary */
> +			err = handler->profile_get(handler, &profile);
> +			if (err)
> +				return err;
> +		}

Same issue as before, you are only saving the profile of the last handler called here,
which might even be a profile not supported by all handlers...

Might be easiest to just enforce all handlers support plain balanced
as I suggested above and then on errors revert all handlers to balanced.

This may seem like it is not nice to do, but errors should not happen
so I think this is ok. And if errors do happen then we need to fix
the errors :)

> +
> +		list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +			err = handler->profile_set(handler, i);
> +			if (err) {
> +				pr_err("Failed to set profile for handler %s\n", handler->name);
> +				break;
> +			}
> +		}
> +		if (err) {
> +			list_for_each_entry_continue_reverse(handler, &platform_profile_handler_list, list) {
> +				if (handler->profile_set(handler, profile))
> +					pr_err("Failed to revert profile for handler %s\n", handler->name);
> +			}
> +			return err;
> +		}
>  	}
>  
> -	err = cur_profile->profile_set(cur_profile, i);
> -	if (!err)
> -		sysfs_notify(acpi_kobj, NULL, "platform_profile");
> -
> -	mutex_unlock(&profile_lock);
> -	if (err)
> -		return err;
> +	sysfs_notify(acpi_kobj, NULL, "platform_profile");
>  	return count;
>  }
>  
> @@ -140,7 +148,8 @@ static const struct attribute_group platform_profile_group = {
>  
>  void platform_profile_notify(void)
>  {
> -	if (!cur_profile)
> +	guard(mutex)(&profile_lock);
> +	if (!platform_profile_is_registered())
>  		return;
>  	sysfs_notify(acpi_kobj, NULL, "platform_profile");
>  }
> @@ -148,40 +157,65 @@ EXPORT_SYMBOL_GPL(platform_profile_notify);
>  
>  int platform_profile_cycle(void)
>  {
> +	struct platform_profile_handler *handler;
>  	enum platform_profile_option profile;
> -	enum platform_profile_option next;
> +	enum platform_profile_option next = PLATFORM_PROFILE_LAST;
> +	enum platform_profile_option next2 = PLATFORM_PROFILE_LAST;
>  	int err;
>  
> -	err = mutex_lock_interruptible(&profile_lock);
> -	if (err)
> -		return err;
> -
> -	if (!cur_profile) {
> -		mutex_unlock(&profile_lock);
> -		return -ENODEV;
> -	}
> -
> -	err = cur_profile->profile_get(cur_profile, &profile);
> -	if (err) {
> -		mutex_unlock(&profile_lock);
> -		return err;
> -	}
> -
> -	next = find_next_bit_wrap(cur_profile->choices, PLATFORM_PROFILE_LAST,
> -				  profile + 1);
> -
> -	if (WARN_ON(next == PLATFORM_PROFILE_LAST)) {
> -		mutex_unlock(&profile_lock);
> -		return -EINVAL;
> +	scoped_cond_guard(mutex_intr, return -ERESTARTSYS, &profile_lock) {
> +		/* first pass, make sure all handlers agree on the definition of "next" profile */
> +		list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +
> +			err = handler->profile_get(handler, &profile);
> +			if (err)
> +				return err;
> +
> +			if (next == PLATFORM_PROFILE_LAST)
> +				next = find_next_bit_wrap(handler->choices,
> +							  PLATFORM_PROFILE_LAST,
> +							  profile + 1);
> +			else
> +				next2 = find_next_bit_wrap(handler->choices,
> +							   PLATFORM_PROFILE_LAST,
> +							   profile + 1);
> +
> +			if (WARN_ON(next == PLATFORM_PROFILE_LAST))
> +				return -EINVAL;
> +
> +			if (next2 == PLATFORM_PROFILE_LAST)
> +				continue;
> +
> +			if (next != next2) {
> +				pr_warn("Next profile to cycle to is ambiguous between platform_profile handlers\n");
> +				return -EINVAL;
> +			}
> +			next = next2;
> +		}

Hmm, this seems complicated, I would suggest to factor out the code
to "and" together all the handler's choices which I suggested above
for platform_profile_choices_show() into a helper (with the locking
to be done by the caller) and then call that helper here to get
a choices which is the result if all the choices and-ed together and
simply call find_next_bit_wrap() on the resulting and-ed value ?

Ah I guess another issue is that the handlers may also differ on
which profile they return from handler->profile_get(), so same
issue as in platform_profile_show(). I think this requires
another factored out helper to get a single consistent profile
value for all handlers. Then this helper can be used both in
platform_profile_show() and here to get a "truth" value for the
current active profile and show that / use that as base to pick
the next value.

Note the above approach definitely is going to have issues
if handlers mismatch on which profiles are supported since
you do not skip choices which are only available in one of
the handlers.

> +
> +		/*
> +		 * Second pass: apply "next" to each handler
> +		 * If any failures occur unwind and revert all back to the original profile
> +		 */
> +		list_for_each_entry(handler, &platform_profile_handler_list, list) {
> +			err = handler->profile_set(handler, next);
> +			if (err) {
> +				pr_err("Failed to set profile for handler %s\n", handler->name);
> +				break;
> +			}
> +		}
> +		if (err) {
> +			list_for_each_entry_continue_reverse(handler, &platform_profile_handler_list, list) {
> +				err = handler->profile_set(handler, profile);

Same issue as before, profile contains the profile of the last handler
in the list only.


> +				if (err)
> +					pr_err("Failed to revert profile for handler %s\n", handler->name);
> +			}
> +		}
>  	}
>  
> -	err = cur_profile->profile_set(cur_profile, next);
> -	mutex_unlock(&profile_lock);
> -
> -	if (!err)
> -		sysfs_notify(acpi_kobj, NULL, "platform_profile");
> +	sysfs_notify(acpi_kobj, NULL, "platform_profile");
>  
> -	return err;
> +	return 0;
>  }
>  EXPORT_SYMBOL_GPL(platform_profile_cycle);
>  
> @@ -190,21 +224,19 @@ int platform_profile_register(struct platform_profile_handler *pprof)
>  	int err;
>  
>  	guard(mutex)(&profile_lock);
> -	/* We can only have one active profile */
> -	if (cur_profile)
> -		return -EEXIST;
>  
>  	/* Sanity check the profile handler field are set */
>  	if (!pprof || bitmap_empty(pprof->choices, PLATFORM_PROFILE_LAST) ||
>  		!pprof->profile_set || !pprof->profile_get)
>  		return -EINVAL;
>  
> -	err = sysfs_create_group(acpi_kobj, &platform_profile_group);
> -	if (err)
> -		return err;
> +	if (!platform_profile_is_registered()) {
> +		err = sysfs_create_group(acpi_kobj, &platform_profile_group);
> +		if (err)
> +			return err;
> +	}
>  	list_add_tail(&pprof->list, &platform_profile_handler_list);
>  
> -	cur_profile = pprof;
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(platform_profile_register);
> @@ -215,7 +247,6 @@ int platform_profile_remove(struct platform_profile_handler *pprof)
>  
>  	list_del(&pprof->list);
>  
> -	cur_profile = NULL;
>  	if (!platform_profile_is_registered())
>  		sysfs_remove_group(acpi_kobj, &platform_profile_group);
>  


Regards,

Hans



  reply	other threads:[~2024-10-26 10:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 19:30 [PATCH 0/8] Add support for binding ACPI platform profile to multiple drivers Mario Limonciello
2024-10-25 19:30 ` [PATCH 1/8] ACPI: platform-profile: Add a name member to handlers Mario Limonciello
2024-10-26 10:06   ` Hans de Goede
2024-10-28 10:07   ` Mark Pearson
2024-10-29 19:10   ` Lyndon Sanche
2024-10-25 19:30 ` [PATCH 2/8] platform/surface: aggregator: Add platform handler pointer to device Mario Limonciello
2024-10-26 10:06   ` Hans de Goede
2024-10-27 23:10   ` Maximilian Luz
2024-10-25 19:30 ` [PATCH 3/8] ACPI: platform_profile: Add platform handler argument to platform_profile_remove() Mario Limonciello
2024-10-26 10:07   ` Hans de Goede
2024-10-28 10:08   ` Mark Pearson
2024-10-25 19:30 ` [PATCH 4/8] ACPI: platform_profile: Add a list to platform profile handler Mario Limonciello
2024-10-26 10:07   ` Hans de Goede
2024-10-28 10:09   ` Mark Pearson
2024-10-25 19:30 ` [PATCH 5/8] ACPI: platform_profile: Use guard(mutex) for register/unregister Mario Limonciello
2024-10-26 10:07   ` Hans de Goede
2024-10-28 10:10   ` Mark Pearson
2024-10-29 10:02   ` Ilpo Järvinen
2024-10-25 19:30 ` [PATCH 6/8] ACPI: platform_profile: Only remove group when no more handler registered Mario Limonciello
2024-10-26 10:07   ` Hans de Goede
2024-10-28 10:11   ` Mark Pearson
2024-10-29 10:06   ` Ilpo Järvinen
2024-10-25 19:30 ` [PATCH 7/8] ACPI: platform_profile: Add support for multiple handlers Mario Limonciello
2024-10-26 10:30   ` Hans de Goede [this message]
2024-10-26 12:16     ` Armin Wolf
2024-10-28 11:01   ` Mark Pearson
2024-10-28 14:10     ` Mario Limonciello
2024-10-28 16:51       ` Armin Wolf
2024-10-28 17:01         ` Mario Limonciello
2024-10-28 17:20       ` Mark Pearson
2024-10-28 17:35         ` Mario Limonciello
2024-10-28 20:11           ` Mark Pearson
2024-10-28 20:15             ` Mario Limonciello
2024-10-25 19:30 ` [PATCH 8/8] platform/x86/amd: pmf: Drop all quirks Mario Limonciello

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=bcf83d6a-2e8d-4829-9c38-17459a2687ed@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=aichao@kylinos.cn \
    --cc=alexbelm48@gmail.com \
    --cc=corentin.chary@gmail.com \
    --cc=hmh@hmh.eng.br \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=ike.pan@canonical.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jlee@suse.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke@ljones.dev \
    --cc=luzmaximilian@gmail.com \
    --cc=mario.limonciello@amd.com \
    --cc=matthew.schwartz@linux.dev \
    --cc=mpearson-lenovo@squebb.ca \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=soyer@irl.hu \
    --cc=u.kleine-koenig@pengutronix.de \
    /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