Re: [PATCH v2 11/15] ACPI: platform_profile: Set profile for all registered handlers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/29/2024 11:50, Ilpo Järvinen wrote:
On Tue, 29 Oct 2024, Mario Limonciello wrote:

On 10/29/2024 05:22, Ilpo Järvinen wrote:
On Sun, 27 Oct 2024, Mario Limonciello wrote:

If multiple platform profile handlers have been registered then when
setting a profile verify that all profile handlers support the requested
profile and set it to each handler.

If this fails for any given handler, revert all profile handlers back to
balanced and log an error into the kernel ring buffer.

Tested-by: Matthew Schwartz <matthew.schwartz@xxxxxxxxx>
Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
---
   drivers/acpi/platform_profile.c | 47 ++++++++++++++++++---------------
   1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/drivers/acpi/platform_profile.c
b/drivers/acpi/platform_profile.c
index a83842f05022b..db2ebd0393cf7 100644
--- a/drivers/acpi/platform_profile.c
+++ b/drivers/acpi/platform_profile.c
@@ -105,37 +105,42 @@ static ssize_t platform_profile_store(struct device
*dev,
   			    struct device_attribute *attr,
   			    const char *buf, size_t count)
   {
+	struct platform_profile_handler *handler;
+	unsigned long choices;
   	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) {

You made guard() conversions in the earlier patch but for some reason
left scoped_cond_guard() ones mixed into other changes still. Is there
a very good reason for that?


Using scoped_cond_guard() requires changing the indentation which meant a bit
of back and forth with code coming and going.  If you think it makes more
sense to split up even considering the indentation changes I'll do another set
of patches for the scoped_cond_guard changes only.

There are ways to combat indentation changes while reviewing. However,
it's a strange argument to bring up because now there are indentation
changes in these patches exactly because you chose to make the
scoped_cond_guard() change "while at it" rather than in a separate patch.

I believe the patches will become cleaner and easier to review if you do
scoped_cond_guard() change separate from any other logic changes.

OK will do.





[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux