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

regulator: stm32-pwr: fix of_iomap leak

2023-05-11T14:00:24Z

[ Upstream commit c4a413e56d16a2ae84e6d8992f215c4dcc7fac20 ] Smatch reports: drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn: 'base' from of_iomap() not released on lines: 151,166. In stm32_pwr_regulator_probe(), base is not released when devm_kzalloc() fails to allocate memory or devm_regulator_register() fails to register a new regulator device, which may cause a leak. To fix this issue, replace of_iomap() with devm_platform_ioremap_resource(). devm_platform_ioremap_resource() is a specialized function for platform devices. It allows 'base' to be automatically released whether the probe function succeeds or fails. Besides, use IS_ERR(base) instead of !base as the return value of devm_platform_ioremap_resource() can either be a pointer to the remapped memory or an ERR_PTR() encoded error code if the operation fails. Fixes: dc62f951a6a8 ("regulator: stm32-pwr: Fix return value check in stm32_pwr_regulator_probe()") Signed-off-by: YAN SHI Reported-by: kernel test robot Link: https://lore.kernel.org/oe-kbuild-all/202304111750.o2643eJN-lkp@intel.com/ Reviewed-by: Dongliang Mu Link: https://lore.kernel.org/r/20230412033529.18890-1-m202071378@hust.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Avoid lockdep reports when resolving supplies

2023-05-11T14:00:23Z

[ Upstream commit cba6cfdc7c3f1516f0d08ddfb24e689af0932573 ] An automated bot told me that there was a potential lockdep problem with regulators. This was on the chromeos-5.15 kernel, but I see nothing that would be different downstream compared to upstream. The bot said: ============================================ WARNING: possible recursive locking detected 5.15.104-lockdep-17461-gc1e499ed6604 #1 Not tainted -------------------------------------------- kworker/u16:4/115 is trying to acquire lock: ffffff8083110170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: create_regulator+0x398/0x7ec but task is already holding lock: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(regulator_ww_class_mutex); lock(regulator_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by kworker/u16:4/115: #0: ffffff808006a948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x520/0x1348 #1: ffffffc00e0a7cc0 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x55c/0x1348 #2: ffffff80828a2260 (&dev->mutex){....}-{3:3}, at: __device_attach_async_helper+0xd0/0x2a4 #3: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8 stack backtrace: CPU: 2 PID: 115 Comm: kworker/u16:4 Not tainted 5.15.104-lockdep-17461-gc1e499ed6604 #1 9292e52fa83c0e23762b2b3aa1bacf5787a4d5da Hardware name: Google Quackingstick (rev0+) (DT) Workqueue: events_unbound async_run_entry_fn Call trace: dump_backtrace+0x0/0x4ec show_stack+0x34/0x50 dump_stack_lvl+0xdc/0x11c dump_stack+0x1c/0x48 __lock_acquire+0x16d4/0x6c74 lock_acquire+0x208/0x750 __mutex_lock_common+0x11c/0x11f8 ww_mutex_lock+0xc0/0x440 create_regulator+0x398/0x7ec regulator_resolve_supply+0x654/0x7c4 regulator_register_resolve_supply+0x30/0x120 class_for_each_device+0x1b8/0x230 regulator_register+0x17a4/0x1f40 devm_regulator_register+0x60/0xd0 reg_fixed_voltage_probe+0x728/0xaec platform_probe+0x150/0x1c8 really_probe+0x274/0xa20 __driver_probe_device+0x1dc/0x3f4 driver_probe_device+0x78/0x1c0 __device_attach_driver+0x1ac/0x2c8 bus_for_each_drv+0x11c/0x190 __device_attach_async_helper+0x1e4/0x2a4 async_run_entry_fn+0xa0/0x3ac process_one_work+0x638/0x1348 worker_thread+0x4a8/0x9c4 kthread+0x2e4/0x3a0 ret_from_fork+0x10/0x20 The problem was first reported soon after we made many of the regulators probe asynchronously, though nothing I've seen implies that the problems couldn't have also happened even without that. I haven't personally been able to reproduce the lockdep issue, but the issue does look somewhat legitimate. Specifically, it looks like in regulator_resolve_supply() we are holding a "rdev" lock while calling set_supply() -> create_regulator() which grabs the lock of a _different_ "rdev" (the one for our supply). This is not necessarily safe from a lockdep perspective since there is no documented ordering between these two locks. In reality, we should always be locking a regulator before the supplying regulator, so I don't expect there to be any real deadlocks in practice. However, the regulator framework in general doesn't express this to lockdep. Let's fix the issue by simply grabbing the two locks involved in the same way we grab multiple locks elsewhere in the regulator framework: using the "wound/wait" mechanisms. Fixes: eaa7995c529b ("regulator: core: avoid regulator_resolve_supply() race condition") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Consistently set mutex_owner when using ww_mutex_lock_slow()

2023-05-11T14:00:23Z

[ Upstream commit b83a1772be854f87602de14726737d3e5b06e1f4 ] When a codepath locks a rdev using ww_mutex_lock_slow() directly then that codepath is responsible for incrementing the "ref_cnt" and also setting the "mutex_owner" to "current". The regulator core consistently got that right for "ref_cnt" but didn't always get it right for "mutex_owner". Let's fix this. It's unlikely that this truly matters because the "mutex_owner" is only needed if we're going to do subsequent locking of the same rdev. However, even though it's not truly needed it seems less surprising if we consistently set "mutex_owner" properly. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted

2023-05-11T14:00:20Z

[ Upstream commit 691c1fcda5351ed98a44610b7dccc0e3ee920020 ] This is very close to a straight revert of commit 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators"). We've identified that patch as causing a boot speed regression on sc7180-trogdor boards. While boot speed certainly isn't more important than making sure that power sequencing is correct, looking closely at the original change it doesn't seem to have been fully justified. It mentions "cycling issues" without describing exactly what the issues were. That means it's possible that the cycling issues were really a problem that should be fixed in a different way. Let's take a careful look at how we should handle regulators that have an off-on-delay and that are boot-on or always-on. Linux currently doesn't have any way to identify whether a GPIO regulator was already on when the kernel booted. That means that when the kernel boots we probe a regulator, see that it wants boot-on / always-on we, and then turn the regulator on. We could be in one of two cases when we do this: a) The regulator might have been left on by the bootloader and we're ensuring that it stays on. b) The regulator might have been left off by the bootloader and we're just now turning it on. For case a) we definitely don't need any sort of delay. For case b) we _might_ need some delay in case the bootloader turned the regulator off _right_ before booting the kernel. To get the proper delay for case b) then we can just assume a `last_off` of 0, which is what it gets initialized to by default. As per above, we can't tell whether we're in case a) or case b) so we'll assume the longer delay (case b). This basically puts the code to how it was before commit 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators"). However, we add one important change: we make sure that the delay is actually honored if `last_off` is 0. Though the original "cycling issues" cited were vague, I'm hopeful that this important extra change will be enough to fix the issues that the initial commit mentioned. With this fix, I've confined that on a sc7180-trogdor board the delay at boot goes down from 500 ms to ~250 ms. That's not as good as the 0 ms that we had prior to commit 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators"), but it's probably safer because we don't know if the bootloader turned the regulator off right before booting. One note is that it's possible that we could be in a state that's not a) or b) if there are other issues in the kernel. The only one I can think of is related to pinctrl. If the pinctrl driver being used on a board isn't careful about avoiding glitches when setting up a pin then it's possible that setting up a pin could cause the regulator to "turn off" briefly immediately before the regulator probes. If this is indeed causing problems then the pinctrl driver should be fixed, perhaps in a similar way to what was done in commit d21f4b7ffc22 ("pinctrl: qcom: Avoid glitching lines when we first mux to output") Fixes: 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators") Cc: Christian Kohlschütter Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: fan53555: Fix wrong TCS_SLEW_MASK

2023-04-26T11:51:47Z

[ Upstream commit c5d5b55b3c1a314137a251efc1001dfd435c6242 ] The support for TCS4525 regulator has been introduced with a wrong ramp-rate mask, which has been defined as a logical expression instead of a bit shift operation. For clarity, fix it using GENMASK() macro. Fixes: 914df8faa7d6 ("regulator: fan53555: Add TCS4525 DCDC support") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20230406171806.948290-4-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: fan53555: Explicitly include bits header

2023-04-26T11:51:47Z

[ Upstream commit 4fb9a5060f73627303bc531ceaab1b19d0a24aef ] Since commit f2a9eb975ab2 ("regulator: fan53555: Add support for FAN53526") the driver makes use of the BIT() macro, but relies on the bits header being implicitly included. Explicitly pull the header in to avoid potential build failures in some configurations. While here, reorder include directives alphabetically. Fixes: f2a9eb975ab2 ("regulator: fan53555: Add support for FAN53526") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20230406171806.948290-3-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: Handle deferred clk

2023-04-05T09:24:55Z

[ Upstream commit 02bcba0b9f9da706d5bd1e8cbeb83493863e17b5 ] devm_clk_get() can return -EPROBE_DEFER. So it is better to return the error code from devm_clk_get(), instead of a hard coded -ENOENT. This gives more opportunities to successfully probe the driver. Fixes: 8959e5324485 ("regulator: fixed: add possibility to enable by clock") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/18459fae3d017a66313699c7c8456b28158b2dd0.1679819354.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Use ktime_get_boottime() to determine how long a regulator was off

2023-03-17T07:48:52Z

[ Upstream commit 80d2c29e09e663761c2778167a625b25ffe01b6f ] For regulators with 'off-on-delay-us' the regulator framework currently uses ktime_get() to determine how long the regulator has been off before re-enabling it (after a delay if needed). A problem with using ktime_get() is that it doesn't account for the time the system is suspended. As a result a regulator with a longer 'off-on-delay' (e.g. 500ms) that was switched off during suspend might still incurr in a delay on resume before it is re-enabled, even though the regulator might have been off for hours. ktime_get_boottime() accounts for suspend time, use it instead of ktime_get(). Fixes: a8ce7bd89689 ("regulator: core: Fix off_on_delay handling") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Matthias Kaehlcke Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20230223003301.v2.1.I9719661b8eb0a73b8c416f9c26cf5bd8c0563f99@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Fix off-on-delay-us for always-on/boot-on regulators

2023-03-17T07:48:52Z

[ Upstream commit 218320fec29430438016f88dd4fbebfa1b95ad8d ] Regulators marked with "regulator-always-on" or "regulator-boot-on" as well as an "off-on-delay-us", may run into cycling issues that are hard to detect. This is caused by the "last_off" state not being initialized in this case. Fix the "last_off" initialization by setting it to the current kernel time upon initialization, regardless of always_on/boot_on state. Signed-off-by: Christian Kohlschütter Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.com Signed-off-by: Mark Brown Stable-dep-of: 80d2c29e09e6 ("regulator: core: Use ktime_get_boottime() to determine how long a regulator was off") Signed-off-by: Sasha Levin

regulator: Flag uncontrollable regulators as always_on

2023-03-17T07:48:52Z

[ Upstream commit 261f06315cf7c3744731e36bfd8d4434949e3389 ] While we currently assume that regulators with no control available are just uncontionally enabled this isn't always as clearly displayed to users as is desirable, for example the code for disabling unused regulators will log that it is about to disable them. Clean this up a bit by setting always_on during constraint evaluation if we have no available mechanism for controlling the regualtor so things that check the constraint will do the right thing. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.org Signed-off-by: Mark Brown Stable-dep-of: 80d2c29e09e6 ("regulator: core: Use ktime_get_boottime() to determine how long a regulator was off") Signed-off-by: Sasha Levin