08 Oct, 2020
1 commit
-
* tag 'v5.4.70': (3051 commits)
Linux 5.4.70
netfilter: ctnetlink: add a range check for l3/l4 protonum
ep_create_wakeup_source(): dentry name can change under you...
...Conflicts:
arch/arm/mach-imx/pm-imx6.c
arch/arm64/boot/dts/freescale/imx8mm-evk.dts
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
drivers/crypto/caam/caamalg.c
drivers/gpu/drm/imx/dw_hdmi-imx.c
drivers/gpu/drm/imx/imx-ldb.c
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/enetc/enetc.c
drivers/net/ethernet/freescale/enetc/enetc_pf.c
drivers/thermal/imx_thermal.c
drivers/usb/cdns3/ep0.c
drivers/xen/swiotlb-xen.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.cSigned-off-by: Jason Liu
01 Oct, 2020
1 commit
-
[ Upstream commit fbb5a79d2fe7b01c6424fbbc04368373b1672d61 ]
Currently we wrongly set the mask of value of LDO2/4 both to the mask of
LDO2, and the LDO4 voltage configuration is left untouched. This leads
to conflict when LDO2/4 are both in use.Fix this issue by setting different vsel_mask to both regulators.
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Signed-off-by: Icenowy Zheng
Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.io
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
23 Sep, 2020
1 commit
-
[ Upstream commit 59ae97a7a9e1499c2070e29841d1c4be4ae2994a ]
If the zero duty cycle doesn't correspond to any voltage in the voltage
table, the PWM regulator returns an -EINVAL from get_voltage_sel() which
results in the core erroring out with a "failed to get the current
voltage" and ending up not applying the machine constraints.Instead, return -ENOTRECOVERABLE which makes the core set the voltage
since it's at an unknown value.For example, with this device tree:
fooregulator {
compatible = "pwm-regulator";
pwms = ;
regulator-min-microvolt = ;
regulator-max-microvolt = ;
regulator-name = "fooregulator";
regulator-always-on;
regulator-boot-on;
voltage-table = ;
};Before this patch:
fooregulator: failed to get the current voltage(-22)
After this patch:
fooregulator: Setting 2250000-2250000uV
fooregulator: 2250 mVSigned-off-by: Vincent Whitchurch
Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
17 Sep, 2020
7 commits
-
commit 0a7416f94707c60b9f66b01c0a505b7e41375f3a upstream.
The recent commit 7d8196641ee1 ("regulator: Remove pointer table
overallocation") changed the size of coupled_rdevs and now KASAN is able
to detect slab-out-of-bounds problem in regulator_unlock_recursive(),
which is a legit problem caused by a typo in the code. The recursive
unlock function uses n_coupled value of a parent regulator for unlocking
supply regulator, while supply's n_coupled should be used. In practice
problem may only affect platforms that use coupled regulators.Cc: stable@vger.kernel.org # 5.0+
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Dmitry Osipenko
Link: https://lore.kernel.org/r/20200831204335.19489-1-digetx@gmail.com
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d3c731564e09b6c2ebefcd1344743a91a237d6dc upstream.
By calling device_initialize() earlier and noting that kfree(NULL) is
ok, we can save a bit of code in error handling and plug of_node leak.
Fixed commit already did part of the work.Fixes: 9177514ce349 ("regulator: fix memory leak on error path of regulator_register()")
Signed-off-by: Michał Mirosław
Reviewed-by: Vladimir Zapolskiy
Acked-by: Vladimir Zapolskiy
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 5c06540165d443c6455123eb48e7f1a9b618ab34 upstream.
Pull regulator_list_mutex into set_consumer_device_supply() and keep
allocations outside of it. Fourth of the fs_reclaim deadlock case.Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: Michał Mirosław
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 87fe29b61f9522a3d7b60a4580851f548558186f upstream.
Move all allocations outside of the regulator_lock()ed section.
======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #535 Not tainted
------------------------------------------------------
f2fs_discard-179:7/702 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0but task is already holding lock:
cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
[...]
-> #3 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc_track_caller+0x54/0x218
kstrdup+0x40/0x5c
create_regulator+0xf4/0x368
regulator_resolve_supply+0x1a0/0x200
regulator_register+0x9c8/0x163c[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock[...]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 73a32129f8ccb556704a26b422f54e048bf14bd0 upstream.
Allocating memory with regulator_list_mutex held makes lockdep unhappy
when memory pressure makes the system do fs_reclaim on eg. eMMC using
a regulator. Push the lock inside regulator_init_coupling() after the
allocation.======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc+0x54/0x218
regulator_register+0x860/0x1584
dummy_regulator_probe+0x60/0xa8
[...]
other info that might help us debug this:Chain exists of:
&sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaimPossible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(&sbi->write_io[i][j].io_rwsem);
*** DEADLOCK ***1 lock held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a577f3456c0a2fac3dee037c483753e6e68f3e49 ]
The code modifies rdev, but locks c_rdev instead. Remove the lock
as this is held together by regulator_list_mutex taken in the caller.Fixes: f9503385b187 ("regulator: core: Mutually resolve regulators coupling")
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Link: https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 467bf30142c64f2eb64e2ac67fa4595126230efd ]
Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
kmem_cache_alloc_trace+0x40/0x1e8
regulator_register+0x384/0x1630
devm_regulator_register+0x50/0x84
reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(regulator_list_mutex);*** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
#1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
19 Aug, 2020
1 commit
-
[ Upstream commit 9177514ce34902b3adb2abd490b6ad05d1cfcb43 ]
The change corrects registration and deregistration on error path
of a regulator, the problem was manifested by a reported memory
leak on deferred probe:as3722-regulator as3722-regulator: regulator 13 register failed -517
# cat /sys/kernel/debug/kmemleak
unreferenced object 0xecc43740 (size 64):
comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s)
hex dump (first 32 bytes):
72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a regulator.24.ZZZ
5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
backtrace:
[] __kmalloc_track_caller+0x15c/0x2c0
[] kvasprintf+0x64/0xd4
[] kvasprintf_const+0x70/0x84
[] kobject_set_name_vargs+0x34/0xa8
[] dev_set_name+0x40/0x64
[] regulator_register+0x3a4/0x1344
[] devm_regulator_register+0x4c/0x84
[] as3722_regulator_probe+0x294/0x754
...The memory leak problem was introduced as a side ef another fix in
regulator_register() error path, I believe that the proper fix is
to decouple device_register() function into its two compounds and
initialize a struct device before assigning any values to its fields
and then using it before actual registration of a device happens.This lets to call put_device() safely after initialization, and, since
now a release callback is called, kfree(rdev->constraints) shall be
removed to exclude a double free condition.Fixes: a3cde9534ebd ("regulator: core: fix regulator_register() error paths to properly release rdev")
Signed-off-by: Vladimir Zapolskiy
Cc: Wen Yang
Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
01 Jul, 2020
1 commit
-
[ Upstream commit 6f1cf5257acc6e6242ddf2f52bc7912aed77b79f ]
PFUZE100_SWB_REG is not proper for sw1a/sw2, because enable_mask/enable_reg
is not correct. On PFUZE3000, sw1a/sw2 should be the same as sw1a/sw2 on
pfuze100 except that voltages are not linear, so add new PFUZE3000_SW_REG
and pfuze3000_sw_regulator_ops which like the non-linear PFUZE100_SW_REG
and pfuze100_sw_regulator_ops.Fixes: 1dced996ee70 ("regulator: pfuze100: update voltage setting for pfuze3000 sw1a")
Reported-by: Christophe Meynard
Signed-off-by: Robin Gong
Link: https://lore.kernel.org/r/1592171648-8752-1-git-send-email-yibin.gong@nxp.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
22 Jun, 2020
1 commit
-
[ Upstream commit 906746ba26d0b45688f4c3b730c35f765dc958ba ]
Fix typos in pm8150 l13/l16/l17 and pm8150l ldo8 supplies.
Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
Signed-off-by: Bjorn Andersson
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Link: https://lore.kernel.org/r/20200415053708.717623-1-bjorn.andersson@linaro.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
19 Jun, 2020
1 commit
-
* tag 'v5.4.47': (2193 commits)
Linux 5.4.47
KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
...Conflicts:
arch/arm/boot/dts/imx6qdl.dtsi
arch/arm/mach-imx/Kconfig
arch/arm/mach-imx/common.h
arch/arm/mach-imx/suspend-imx6.S
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
arch/powerpc/include/asm/cacheflush.h
drivers/cpufreq/imx6q-cpufreq.c
drivers/dma/imx-sdma.c
drivers/edac/synopsys_edac.c
drivers/firmware/imx/imx-scu.c
drivers/net/ethernet/freescale/fec.h
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
drivers/net/phy/phy_device.c
drivers/perf/fsl_imx8_ddr_perf.c
drivers/usb/cdns3/gadget.c
drivers/usb/dwc3/gadget.c
include/uapi/linux/dma-buf.hSigned-off-by: Jason Liu
12 Mar, 2020
1 commit
-
commit 02fbabd5f4ed182d2c616e49309f5a3efd9ec671 upstream.
There maybe an overshoot, when disabling, then re-enabling vrefbuf
too quickly. VREFBUF is used by ADC/DAC on some boards. When re-enabling
too quickly, an overshoot on the reference voltage make the conversions
inaccurate for a short period of time.
- Don't put the VREFBUF in HiZ when disabling, to force an active
discharge.
- Enforce a 1ms OFF/ON delayFixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf")
Signed-off-by: Fabrice Gasnier
Message-Id:
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
10 Mar, 2020
2 commits
-
Take account of bypass case where min_dropout_uV is 0 to adjust external
supply voltage correctly, otherwise, external pmic voltage will never be
in ldo bypass mode.Signed-off-by: Robin Gong
Reviewed-by: Anson Huang -
In bypass mode, the anatop digital regulators do not have any minimum
dropout value (the input voltage is equal to the output voltage according
to documentation).Having a min dropout value of 125mV will lead to an increased voltage
for PMIC supplies.Only set minimum dropout value for ldo enabled mode.
Signed-off-by: Irina Tirdea
Signed-off-by: Vipul Kumar
Signed-off-by: Robin Gong
Reviewed-by: Anson Huang
(cherry picked from commit 9092e24ba0dce713e5478c0f925168b00e9e83cb)
08 Mar, 2020
1 commit
-
Merge Linux stable release v5.4.24 into imx_5.4.y
* tag 'v5.4.24': (3306 commits)
Linux 5.4.24
blktrace: Protect q->blk_trace with RCU
kvm: nVMX: VMWRITE checks unsupported field before read-only field
...Signed-off-by: Jason Liu
Conflicts:
arch/arm/boot/dts/imx6sll-evk.dts
arch/arm/boot/dts/imx7ulp.dtsi
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
drivers/clk/imx/clk-composite-8m.c
drivers/gpio/gpio-mxc.c
drivers/irqchip/Kconfig
drivers/mmc/host/sdhci-of-esdhc.c
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
drivers/net/can/flexcan.c
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/net/ethernet/mscc/ocelot.c
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
drivers/net/phy/realtek.c
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
drivers/perf/fsl_imx8_ddr_perf.c
drivers/tee/optee/shm_pool.c
drivers/usb/cdns3/gadget.c
kernel/sched/cpufreq.c
net/core/xdp.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.c
sound/soc/sof/core.c
sound/soc/sof/imx/Kconfig
sound/soc/sof/loader.c
24 Feb, 2020
3 commits
-
[ Upstream commit 3d7610e8da993539346dce6f7c909fd3d56bf4d5 ]
Change the exported symbols introduced by commit e9153311491da
("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for all the core
parts.Fixes: e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Reported-by: Dmitry Osipenko
Signed-off-by: Enric Balletbo i Serra
Link: https://lore.kernel.org/r/20200120123921.1204339-1-enric.balletbo@collabora.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit e9153311491da9d9863ead9888a1613531cb4a1b ]
`cat /sys/kernel/debug/regulator/regulator_summary` ends on a deadlock
when you have a voltage controlled regulator (vctrl).The problem is that the vctrl_get_voltage() and vctrl_set_voltage() calls the
regulator_get_voltage() and regulator_set_voltage() and that will try to lock
again the dependent regulators (the regulator supplying the control voltage).Fix the issue by exporting the unlocked version of the regulator_get_voltage()
and regulator_set_voltage() API so drivers that need it, like the voltage
controlled regulator driver can use it.Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Reported-by: Douglas Anderson
Signed-off-by: Enric Balletbo i Serra
Link: https://lore.kernel.org/r/20200116094543.2847321-1-enric.balletbo@collabora.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit b8a039d37792067c1a380dc710361905724b9b2f ]
RK808 can leverage a couple of GPIOs to tweak the ramp rate during DVS
(Dynamic Voltage Scaling). These GPIOs are entirely optional but a
dev_warn() appeared when cleaning this driver to use a more up-to-date
gpiod API. At least reduce the log level to 'info' as it is totally
fine to not populate these GPIO on a hardware design.This change is trivial but it is worth not polluting the logs during
bringup phase by having real warnings and errors sorted out
correctly.Fixes: a13eaf02e2d6 ("regulator: rk808: make better use of the gpiod API")
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/r/20191203164709.11127-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
11 Feb, 2020
1 commit
-
commit b059b7e0ec3208ff1e17cff6387d75a9fbab4e02 upstream.
Add regulator_is_equal() helper to compare whether two regulators are
the same. This is useful for checking whether two separate regulators
in a driver are actually the same supply.Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Igor Opaniuk
Cc: Liam Girdwood
Cc: Marcel Ziswiler
Cc: Mark Brown
Cc: Oleksandr Suvorov
Link: https://lore.kernel.org/r/20191220164450.1395038-1-marex@denx.de
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
26 Jan, 2020
1 commit
-
[ Upstream commit 55d5f62c3fa005a6a8010363d7d1855909ceefbc ]
The bd70528 regulator driver is probed by MFD driver. Add MODULE_ALIAS
in order to allow udev to load the module when MFD sub-device cell for
regulators is added.Fixes: 99ea37bd1e7d7 ("regulator: bd70528: Support ROHM BD70528 regulator block")
Signed-off-by: Matti Vaittinen
Link: https://lore.kernel.org/r/20191023121452.GA1812@localhost.localdomain
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
12 Jan, 2020
3 commits
-
[ Upstream commit 62a1923cc8fe095912e6213ed5de27abbf1de77e ]
platform device aliases were missing, preventing
autoloading of module.Fixes: 811b700630ff ("regulator: rn5t618: add driver for Ricoh RN5T618 regulators")
Signed-off-by: Andreas Kemnade
Link: https://lore.kernel.org/r/20191211221600.29438-1-andreas@kemnade.info
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit a3cde9534ebdafe18a9bbab208df724c57e6c8e8 ]
There are several issues with the error handling code of
the regulator_register() function:
ret = device_register(&rdev->dev);
if (ret != 0) {
put_device(&rdev->dev); --> rdev released
goto unset_supplies;
}
...
unset_supplies:
...
unset_regulator_supplies(rdev); --> use-after-free
...
clean:
if (dangling_of_gpiod)
gpiod_put(config->ena_gpiod);
kfree(rdev); --> double freeWe add a variable to record the failure of device_register() and
move put_device() down a bit to avoid the above issues.Fixes: c438b9d01736 ("regulator: core: Move registration of regulator device")
Signed-off-by: Wen Yang
Cc: Liam Girdwood
Cc: Mark Brown
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 4affd79a125ac91e6a53be843ea3960a8fc00cbb ]
This is caused by dereferencing 'rdev' after put_device() in
the _regulator_get()/_regulator_put() functions.
This patch just moves the put_device() down a bit to avoid the
issue.Signed-off-by: Wen Yang
Cc: Liam Girdwood
Cc: Mark Brown
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
09 Jan, 2020
4 commits
-
commit 99c4f70df3a6446c56ca817c2d0f9c12d85d4e7c upstream.
The USB regulator was removed for AB8500 in
commit 41a06aa738ad ("regulator: ab8500: Remove USB regulator").
It was then added for AB8505 in
commit 547f384f33db ("regulator: ab8500: add support for ab8505").However, there was never an entry added for it in
ab8505_regulator_match. This causes all regulators after it
to be initialized with the wrong device tree data, eventually
leading to an out-of-bounds array read.Given that it is not used anywhere in the kernel, it seems
likely that similar arguments against supporting it exist for
AB8505 (it is controlled by hardware).Therefore, simply remove it like for AB8500 instead of adding
an entry in ab8505_regulator_match.Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505")
Cc: Linus Walleij
Signed-off-by: Stephan Gerhold
Reviewed-by: Linus Walleij
Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.net
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit f40ddaa059fdfb472e3aeb733c6220d8e0633a47 upstream.
A copy-paste error was introduced when bitmasks were converted to
macros, incorrectly setting the enable bitmask for ELDO2 to the one
for ELDO1 for the AXP22x units.Fix it by using the correct macro.
On affected boards, ELDO1 and/or ELDO2 are used to power the camera,
which is currently unsupported.Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Signed-off-by: Chen-Yu Tsai
Link: https://lore.kernel.org/r/20191218044720.21990-1-wens@kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 6f1ff76154b8b36033efcbf6453a71a3d28f52cd upstream.
The .set_ramp_delay should be for bd70528_buck_ops only.
Setting .set_ramp_delay for for bd70528_ldo_ops causes problem because
BD70528_MASK_BUCK_RAMP (0x10) overlaps with BD70528_MASK_LDO_VOLT (0x1f).
So setting ramp_delay for LDOs may change the voltage output, fix it.Fixes: 99ea37bd1e7d ("regulator: bd70528: Support ROHM BD70528 regulator block")
Signed-off-by: Axel Lin
Acked-by: Matti Vaittinen
Link: https://lore.kernel.org/r/20200101022406.15176-1-axel.lin@ingics.com
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 71dd2fe5dec171b34b71603a81bb46c24c498fde upstream.
Current code set incorrect bits when set ramp_delay for AXP20X_DCDC2,
fix it.Fixes: d29f54df8b16 ("regulator: axp20x: add support for set_ramp_delay for AXP209")
Signed-off-by: Axel Lin
Link: https://lore.kernel.org/r/20191221081049.32490-1-axel.lin@ingics.com
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
31 Dec, 2019
3 commits
-
[ Upstream commit 089b3f61ecfc43ca4ea26d595e1d31ead6de3f7b ]
Boot-on regulators are always kept on because their use_count value
is now incremented at boot time and never cleaned.Only increment count value for alway-on regulators.
regulator_late_cleanup() is now able to power off boot-on regulators
when unused.Fixes: 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies")
Signed-off-by: Pascal Paillet
Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 26c2c997aa1a6c5522f6619910ba025e53e69763 ]
This patch fixes memory leak which should happen if regulator's coupling
fails to initialize.Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: Dmitry Osipenko
Link: https://lore.kernel.org/r/20191025002240.25288-1-digetx@gmail.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 472b39c3d1bba0616eb0e9a8fa3ad0f56927c7d7 ]
Inside function max8907_regulator_probe(), variable val could
be uninitialized if regmap_read() fails. However, val is used
later in the if statement to decide the content written to
"pmic", which is potentially unsafe.Signed-off-by: Yizhuo
Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
24 Dec, 2019
1 commit
-
Some registers on pfuze3000 will lost after exit from LPSR, need restore them,
otherwise system may reboot with below command after system enter LPSR one time:root@imx7d_all:~# echo enabled > /sys/class/tty/ttymxc0/power/wakeup
root@imx7d_all:~# echo mem > /sys/power/statebecause LDOGCTL not recover as 1. Add 'fsl,lpsr-mode' property to this case,
please add this property if your board support LPSR mode as imx7d-12x12-lpddr3-arm2
board.Signed-off-by: Robin Gong
(cherry picked from commit 4aa2a2a92814433d76de1bf6ae8902e46fb87961)
29 Nov, 2019
1 commit
-
Add pca9450 regulator driver.
Signed-off-by: John Lee
Signed-off-by: Robin Gong
Reviewed-by: Anson Huang
(cherry picked from commit 90f61a4155308cfd0e33116540ec0c939204ce73)
28 Nov, 2019
1 commit
-
Add n_voltages/min_uV in regulator description so that no failure return
while regulator_count_voltages() called, which cause vqmmc regulator
voltage switching to 1.8V failure on i.mx7ulp-evk. This issue is exposed
by commit 498209445124 ("regulator: core: simplify return value on
suported_voltage").Signed-off-by: Robin Gong
Reported-by: Haibo Chen
Reviewed-by: Anson Huang
25 Nov, 2019
4 commits
-
At some systems, the pinctrl setting will be lost or needs to
set as "sleep" state to save power consumption. So, we need to
configure pinctrl as "sleep" state when system enters suspend,
and as "default" state after system resumes. In this way, the
pinctrl value can be recovered as "default" state after resuming.Signed-off-by: Peter Chen
Signed-off-by: Vipul Kumar -
Depends on board design, the gpio controlling regulator may
connects with a big capacitance. When need off, it takes some time
to let the regulator to be truly off. If not add enough delay, the
regulator might have always been on, so introduce off-on-delay to
handle such case.Signed-off-by: Peng Fan
Link: https://lore.kernel.org/r/1572311875-22880-3-git-send-email-peng.fan@nxp.com
Signed-off-by: Mark Brown
(cherry picked from commit f7907e57aea2adcd0b57ebcca410e125412ab680) -
The Linux kernel regulator core implementation does not accept negative
voltage values; all negative values are treated as errors.The problem with the EPDC is that the panel uses a negative voltage
regulator which fails to be enabled by the regulator core. This issue has
slipped up until the 4.9 rebase because the voltage range [min, max] was
checked against only when min = max. This has been fixed in 4.9, resulting
in errors in the VCOM regulator driver.The fix is to use the negative values when communicating with the hardware,
but send only positive values to the regulator core.This patch sends the absolute value to the regulator core and transforms
the received value (from the regulator core) to negative one before sending
it to hardware.Fix device tree to deal with negative voltage regulator values by setting
min_value = -real_max_value and vice versa. Boards affected:
- imx6dl-sabresd
- imx6ull-14x14-ddr3-arm2
- imx7d-12x12-lpddr3-arm2
- imx7d-sdb
- imx6sll-evk
- imx6sl-evk
- imx6sll-lpddr3-arm2Signed-off-by: Cristina Ciocan
[Arul: Fix merge conflicts]
Signed-off-by: Arulpandiyan Vadivel[Robby: split original patch to driver and dts part. this is driver part.]
Signed-off-by: Robby Cai -
Add PMIC 'MAX17135' module drivers to 4.1.y kernel. These are necessary
to supply power for E-ink panel display functions.Signed-off-by: Robby Cai
Signed-off-by: Vipul Kumar
