linux-kernel - Re: [PATCH 2/2] regulator: Optimise out noop voltage changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <3bf69fb1c4f33c8a1f405b4f05ba1a59.squirrel@www.codeaurora.org>
Date:	Thu, 16 Dec 2010 17:46:07 -0800 (PST)
From:	"Saravana Kannan" <skannan@...eaurora.org>
To:	"Mark Brown" <broonie@...nsource.wolfsonmicro.com>
Cc:	"Saravana Kannan" <skannan@...eaurora.org>,
	"Liam Girdwood" <lrg@...mlogic.co.uk>,
	linux-kernel@...r.kernel.org, patches@...nsource.wolfsonmicro.com,
	"Mark Brown" <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH 2/2] regulator: Optimise out noop voltage changes


> Reported-by: Saravana Kannan <skannan@...eaurora.org>
Thanks

>  int regulator_set_voltage(struct regulator *regulator, int min_uV, int
> max_uV)
>  {
>  	struct regulator_dev *rdev = regulator->rdev;
> -	int ret;
> +	int ret = 0;
>
>  	mutex_lock(&rdev->mutex);
>
> +	/* If we're setting the same range as last time the change
> +	 * should be a noop (some cpufreq implementations use the same +	 *
voltage for multiple frequencies, for example).
> +	 */
> +	if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
+		goto out;
> +

I have only web email access now. Sorry for the vague references to code
that follow.

When you reported a merge/rebase issue the other day, I didn't respond
with a similar patch for the following reasons:
1. With support for multiple consumers, we can further optimize and call
the producer's set voltage only if the final voltage range changes. So if
consumer A asks for (2.0 - 5.0) and consumer B keeps changing between (1.0
- 5.0) and (1.5 - 5.0), then we can completely no-op all of consumer B's
calls.

2. When I was trying to do the above this Sunday, I also noticed what
looks like a bug or at least an unpleasant behavior. A consumer's min_uV
and max_uV were being updated (for-next around Dec 12th) before calling
the producer's set voltage. So, in the above example, if consumer C comes
in and asks for (10 - 15), it will prevent the producer voltage from ever
changing again. All of consumer A and B's future requests will result in a
failure since min_uV > max_uV when you do the consumer aggregation.

Hope my vague references to code is good enough to point you the code I'm
talking about. May be you already fixed it too!

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/