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
| ||
|
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/
Powered by blists - more mailing lists