linux-stable/include
Douglas Anderson 5451781dad
regulator: core: Only count load for enabled consumers
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.

Up to this point the regulator framework has continued to count a
consumer's load request for disabled regulators.  This has led to code
patterns that look like this:

  enable_my_thing():
    regular_set_load(reg, load_uA)
    regulator_enable(reg)

  disable_my_thing():
    regulator_disable(reg)
    regulator_set_load(reg, 0)

Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead
of setting a 0 uA load.  I will make the assertion that nearly all (if
not all) places where we set a nominal load of 100 uA or less we end
up with a result that is the same as if we had set a load of 0 uA.
Specifically:
- The whole point of setting the load is to help set the operating
  mode of the regulator.  Higher loads may need less efficient
  operating modes.
- The only time this matters at all is if there is another consumer of
  the regulator that wants the regulator on.  If there are no other
  consumers of the regulator then the regulator will turn off and we
  don't care about the operating mode.
- If there's another consumer that actually wants the regulator on
  then presumably it is requesting a load that makes our nominal
  <= 100 uA load insignificant.

A quick survey of the existing callers to regulator_set_load() to see
how everyone uses it:

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-22 14:38:00 +00:00
..
acpi pci-v4.20-changes 2018-10-25 06:50:48 -07:00
asm-generic percpu: remove PER_CPU_DEF_ATTRIBUTES macro 2018-10-31 08:54:14 -07:00
clocksource
crypto KEYS: asym_tpm: extract key size & public key [ver #2] 2018-10-26 09:30:46 +01:00
drm drm, i915, amdgpu, bridge + core quirk 2018-11-02 10:58:20 -07:00
dt-bindings This time it looks like a quieter release cycle in the clk tree. I guess that's 2018-10-31 11:08:30 -07:00
keys KEYS: Move trusted.h to include/keys [ver #2] 2018-10-26 09:30:47 +01:00
kvm
linux regulator: core: Only count load for enabled consumers 2018-11-22 14:38:00 +00:00
math-emu
media media updates for v4.20-rc1 2018-10-31 10:53:29 -07:00
memory
misc
net net: drop a space before tabs 2018-10-31 12:37:12 -07:00
pcmcia
ras
rdma First merge window pull request 2018-10-26 07:38:19 -07:00
scsi
soc ARM: SoC driver updates for 4.17 2018-10-29 15:16:01 -07:00
sound ASoC: Updates for v5.0/v4.20 2018-10-22 23:26:37 +02:00
target
trace Merge branch 'work.afs' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs 2018-11-01 19:58:52 -07:00
uapi Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 2018-11-03 18:13:43 -07:00
video
xen Merge branch 'x86-paravirt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 2018-10-23 17:54:58 +01:00