i915 will soon gain an eviction path that trylock a whole lot of locks
for eviction, getting dmesg failures like below:

  BUG: MAX_LOCK_DEPTH too low!
  turning off the locking correctness validator.
  depth: 48  max: 48!
  48 locks held by i915_selftest/5776:
   #0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160
   #1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915]
   #2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915]
   #3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915]
   #4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
   #5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
  ...
   #46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
   #47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
  INFO: lockdep is turned off.

Fixing eviction to nest into ww_class_acquire is a high priority, but
it requires a rework of the entire driver, which can only be done one
step at a time.

As an intermediate solution, add an acquire context to
ww_mutex_trylock, which allows us to do proper nesting annotations on
the trylocks, making the above lockdep splat disappear.

This is also useful in regulator_lock_nested, which may avoid dropping
regulator_nesting_mutex in the uncontended path, so use it there.

TTM may be another user for this, where we could lock a buffer in a
fastpath with list locks held, without dropping all locks we hold.

[peterz: rework actual ww_mutex_trylock() implementations]
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net

vctrl_enable() and vctrl_disable() call regulator_enable() and
regulator_disable(), respectively. However, vctrl_* are regulator ops
and should not be calling the locked regulator APIs. Doing so results in
a lockdep warning.

Instead of exporting more internal regulator ops, model the ctrl supply
as an actual supply to vctrl-regulator. At probe time this driver still
needs to use the consumer API to fetch its constraints, but otherwise
lets the regulator core handle the upstream supply for it.

The enable/disable/is_enabled ops are not removed, but now only track
state internally. This preserves the original behavior with the ops
being available, but one could argue that the original behavior was
already incorrect: the internal state would not match the upstream
supply if that supply had another consumer that enabled the supply,
while vctrl-regulator was not enabled.

The lockdep warning is as follows:

	WARNING: possible circular locking dependency detected
	5.14.0-rc6 #2 Not tainted
	------------------------------------------------------
	swapper/0/1 is trying to acquire lock:
	ffffffc011306d00 (regulator_list_mutex){+.+.}-{3:3}, at:
		regulator_lock_dependent (arch/arm64/include/asm/current.h:19
					  include/linux/ww_mutex.h:111
					  drivers/regulator/core.c:329)

	but task is already holding lock:
	ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
		regulator_lock_recursive (drivers/regulator/core.c:156
					  drivers/regulator/core.c:263)

	which lock already depends on the new lock.

	the existing dependency chain (in reverse order) is:

	-> #2 (regulator_ww_class_mutex){+.+.}-{3:3}:
	__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
			     include/asm-generic/atomic-long.h:29
			     kernel/locking/mutex.c:103
			     kernel/locking/mutex.c:144
			     kernel/locking/mutex.c:963)
	ww_mutex_lock (kernel/locking/mutex.c:1199)
	regulator_lock_recursive (drivers/regulator/core.c:156
				  drivers/regulator/core.c:263)
	regulator_lock_dependent (drivers/regulator/core.c:343)
	regulator_enable (drivers/regulator/core.c:2808)
	set_machine_constraints (drivers/regulator/core.c:1536)
	regulator_register (drivers/regulator/core.c:5486)
	devm_regulator_register (drivers/regulator/devres.c:196)
	reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
	platform_probe (drivers/base/platform.c:1427)
	[...]

	-> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
	regulator_lock_dependent (include/linux/ww_mutex.h:129
				  drivers/regulator/core.c:329)
	regulator_enable (drivers/regulator/core.c:2808)
	set_machine_constraints (drivers/regulator/core.c:1536)
	regulator_register (drivers/regulator/core.c:5486)
	devm_regulator_register (drivers/regulator/devres.c:196)
	reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
	[...]

	-> #0 (regulator_list_mutex){+.+.}-{3:3}:
	__lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
			kernel/locking/lockdep.c:3174 (discriminator 4)
			kernel/locking/lockdep.c:3789 (discriminator 4)
			kernel/locking/lockdep.c:5015 (discriminator 4))
	lock_acquire (arch/arm64/include/asm/percpu.h:39
		      kernel/locking/lockdep.c:438
		      kernel/locking/lockdep.c:5627)
	__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
			     include/asm-generic/atomic-long.h:29
			     kernel/locking/mutex.c:103
			     kernel/locking/mutex.c:144
			     kernel/locking/mutex.c:963)
	mutex_lock_nested (kernel/locking/mutex.c:1125)
	regulator_lock_dependent (arch/arm64/include/asm/current.h:19
				  include/linux/ww_mutex.h:111
				  drivers/regulator/core.c:329)
	regulator_enable (drivers/regulator/core.c:2808)
	vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
	_regulator_do_enable (drivers/regulator/core.c:2617)
	_regulator_enable (drivers/regulator/core.c:2764)
	regulator_enable (drivers/regulator/core.c:308
			  drivers/regulator/core.c:2809)
	_set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
	dev_pm_opp_set_rate (drivers/opp/core.c:1164)
	set_target (drivers/cpufreq/cpufreq-dt.c:62)
	__cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
				 drivers/cpufreq/cpufreq.c:2271)
	cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
	cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
	subsys_interface_register (drivers/base/bus.c:?)
	cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
	dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
	[...]

	other info that might help us debug this:

	Chain exists of:
	  regulator_list_mutex --> regulator_ww_class_acquire --> regulator_ww_class_mutex

	 Possible unsafe locking scenario:

	       CPU0                    CPU1
	       ----                    ----
	  lock(regulator_ww_class_mutex);
				       lock(regulator_ww_class_acquire);
				       lock(regulator_ww_class_mutex);
	  lock(regulator_list_mutex);

	 *** DEADLOCK ***

	6 locks held by swapper/0/1:
	#0: ffffff8002d32188 (&dev->mutex){....}-{3:3}, at:
		__device_driver_lock (drivers/base/dd.c:1030)
	#1: ffffffc0111a0520 (cpu_hotplug_lock){++++}-{0:0}, at:
		cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2792 (discriminator 2))
	#2: ffffff8002a8d918 (subsys mutex#9){+.+.}-{3:3}, at:
		subsys_interface_register (drivers/base/bus.c:1033)
	#3: ffffff800341bb90 (&policy->rwsem){+.+.}-{3:3}, at:
		cpufreq_online (include/linux/bitmap.h:285
				include/linux/cpumask.h:405
				drivers/cpufreq/cpufreq.c:1399)
	#4: ffffffc011f0b7b8 (regulator_ww_class_acquire){+.+.}-{0:0}, at:
		regulator_enable (drivers/regulator/core.c:2808)
	#5: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
		regulator_lock_recursive (drivers/regulator/core.c:156
		drivers/regulator/core.c:263)

	stack backtrace:
	CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc6 #2 7c8f8996d021ed0f65271e6aeebf7999de74a9fa
	Hardware name: Google Scarlet (DT)
	Call trace:
	dump_backtrace (arch/arm64/kernel/stacktrace.c:161)
	show_stack (arch/arm64/kernel/stacktrace.c:218)
	dump_stack_lvl (lib/dump_stack.c:106 (discriminator 2))
	dump_stack (lib/dump_stack.c:113)
	print_circular_bug (kernel/locking/lockdep.c:?)
	check_noncircular (kernel/locking/lockdep.c:?)
	__lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
			kernel/locking/lockdep.c:3174 (discriminator 4)
			kernel/locking/lockdep.c:3789 (discriminator 4)
			kernel/locking/lockdep.c:5015 (discriminator 4))
	lock_acquire (arch/arm64/include/asm/percpu.h:39
		      kernel/locking/lockdep.c:438
		      kernel/locking/lockdep.c:5627)
	__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
			     include/asm-generic/atomic-long.h:29
			     kernel/locking/mutex.c:103
			     kernel/locking/mutex.c:144
			     kernel/locking/mutex.c:963)
	mutex_lock_nested (kernel/locking/mutex.c:1125)
	regulator_lock_dependent (arch/arm64/include/asm/current.h:19
				  include/linux/ww_mutex.h:111
				  drivers/regulator/core.c:329)
	regulator_enable (drivers/regulator/core.c:2808)
	vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
	_regulator_do_enable (drivers/regulator/core.c:2617)
	_regulator_enable (drivers/regulator/core.c:2764)
	regulator_enable (drivers/regulator/core.c:308
			  drivers/regulator/core.c:2809)
	_set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
	dev_pm_opp_set_rate (drivers/opp/core.c:1164)
	set_target (drivers/cpufreq/cpufreq-dt.c:62)
	__cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
				 drivers/cpufreq/cpufreq.c:2271)
	cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
	cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
	subsys_interface_register (drivers/base/bus.c:?)
	cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
	dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
	[...]
Reported-by: NBrian Norris <briannorris@chromium.org>
Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Fixes: e9153311 ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Signed-off-by: NChen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

In commit e9153311 ("regulator: vctrl-regulator: Avoid deadlock getting
and setting the voltage"), all calls to get/set the voltage of the
control regulator were switched to unlocked versions to avoid deadlocks.
However, the call in the probe path is done without regulator locks
held. In this case the locked version should be used.

Switch back to the locked regulator_get_voltage() in the probe path to
avoid any mishaps.

Fixes: e9153311 ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Signed-off-by: NChen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-2-wenst@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

The helper to send IRQ notification for regulator errors had still
old description mentioning calling BUG() as a last resort when
error status reading has kept failing for more times than a given
threshold.

The impementation calling BUG() did never end-up in-tree but was
replaced by hopefully more sophisticated handler trying to power-off
the system.

Fix the documentation to reflect actual behaviour.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomainSigned-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210806091058.141-6-alistair@alistair23.meSigned-off-by: NMark Brown <broonie@kernel.org>

Instead of storing the GPIO state in the mfd (where it isn't used) store
it in the regulator.
Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210803084456.198-7-alistair@alistair23.meSigned-off-by: NMark Brown <broonie@kernel.org>

Use the parent's MFD data instead of our data.
Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210803084456.198-6-alistair@alistair23.meSigned-off-by: NMark Brown <broonie@kernel.org>

From testing on hardware the poll_enable_time isn't required and
sometimes causes the driver probe to fail so let's remove it.
Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210803084456.198-5-alistair@alistair23.meSigned-off-by: NMark Brown <broonie@kernel.org>

Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently. Since the register map
is small, we use a FLAT regmap cache.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20210803165211.3b00db29@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently. Since the register map
is small -- there's only one register in sy8824c and sy8824e, there
are only two registers in sy20276 and sy20278, so we use a FLAT regmap
cache.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20210803165043.042ec24d@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

Add empty space and put constant number to the right side for 'if' judgement.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1627648326-5026-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The arrays containing the regulator's voltage ranges are
currently named after the first ldo which uses such range.

However, it sounds a lot clearer if those are named with
the voltage range instead.

No functional changes.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/1bdff1d1f23753b69c8044160decfad1e8553d08.1627121912.git.mchehab+huawei@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

As lowercase is generally preferred for node names, while it is
not too late, change the LDO DT properties to lower case.
Suggested-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/395510cffeb39aebd1763cc5de1cb00a2c40e461.1627121912.git.mchehab+huawei@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Instead of returning error directly, use dev_err_probe. This avoids
messages in the dmesg log for devices which will be probed again later.
Signed-off-by: NChris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20210721165716.19915-1-macroalpha82@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This adds support for Richtek RTQ2134 SubPMIC.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1626422636-29458-2-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

There are a couple of spelling mistakes in the Kconfig text. Fix them.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210719103429.15544-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Reg will be reset in below two conditions.
1. 'Enable' pin from H to L.
2. Both PAVDD and NAVDD are all disabled.

And 'Enable' pin also control i2c communication capability.

This patch is to Seperate the if condition in enable/disable callback for
reg cache manipulation.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1626407746-23156-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

In addition to the ability of merging some power outputs, this chip has
an overdrive mode.
BCORE1, BCORE2 and BPRO have this ability, in which case the legal
current draw is increased from 2 amps to 2.5 amps (at the expense of
a quiescent current increase), and the configurable current limits
are doubled.
If a current higher than maximum half-current mode is requested, enable
overdrive, and scale the current limit down.
Symmetrically, scale the current limit up when querying a overdrive-enabled
regulator.
Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/824518e6391b783a12eba9ff0527f06607a34bfb.1626160826.git.plr.vincent@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Don't populate the const array func_base on the stack but instead it
static. Makes the object code smaller by 55 bytes:

Before:
   text    data     bss     dec    hex filename
   6422    3216      64    9702   25e6 drivers/regulator/rt6245-regulator.o

After:
   text    data     bss     dec    hex filename
   6303    3280      64    9647   25af drivers/regulator/rt6245-regulator.o

Reduction of 55 bytes

(gcc version 10.3.0)
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210715141531.27672-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix the typo for reg define and author name.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Reported-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/1626230170-13648-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The ROHM BD71837/47/50/78 do support enabling/disabling the under/over
voltage protection. Add support for enabling/disabling the protection
according to the device-tree information.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210705105416.GA1189560@localhost.localdomainSigned-off-by: NMark Brown <broonie@kernel.org>

Resolve following checkpatch issue,
Replace symbolic permissions with octal permissions
Signed-off-by: NJinchao Wang <wjc@cdjrlc.com>
Link: https://lore.kernel.org/r/20210626102454.54931-1-wjc@cdjrlc.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add suport for Richtek RTQ6752.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1625845236-30285-2-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Instead of linear mapping, Use linear range to map all voltage selection.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/1625553939-9109-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The TPS65910 regulator now gets a deferred probe until supply regulator is
registered. Silence noisy error message about the deferred probe.

Reported-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210705201211.16082-1-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The shift setting can be calculated via the corresponding mask field,
so remove modeset_shift.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210629130503.2183574-3-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

The shift setting can be calculated via the corresponding mask field,
so remove these shift fields.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210629130503.2183574-2-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

The shift setting can be calculated via the corresponding mask field,
so remove these shift fields.

The usage of da_vsel_mask is different from other mask defines because
current code does shift regval before mask with the da_vsel_mask.
Do proper shit to da_vsel_mask setting so we can calculate the shift.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210629130503.2183574-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

This API hook isn't used anywhere outside of the regulator devres code.
This function is needed for the devm_regulator_bulk_register_supply_alias()
function on the error path, to cleanup any previously registered supply
aliases.

This change makes the devm_regulator_unregister_supply_alias() local to the
regulator core framework, to avoid it being used in any weird logic.
It's also removing the doc-string for
devm_regulator_unregister_supply_alias(), since it doesn't need to be
documented anymore, as no other external consumer should use it.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625122324.327585-5-aardelean@deviqon.comSigned-off-by: NMark Brown <broonie@kernel.org>

This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.

For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.

Removing this also discourages any weird logic that could be created with
such an API function.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625122324.327585-4-aardelean@deviqon.comSigned-off-by: NMark Brown <broonie@kernel.org>

This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.

For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.

Removing this also discourages any weird logic that could be created with
such an API function.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625122324.327585-3-aardelean@deviqon.comSigned-off-by: NMark Brown <broonie@kernel.org>

The Huawei's copyright is missing a dot at the end. Add it,
in order to make it similar to the other two copyrights.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/e9c0f27688d7be75652800e67c913878fd772cbe.1625211021.git.mchehab+huawei@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Since config.dev = pdev->dev.parent in current code, so
dev_get_drvdata(rdev->dev.parent) call in hi6421_regulator_enable
returns the drvdata of the mfd device rather than the regulator. Fix it.

This was broken while converting to use simplified DT parsing because the
config.dev changed from pdev->dev to pdev->dev.parent for parsing the
parent's of_node.

Fixes: 29dc269a ("regulator: hi6421: Convert to use simplified DT parsing")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210630095959.2411543-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

If use dev->parent, the regulator_unregister will not be called when this
driver is unloaded. Fix it by using dev instead.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210702142140.2678130-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix trivial copy-paste typo.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210623153443.623856-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Since config.dev = pdev->dev.parent in current code, so
dev_get_drvdata(rdev->dev.parent) actually returns the drvdata of the mfd
device rather than the regulator. Fix it.

Fixes: 9bc146ac ("regulator: hi6421v600: Fix setting wrong driver_data")
Reported-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Tested-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210630074246.2305166-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix wrong mask for strobe-polarity-high.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
In-reply-to: <CAFRkauB=0KwrJW19nJTTagdHhBR=V2R8YFWG3R3oVXt=rBRsqw@mail.gmail.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/1624723112-26653-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The boolean variable may_have_irqs is not ininitialized and is
only being set to true in the case where chip is ROHM_CHIP_TYPE_BD9576.
Fix this by ininitialized may_have_irqs to false.

Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: e7bf1fa5 ("regulator: bd9576: Support error reporting")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210622144730.22821-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix build error if REGMAP_I2C is not set.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210622141526.472175-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use DIV_ROUND_UP to prevent truncation by integer division issue.
This ensures we return enough delay time.

Also fix returning negative value when new_sel < old_sel.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>