user/sven/linux.git/drivers/regulator, branch v5.4.38

regulator: stm32-vrefbuf: fix a possible overshoot when re-enabling

2020-03-12T12:00:29Z

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 delay Fixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf") Signed-off-by: Fabrice Gasnier Message-Id: <1583312132-20932-1-git-send-email-fabrice.gasnier@st.com> Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regulator: core: Fix exported symbols to the exported GPL version

2020-02-24T07:36:54Z

[ 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

regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage

2020-02-24T07:36:52Z

[ 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

regulator: rk808: Lower log level on optional GPIOs being not available

2020-02-24T07:36:33Z

[ 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

regulator: core: Add regulator_is_equal() helper

2020-02-11T12:35:48Z

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

regulator: bd70528: Add MODULE_ALIAS to allow module auto loading

2020-01-26T09:01:05Z

[ 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

regulator: rn5t618: fix module aliases

2020-01-12T11:21:34Z

[ 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

regulator: core: fix regulator_register() error paths to properly release rdev

2020-01-12T11:21:15Z

[ 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 free We 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

regulator: fix use after free issue

2020-01-12T11:21:11Z

[ 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

regulator: ab8500: Remove AB8505 USB regulator

2020-01-09T09:20:04Z

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