#
e4ead3cd |
|
12-Mar-2024 |
Kory Maincent <kory.maincent@bootlin.com> |
regulator: core: Propagate the regulator state in case of exclusive get Previously, performing an exclusive get on an already-enabled regulator resulted in inconsistent state initialization between child and parent regulators. While the child's counts were updated, its parent's counters remained unaffected. Consequently, attempting to disable an already-enabled exclusive regulator triggered unbalanced disables warnings from its parent regulator. This commit addresses the issue by propagating the enable state to the parent regulator using a regulator_enable call. This ensures consistent state management across the regulator hierarchy, preventing warnings! Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://msgid.link/r/20240312091638.1266167-1-kory.maincent@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4fe62075 |
|
05-Mar-2024 |
Ricardo B. Marliere <ricardo@marliere.net> |
regulator: core: make regulator_class constant Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the regulator_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Link: https://msgid.link/r/20240305-class_cleanup-regulator-v1-1-4950345d6d8f@marliere.net Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
055100d1 |
|
16-Feb-2024 |
Colin Ian King <colin.i.king@gmail.com> |
regulator: core: Remove redundant assignment to variable possible_uV The variable possible_uV being assigned a value that is never read, the control flow via the following goto statement takes a path where the variable is not accessed. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/regulator/core.c:3935:3: warning: Value stored to 'possible_uV' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://msgid.link/r/20240216134918.2108262-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7f719a95 |
|
16-Feb-2024 |
Colin Ian King <colin.i.king@gmail.com> |
regulator: core: Remove redundant assignment to variable possible_uV The variable possible_uV being assigned a value that is never read, the control flow via the following goto statement takes a path where the variable is not accessed. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/regulator/core.c:3935:3: warning: Value stored to 'possible_uV' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://msgid.link/r/20240216134918.2108262-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
16e5ac12 |
|
05-Dec-2023 |
Naresh Solanki <naresh.solanki@9elements.com> |
regulator: event: Add regulator netlink event support This commit introduces netlink event support to the regulator subsystem. Changes: - Introduce event.c and regnl.h for netlink event handling. - Implement reg_generate_netlink_event to broadcast regulator events. - Update Makefile to include the new event.c file. Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2506c1de |
|
05-Dec-2023 |
Naresh Solanki <naresh.solanki@9elements.com> |
regulator: event: Add regulator netlink event support This commit introduces netlink event support to the regulator subsystem. Changes: - Introduce event.c and regnl.h for netlink event handling. - Implement reg_generate_netlink_event to broadcast regulator events. - Update Makefile to include the new event.c file. Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7993d3a9 |
|
03-Nov-2023 |
Rui Zhang <zr.zhang@vivo.com> |
regulator: core: Only increment use_count when enable_count changes The use_count of a regulator should only be incremented when the enable_count changes from 0 to 1. Similarly, the use_count should only be decremented when the enable_count changes from 1 to 0. In the previous implementation, use_count was sometimes decremented to 0 when some consumer called unbalanced disable, leading to unexpected disable even the regulator is enabled by other consumers. With this change, the use_count accurately reflects the number of users which the regulator is enabled. This should make things more robust in the case where a consumer does leak references. Signed-off-by: Rui Zhang <zr.zhang@vivo.com> Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c986968f |
|
07-Nov-2023 |
Javier Martinez Canillas <javierm@redhat.com> |
regulator: core: Add option to prevent disabling unused regulators This may be useful for debugging and develompent purposes, when there are drivers that depend on regulators to be enabled but do not request them. It is inspired from the clk_ignore_unused and pd_ignore_unused parameters, that are used to keep firmware-enabled clocks and power domains on even if these are not used by drivers. The parameter is not expected to be used in normal cases and should not be needed on a platform with proper driver support. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1e22152a |
|
26-Oct-2023 |
Oleksij Rempel <o.rempel@pengutronix.de> |
regulator: Implement uv_survival_time for handling under-voltage events Add 'uv_survival_time' field to regulation_constraints for specifying survival time post critical under-voltage event. Update the regulator notifier call chain and Device Tree property parsing to use this new field, allowing a configurable timeout before emergency shutdown. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8156c7dd |
|
26-Oct-2023 |
Oleksij Rempel <o.rempel@pengutronix.de> |
regulator: Introduce handling for system-critical under-voltage events Handle under-voltage events for crucial regulators to maintain system stability and avoid issues during power drops. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6e800968 |
|
18-Sep-2023 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator/core: Revert "fix kobject release warning and memory leak in regulator_register()" This reverts commit 5f4b204b6b8153923d5be8002c5f7082985d153f. Since rdev->dev now has a release() callback, the proper way of freeing the initialized device can be restored. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/d7f469f3f7b1f0e1d52f9a7ede3f3c5703382090.1695077303.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8adb4e64 |
|
18-Sep-2023 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator/core: regulator_register: set device->class earlier When fixing a memory leak in commit d3c731564e09 ("regulator: plug of_node leak in regulator_register()'s error path") it moved the device_initialize() call earlier, but did not move the `dev->class` initialization. The bug was spotted and fixed by reverting part of the commit (in commit 5f4b204b6b81 "regulator: core: fix kobject release warning and memory leak in regulator_register()") but introducing a different bug: now early error paths use `kfree(dev)` instead of `put_device()` for an already initialized `struct device`. Move the missing assignments to just after `device_initialize()`. Fixes: d3c731564e09 ("regulator: plug of_node leak in regulator_register()'s error path") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/b5b19cb458c40c9d02f3d5a7bd1ba7d97ba17279.1695077303.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
08880713 |
|
25-May-2023 |
Geert Uytterhoeven <geert+renesas@glider.be> |
regulator: core: Streamline debugfs operations If CONFIG_DEBUG_FS is not set: regulator: Failed to create debugfs directory ... regulator-dummy: Failed to create debugfs directory As per the comments for debugfs_create_dir(), errors returned by this function should be expected, and ignored: * If debugfs is not enabled in the kernel, the value -%ENODEV will be * returned. * * NOTE: it's expected that most callers should _ignore_ the errors returned * by this function. Other debugfs functions handle the fact that the "dentry" * passed to them could be an error and they don't crash in that case. * Drivers should generally work fine even if debugfs fails to init anyway. Adhere to the debugfs spirit, and streamline all operations by: 1. Demoting the importance of the printed error messages to debug level, like is already done in create_regulator(), 2. Further ignoring any returned errors, as by design, all debugfs functions are no-ops when passed an error pointer. Fixes: 2bf1c45be3b8f3a3 ("regulator: Fix error checking for debugfs_create_dir") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/2f8bb6e113359ddfab7b59e4d4274bd4c06d6d0a.1685013051.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2715bb11 |
|
25-May-2023 |
Geert Uytterhoeven <geert+renesas@glider.be> |
regulator: core: Fix more error checking for debugfs_create_dir() In case of failure, debugfs_create_dir() does not return NULL, but an error pointer. Most incorrect error checks were fixed, but the one in create_regulator() was forgotten. Fix the remaining error check. Fixes: 2bf1c45be3b8f3a3 ("regulator: Fix error checking for debugfs_create_dir") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/ee980a108b5854dd8ce3630f8f673e784e057d17.1685013051.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2bf1c45b |
|
15-May-2023 |
Osama Muhammad <osmtendev@gmail.com> |
regulator: Fix error checking for debugfs_create_dir This patch fixes the error checking in core.c in debugfs_create_dir. The correct way to check if an error occurred is 'IS_ERR' inline function. Signed-off-by: Osama Muhammad <osmtendev@gmail.com Suggested-by: Ivan Orlov <ivan.orlov0322@gmail.com Link: https://lore.kernel.org/r/20230515172938.13338-1-osmtendev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
|
#
37473397 |
|
13-Apr-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Make regulator_lock_two() logic easier to follow The regulator_lock_two() function could be made clearer in the case of lock contention by having a local variable for each of the held and contended locks. Let's do that. At the same time, let's use the swap() function instead of open coding it. This change is expected to be a no-op and simply improves code clarity. Suggested-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/CAE-0n53Eb1BeDPmjBycXUaQAF4ppiAM6UDWje_jiB9GAmR8MMw@mail.gmail.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230413173359.1.I1ae92b25689bd6579952e6d458b79f5f8054a0c9@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
cba6cfdc |
|
29-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Avoid lockdep reports when resolving supplies 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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b83a1772 |
|
29-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Consistently set mutex_owner when using ww_mutex_lock_slow() 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 <dianders@chromium.org> Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
691c1fcd |
|
13-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted 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 <christian@kohlschutter.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
80d2c29e |
|
22-Feb-2023 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Use ktime_get_boottime() to determine how long a regulator was off 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 <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230223003301.v2.1.I9719661b8eb0a73b8c416f9c26cf5bd8c0563f99@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
cb3543cf |
|
15-Dec-2022 |
Johan Hovold <johan+linaro@kernel.org> |
regulator: core: fix deadlock on regulator enable When updating the operating mode as part of regulator enable, the caller has already locked the regulator tree and drms_uA_update() must not try to do the same in order not to trigger a deadlock. The lock inversion is reported by lockdep as: ====================================================== WARNING: possible circular locking dependency detected 6.1.0-next-20221215 #142 Not tainted ------------------------------------------------------ udevd/154 is trying to acquire lock: ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280 but task is already holding lock: ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80 which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_acquire); lock(regulator_list_mutex); lock(regulator_ww_class_acquire); lock(regulator_list_mutex); *** DEADLOCK *** just before probe of a Qualcomm UFS controller (occasionally) deadlocks when enabling one of its regulators. Fixes: 9243a195be7a ("regulator: core: Change voltage setting path") Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0debed5b |
|
13-Dec-2022 |
ChiYuan Huang <cy_huang@richtek.com> |
regulator: core: Fix resolve supply lookup issue From Marek's log, the previous change modify the parent of rdev. https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/ In 'regulator_resolve_supply', it uses the parent DT node of rdev as the DT-lookup starting node. But the parent DT node may not exist. This will cause the NULL supply issue. This patch modify the parent of rdev back to the device that provides from 'regulator_config' in 'regulator_register'. Fixes: 8f3cbcd6b440 ("regulator: core: Use different devices for resource allocation and DT lookup") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8f3cbcd6 |
|
06-Dec-2022 |
ChiYuan Huang <cy_huang@richtek.com> |
regulator: core: Use different devices for resource allocation and DT lookup Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/ From the analysis of Yingliang CPU A |CPU B mt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data() i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register() It's common to use mfd core to create child device for the regulator. In order to do the DT lookup for init data, the child that registered the regulator would pass its parent as the parameter. And this causes init data resource allocated to its parent, not itself. The issue happen when parent device is going to release and regulator core is still doing some operation of init data constraint for the regulator of child device. To fix it, this patch expand 'regulator_register' API to use the different devices for init data allocation and DT lookup. Reported-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ba62319a |
|
01-Dec-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
regulator: core: fix resource leak in regulator_register() I got some resource leak reports while doing fault injection test: OF: ERROR: memory leak, expected refcount 1 instead of 100, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@64/regulators/buck1 unreferenced object 0xffff88810deea000 (size 512): comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ................ backtrace: [<00000000d78541e2>] kmalloc_trace+0x21/0x110 [<00000000b343d153>] device_private_init+0x32/0xd0 [<00000000be1f0c70>] device_add+0xb2d/0x1030 [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] unreferenced object 0xffff88810b617b80 (size 32): comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s) hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53 regulator.2868-S 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+... backtrace: [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0 [<0000000025c6a4e5>] kstrdup+0x3a/0x70 [<00000000790efb69>] create_regulator+0xc0/0x4e0 [<0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440 [<0000000045796214>] regulator_register+0x10b3/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] After calling regulator_resolve_supply(), the 'rdev->supply' is set by set_supply(), after this set, in the error path, the resources need be released, so call regulator_put() to avoid the leaks. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221202025111.496402-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
da46ee19 |
|
01-Dec-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
regulator: core: fix module refcount leak in set_supply() If create_regulator() fails in set_supply(), the module refcount needs be put to keep refcount balanced. Fixes: e2c09ae7a74d ("regulator: core: Increase refcount for regulator supply's module") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0591b14c |
|
30-Nov-2022 |
Rui Zhang <zr.zhang@vivo.com> |
regulator: core: fix use_count leakage when handling boot-on I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │◀──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on', we wish it could be disabled afterwards. Signed-off-by: Rui Zhang <zr.zhang@vivo.com> Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
dc8d006d |
|
22-Nov-2022 |
Wang ShaoBo <bobo.shaobowang@huawei.com> |
regulator: core: use kfree_const() to free space conditionally Use kfree_const() to free supply_name conditionally in create_regulator() as supply_name may be allocated from kmalloc() or directly from .rodata section. Fixes: 87fe29b61f95 ("regulator: push allocations in create_regulator() outside of lock") Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com> Link: https://lore.kernel.org/r/20221123034616.3609537-1-bobo.shaobowang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f2b41b74 |
|
15-Nov-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
regulator: core: fix unbalanced of node refcount in regulator_dev_lookup() I got the the following report: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@62/regulators/exten In of_get_regulator(), the node is returned from of_parse_phandle() with refcount incremented, after using it, of_node_put() need be called. Fixes: 69511a452e6d ("regulator: map consumer regulator based on device tree") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221115091508.900752-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fd184506 |
|
31-Oct-2022 |
Zev Weiss <zev@bewilderbeest.net> |
regulator: devres: Add devm_regulator_bulk_get_exclusive() We had an exclusive variant of the devm_regulator_get() API, but no corresponding variant for the bulk API; let's add one now. We add a generalized version of the existing regulator_bulk_get() function that additionally takes a get_type parameter and redefine regulator_bulk_get() in terms of it, then do similarly with devm_regulator_bulk_get(), and finally add the new devm_regulator_bulk_get_exclusive(). Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.net Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1f386d68 |
|
15-Nov-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
regulator: core: fix UAF in destroy_regulator() I got a UAF report as following: ================================================================== BUG: KASAN: use-after-free in __lock_acquire+0x935/0x2060 Read of size 8 at addr ffff88810e838220 by task python3/268 Call Trace: <TASK> dump_stack_lvl+0x67/0x83 print_report+0x178/0x4b0 kasan_report+0x90/0x190 __lock_acquire+0x935/0x2060 lock_acquire+0x156/0x400 _raw_spin_lock+0x2a/0x40 lockref_get+0x11/0x30 simple_recursive_removal+0x41/0x440 debugfs_remove.part.12+0x32/0x50 debugfs_remove+0x29/0x30 _regulator_put.cold.54+0x3e/0x27f regulator_put+0x1f/0x30 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 Allocated by task 37: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x5d/0x70 slab_post_alloc_hook+0x62/0x510 kmem_cache_alloc_lru+0x222/0x5a0 __d_alloc+0x31/0x440 d_alloc+0x30/0xf0 d_alloc_parallel+0xc4/0xd20 __lookup_slow+0x15e/0x2f0 lookup_one_len+0x13a/0x150 start_creating+0xea/0x190 debugfs_create_dir+0x1e/0x210 create_regulator+0x254/0x4e0 _regulator_get+0x2a1/0x467 _devm_regulator_get+0x5a/0xb0 regulator_virtual_probe+0xb9/0x1a0 Freed by task 30: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x102/0x190 kmem_cache_free+0xf6/0x600 rcu_core+0x54c/0x12b0 __do_softirq+0xf2/0x5e3 Last potentially related work creation: kasan_save_stack+0x1c/0x40 __kasan_record_aux_stack+0x98/0xb0 call_rcu+0x42/0x700 dentry_free+0x6c/0xd0 __dentry_kill+0x23b/0x2d0 dput.part.31+0x431/0x780 simple_recursive_removal+0xa9/0x440 debugfs_remove.part.12+0x32/0x50 debugfs_remove+0x29/0x30 regulator_unregister+0xe3/0x230 release_nodes+0x6a/0xa0 ================================================================== Here is how happened: processor A processor B regulator_register() rdev_init_debugfs() rdev->debugfs = debugfs_create_dir() devm_regulator_get() rdev = regulator_dev_lookup() create_regulator(rdev) // using rdev->debugfs as parent debugfs_create_dir(rdev->debugfs) mfd_remove_devices_fn() release_nodes() regulator_unregister() // free rdev->debugfs debugfs_remove_recursive(rdev->debugfs) release_nodes() destroy_regulator() debugfs_remove_recursive() <- causes UAF In devm_regulator_get(), after getting rdev, the refcount is get, so fix this by moving debugfs_remove_recursive() to regulator_dev_release(), then it can be proctected by the refcount, the 'rdev->debugfs' can not be freed until the refcount is 0. Fixes: 5de705194e98 ("regulator: Add basic per consumer debugfs") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221116033706.3595812-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5f4b204b |
|
16-Nov-2022 |
Zeng Heng <zengheng4@huawei.com> |
regulator: core: fix kobject release warning and memory leak in regulator_register() Here is a warning report about lack of registered release() from kobject lib: Device '(null)' does not have a release() function, it is broken and must be fixed. WARNING: CPU: 0 PID: 48430 at drivers/base/core.c:2332 device_release+0x104/0x120 Call Trace: kobject_put+0xdc/0x180 put_device+0x1b/0x30 regulator_register+0x651/0x1170 devm_regulator_register+0x4f/0xb0 When regulator_register() returns fail and directly goto `clean` symbol, rdev->dev has not registered release() function yet (which is registered by regulator_class in the following), so rdev needs to be freed manually. If rdev->dev.of_node is not NULL, which means the of_node has gotten by regulator_of_get_init_data(), it needs to call of_node_put() to avoid refcount leak. Otherwise, only calling put_device() would lead memory leak of rdev in further: unreferenced object 0xffff88810d0b1000 (size 2048): comm "107-i2c-rtq6752", pid 48430, jiffies 4342258431 (age 1341.780s) backtrace: kmalloc_trace+0x22/0x110 regulator_register+0x184/0x1170 devm_regulator_register+0x4f/0xb0 When regulator_register() returns fail and goto `wash` symbol, rdev->dev has registered release() function, so directly call put_device() to cleanup everything. Fixes: d3c731564e09 ("regulator: plug of_node leak in regulator_register()'s error path") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Link: https://lore.kernel.org/r/20221116074339.1024240-1-zengheng4@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8d8e1659 |
|
09-Sep-2022 |
Patrick Rudolph <patrick.rudolph@9elements.com> |
regulator: core: Prevent integer underflow By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen. Use a signed iterator to make sure that the loop exits once the remaining time is negative. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
520fb178 |
|
29-Aug-2022 |
Christian Kohlschütter <christian@kohlschutter.com> |
regulator: core: Fix regulator supply registration with sysfs In "regulator: core: Resolve supply name earlier to prevent double-init", we introduced a bug that prevented the regulator names from registering properly with sysfs. Reorder regulator_register such that supply names are properly resolved and registered. Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") Link: https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/ Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20220829165543.24856-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
57919f4a |
|
24-Aug-2022 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Don't err if allow-set-load but no allowed-modes Apparently the device trees of some boards have the property "regulator-allow-set-load" for some of their regulators but then they don't specify anything for "regulator-allowed-modes". That's not really legit, but... ...before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") they used to get away with it, at least on boards using RPMH regulators. That's because when a regulator driver implements set_load() then the core doesn't look at "regulator-allowed-modes" when trying to automatically adjust things in response to the regulator's load. The core doesn't know what mode we'll end up in, so how could it validate it? Said another way: before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") some boards _were_ having the regulator mode adjusted despite listing no allowed modes. After commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") these same boards were now getting an error returned when trying to use their regulators, since simply enabling a regulator tries to update its load and that was failing. We don't really want to go back to the behavior from before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"). Boards shouldn't have been changing modes if no allowed modes were listed. However, the behavior after commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") isn't the best because now boards can't even turn their regulators on. Let's choose to detect this case and return "no error" from drms_uA_update(). The net-result will be _different_ behavior than we had before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"), but this new behavior seems more correct. If a board truly needed the mode switched then its device tree should be updated to list the allowed modes. Reported-by: Andrew Halaney <ahalaney@redhat.com> Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
55841199 |
|
24-Aug-2022 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Require regulator drivers to check uV for get_optimum_mode() The get_optimum_mode() for regulator drivers is passed the input voltage and output voltage as well as the current. This is because, in theory, the optimum mode can depend on all three things. It turns out that for all regulator drivers in mainline only the current is looked at when implementing get_optimum_mode(). None of the drivers take the input or output voltage into account. Despite the fact that none of the drivers take the input or output voltage into account, though, the regulator framework will error out before calling into get_optimum_mode() if it doesn't know the input or output voltage. The above behavior turned out to be a probelm for some boards when we landed commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"). Before that change we'd have no problems running drms_uA_update() for RPMH regulators even if a regulator's input or output voltage was unknown. After that change drms_uA_update() started to fail. This is because typically boards using RPMH regulators don't model the input supplies of RPMH regulators. Input supplies for RPMH regulators nearly always come from the output of other RPMH regulators (or always-on regulators) and RPMH firmware is initialized with this knowledge and handles enabling (and adjusting the voltage of) input supplies. While we could model the parent/child relationship of the regulators in Linux, many boards don't bother since it adds extra overhead. Let's change the regulator core to make things work again. Now if we fail to get the input or output voltage we'll still call into get_optimum_mode() and we'll just pass error codes in for input_uV and/or output_uV parameters. Since no existing regulator drivers even look at input_uV and output_uV we don't need to add this error handling anywhere right now. We'll add some comments in the core so that it's obvious that (if regulator drivers care) it's up to them to add the checks. Reported-by: Andrew Halaney <ahalaney@redhat.com> Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0739ce4c |
|
20-Aug-2022 |
Christian Kohlschütter <christian@kohlschutter.com> |
regulator: core: Remove "ramp_delay not set" debug message This message shows up occasionally but in bursts (seen up to 30 times per second on my ODROID N2+). According to Matthias Kaehlcke's comment in 'regulator: core: silence warning: "VDD1: ramp_delay not set"', this message should have been removed after restructuring previous code that assumed that ramp_delay being zero in that function was an error. Link: https://lore.kernel.org/lkml/625675256c0d75805f088b4be17a3308dc1b7ea4.1477571498.git.hns@goldelico.com/T/ Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220820131420.16608-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8a866d52 |
|
17-Aug-2022 |
Christian Kohlschütter <christian@kohlschutter.com> |
regulator: core: Resolve supply name earlier to prevent double-init Previously, an unresolved regulator supply reference upon calling regulator_register on an always-on or boot-on regulator caused set_machine_constraints to be called twice. This in turn may initialize the regulator twice, leading to voltage glitches that are timing-dependent. A simple, unrelated configuration change may be enough to hide this problem, only to be surfaced by chance. One such example is the SD-Card voltage regulator in a NanoPI R4S that would not initialize reliably unless the registration flow was just complex enough to allow the regulator to properly reset between calls. Fix this by re-arranging regulator_register, trying resolve the regulator's supply early enough that set_machine_constraints does not need to be called twice. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c32f1ebf |
|
19-Aug-2022 |
Andrew Halaney <ahalaney@redhat.com> |
regulator: core: Clean up on enable failure If regulator_enable() fails, enable_count is incremented still. A consumer, assuming no matching regulator_disable() is necessary on failure, will then get this error message upon regulator_put() since enable_count is non-zero: [ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170 The consumer could try to fix this in their driver by cleaning up on error from regulator_enable() (i.e. call regulator_disable()), but that results in the following since regulator_enable() failed and didn't increment user_count: [ 1.258112] unbalanced disables for vreg_l17c [ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190 Fix this by decrementing enable_count upon failure to enable. With this in place, just the reason for failure to enable is printed as expected and developers can focus on the root cause of their issue instead of thinking their usage of the regulator consumer api is incorrect. For example, in my case: [ 1.240426] vreg_l17c: invalid input voltage found Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d511e8a7 |
|
09-Aug-2022 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Fix missing error return from regulator_bulk_get() In commit 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") I changed the error handling but had a subtle that caused us to always return no error even if there was an error. Fix it. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6eabfc01 |
|
26-Jul-2022 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Allow specifying an initial load w/ the bulk API There are a number of drivers that follow a pattern that looks like this: 1. Use the regulator bulk API to get a bunch of regulators. 2. Set the load on each of the regulators to use whenever the regulators are enabled. Let's make this easier by just allowing the drivers to pass the load in. As part of this change we need to move the error printing in regulator_bulk_get() around; let's switch to the new dev_err_probe() to simplify it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
218320fe |
|
19-Jul-2022 |
Christian Kohlschütter <christian@kohlschutter.com> |
regulator: core: Fix off-on-delay-us for always-on/boot-on regulators 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 <christian@kohlschutter.com> Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c3e3ca05 |
|
04-May-2022 |
Zev Weiss <zev@bewilderbeest.net> |
regulator: core: Fix enable_count imbalance with EXCLUSIVE_GET Since the introduction of regulator->enable_count, a driver that did an exclusive get on an already-enabled regulator would end up with enable_count initialized to 0 but rdev->use_count initialized to 1. With that starting point the regulator is effectively stuck enabled, because if the driver attempted to disable it it would fail the enable_count underflow check in _regulator_handle_consumer_disable(). The EXCLUSIVE_GET path in _regulator_get() now initializes enable_count along with rdev->use_count so that the regulator can be disabled without underflowing the former. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers") Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0f2d636e |
|
04-May-2022 |
Zev Weiss <zev@bewilderbeest.net> |
regulator: core: Add error flags to sysfs attributes If a regulator provides a get_error_flags() operation, its sysfs attributes will now include an entry for each defined REGULATOR_ERROR_* flag. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20220504065252.6955-3-zev@bewilderbeest.net Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
062920d2 |
|
20-Apr-2022 |
Brian Norris <briannorris@chromium.org> |
regulator: core: Sleep (not delay) in set_voltage() These delays can be relatively large (e.g., hundreds of microseconds to several milliseconds on RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that should usually use a sleeping delay. Let's use the existing regulator delay helper to handle both large and small delays appropriately. This avoids burning a bunch of CPU time and hurting scheduling latencies when hitting regulators a lot (e.g., during cpufreq). The sleep vs. delay issue choice has been made differently over time -- early versions of RK3399 Gru PWM-regulator support used usleep_range() in pwm-regulator.c. More of this got moved into the regulator core, in commits like: 73e705bf81ce regulator: core: Add set_voltage_time op At the same time, the sleep turned into a delay. It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an atomic context. (All our callers grab various mutexes already.) I avoid using fsleep() because it uses a usleep_range() of [N to N*2], and usleep_range() very commonly biases to the high end of the range. We don't want to double the expected delay, especially for long delays. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a38dce4c |
|
20-Apr-2022 |
Brian Norris <briannorris@chromium.org> |
regulator: core: Rename _regulator_enable_delay() I want to use it in other contexts besides _regulator_do_enable(). Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.1.I31ef0014c9597d53722ab513890f839f357fdfb3@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
261f0631 |
|
25-Mar-2022 |
Mark Brown <broonie@kernel.org> |
regulator: Flag uncontrollable regulators as always_on 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 <broonie@kernel.org> Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4e2a354e |
|
08-Feb-2022 |
Oliver Barta <oliver.barta@aptiv.com> |
regulator: core: fix false positive in regulator_late_cleanup() The check done by regulator_late_cleanup() to detect whether a regulator is on was inconsistent with the check done by _regulator_is_enabled(). While _regulator_is_enabled() takes the enable GPIO into account, regulator_late_cleanup() was not doing that. This resulted in a false positive, e.g. when a GPIO-controlled fixed regulator was used, which was not enabled at boot time, e.g. reg_disp_1v2: reg_disp_1v2 { compatible = "regulator-fixed"; regulator-name = "display_1v2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; gpio = <&tlmm 148 0>; enable-active-high; }; Such regulator doesn't have an is_enabled() operation. Nevertheless it's state can be determined based on the enable GPIO. The check in regulator_late_cleanup() wrongly assumed that the regulator is on and tried to disable it. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
400d5a5d |
|
21-Oct-2021 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: Don't error out fixed regulator in regulator_sync_voltage() Fixed regulator can't change voltage and regulator_sync_voltage() returns -EINVAL in this case. Make regulator_sync_voltage() to succeed for regulators that are incapable to change voltage. On NVIDIA Tegra power management driver needs to sync voltage and we have one device (Trimslice) that uses fixed regulator which is getting synced. The syncing error isn't treated as fatal, but produces a noisy error message. This patch silences that error. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20211021183308.27786-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
35d11469 |
|
29-Sep-2021 |
Mark Brown <broonie@kernel.org> |
regulator: Lower priority of logging when setting supply We lowered all the other constraint related log messages to debug level so lower the logging of what supplies we're configuring to debug level too. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210929140717.3769-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
12235da8 |
|
09-Sep-2021 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
kernel/locking: Add context to ww_mutex_trylock() 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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net
|
#
adea2831 |
|
26-Aug-2021 |
Brian Norris <briannorris@chromium.org> |
regulator: core: resolve supply voltage deferral silently Voltage-controlled regulators depend on their supply regulator for retrieving their voltage, and so they might return -EPROBE_DEFER at this stage. Our caller already attempts to resolve supplies and retry, so we shouldn't be printing this error to logs. Quiets log messages like this, on Rockchip RK3399 Gru/Kevin boards: [ 1.033057] ppvar_bigcpu: failed to get the current voltage: -EPROBE_DEFER ... [ 1.036735] ppvar_litcpu: failed to get the current voltage: -EPROBE_DEFER ... [ 1.040366] ppvar_gpu: failed to get the current voltage: -EPROBE_DEFER ... [ 1.044086] ppvar_centerlogic: failed to get the current voltage: -EPROBE_DEFER Cc: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20210826124015.1.Iab79c6dd374ec48beac44be2fcddd165dd26476b@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
89a6a5e5 |
|
02-Jun-2021 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: add property parsing and callbacks to set protection limits Add DT property parsing code and setting callback for regulator over/under voltage, over-current and temperature error limits. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/e7b8007ba9eae7076178bf3363fb942ccb1cc9a5.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7111c6d1 |
|
02-Jun-2021 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: IRQ based event/error notification helpers Provide helper function for IC's implementing regulator notifications when an IRQ fires. The helper also works for IRQs which can not be acked. Helper can be set to disable the IRQ at handler and then re-enabling it on delayed work later. The helper also adds regulator_get_error_flags() errors in cache for the duration of IRQ disabling. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
157d2230 |
|
02-Jun-2021 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: move rdev_print helpers to internal.h The rdev print helpers are a nice way to print messages related to a specific regulator device. Move them from core.c to internal.h As the rdev print helpers use rdev_get_name() export it from core.c. Also move the declaration from coupler.h to driver.h because the rdev name is not just a coupled regulator property. I guess the main audience for rdev_get_name() will be the regulator core and drivers. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/dc7fd70dc31de4d0e820b7646bb78eeb04f80735.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a277a262 |
|
29-May-2021 |
YueHaibing <yuehaibing@huawei.com> |
regulator: core: Use DEVICE_ATTR_RO macro Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(), which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20210529115226.25376-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
380d2b2d |
|
27-May-2021 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Add regulator_sync_voltage_rdev() Some NVIDIA Tegra devices use a CPU soft-reset method for the reboot and in this case we need to restore the coupled voltages to the state that is suitable for hardware during boot. Add new regulator_sync_voltage_rdev() helper which is needed by regulator drivers in order to sync voltage of a coupled regulators. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
|
#
98e48cd9 |
|
19-May-2021 |
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> |
regulator: core: resolve supply for boot-on/always-on regulators For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a8ce7bd8 |
|
23-Apr-2021 |
Vincent Whitchurch <vincent.whitchurch@axis.com> |
regulator: core: Fix off_on_delay handling The jiffies-based off_on_delay implementation has a couple of problems that cause it to sometimes not actually delay for the required time: (1) If, for example, the off_on_delay time is equivalent to one jiffy, and the ->last_off_jiffy is set just before a new jiffy starts, then _regulator_do_enable() does not wait at all since it checks using time_before(). (2) When jiffies overflows, the value of "remaining" becomes higher than "max_delay" and the code simply proceeds without waiting. Fix these problems by changing it to use ktime_t instead. [Note that since jiffies doesn't start at zero but at INITIAL_JIFFIES ("-5 minutes"), (2) above also led to the code not delaying if the first regulator_enable() is called when the ->last_off_jiffy is not initialised, such as for regulators with ->constraints->boot_on set. It's not clear to me if this was intended or not, but I've preserved this behaviour explicitly with the check for a non-zero ->last_off.] Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210423114524.26414-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a5ccccb3 |
|
22-Apr-2021 |
Vincent Whitchurch <vincent.whitchurch@axis.com> |
regulator: core: Respect off_on_delay at startup We currently do not respect off_on_delay the first time we turn on a regulator. This is problematic since the regulator could have been turned off by the bootloader, or it could it have been turned off during the probe of the regulator driver (such as when regulator-fixed requests the enable GPIO), either of which could potentially have happened less than off_on_delay microseconds ago before the first time a client requests for the regulator to be turned on. We can't know exactly when the regulator was turned off, but initialise off_on_delay to the current time when registering the regulator, so that we guarantee that we respect the off_on_delay in all cases. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210422083044.11479-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
72241e31 |
|
20-Apr-2021 |
Sebastian Fricke <sebastian.fricke@posteo.net> |
regulator: core.c: Improve a comment s/regulator may on/regulator may already be enabled/ s/or left on/or was left on/ The aim of this patch is to make the comment more readable and to make it clear, that this is about a regulator, that is already enabled instead of a regulator that may be switched on. Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net> Link: https://lore.kernel.org/r/20210421055236.13148-1-sebastian.fricke@posteo.net Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
69b8821e |
|
19-Apr-2021 |
Shubhankar Kuranagatti <shubhankarvk@gmail.com> |
regulator: core.c: Fix indentation of comment Shifted the closing */ of multiline comment to a new line This is done to maintain code uniformity Signed-off-by: Shubhankar Kuranagatti <shubhankarvk@gmail.com> Link: https://lore.kernel.org/r/20210420034718.t7wudu6xcfpahflv@kewl-virtual-machine Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
dbe954d8 |
|
22-Jan-2021 |
Hans de Goede <hdegoede@redhat.com> |
regulator: core: Avoid debugfs: Directory ... already present! error Sometimes regulator_get() gets called twice for the same supply on the same device. This may happen e.g. when a framework / library is used which uses the regulator; and the driver itself also needs to enable the regulator in some cases where the framework will not enable it. Commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate sysfs") already takes care of the backtrace which would trigger when creating a duplicate consumer symlink under /sys/class/regulator/regulator.%d in this scenario. Commit c33d442328f5 ("debugfs: make error message a bit more verbose") causes a new error to get logged in this scenario: [ 26.938425] debugfs: Directory 'wm5102-codec-MICVDD' with parent 'spi-WM510204:00-MICVDD' already present! There is no _nowarn variant of debugfs_create_dir(), but we can detect and avoid this problem by checking the return value of the earlier sysfs_create_link_nowarn() call. Add a check for the earlier sysfs_create_link_nowarn() failing with -EEXIST and skip the debugfs_create_dir() call in that case, avoiding this error getting logged. Fixes: c33d442328f5 ("debugfs: make error message a bit more verbose") Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210122183250.370571-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
24be0c71 |
|
22-Jan-2021 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: Make regulator_sync_voltage() usable by coupled regulators Make regulator_sync_voltage() to re-balance voltage state of a coupled regulators instead of changing the voltage directly. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Dmitry Osipenko <digetx@gmail.com> # A500 T20 and Nexus7 T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210122174311.28230-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
90cf443d |
|
03-Jan-2021 |
Daniel Scally <djrscally@gmail.com> |
regulator: core.c: Replace references to non-existent function The function regulator_set_device_supply() is referenced a few times in comments in regulator/core.c; however this function was removed a long time ago by commit a5766f11cfd3 ("regulator: core - Rework machine API to remove string based functions."). Update those references to point to set_consumer_device_supply(), which replaced the old function. Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20210103165541.784360-1-djrscally@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
14a71d50 |
|
22-Jan-2021 |
Mark Brown <broonie@kernel.org> |
regulator: Fix lockdep warning resolving supplies With commit eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) we started holding the rdev lock while resolving supplies, an operation that requires holding the regulator_list_mutex. This results in lockdep warnings since in other places we take the list mutex then the mutex on an individual rdev. Since the goal is to make sure that we don't call set_supply() twice rather than a concern about the cost of resolution pull the rdev lock and check for duplicate resolution down to immediately before we do the set_supply() and drop it again once the allocation is done. Fixes: eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
eaa7995c |
|
07-Jan-2021 |
David Collins <collinsd@codeaurora.org> |
regulator: core: avoid regulator_resolve_supply() race condition The final step in regulator_register() is to call regulator_resolve_supply() for each registered regulator (including the one in the process of being registered). The regulator_resolve_supply() function first checks if rdev->supply is NULL, then it performs various steps to try to find the supply. If successful, rdev->supply is set inside of set_supply(). This procedure can encounter a race condition if two concurrent tasks call regulator_register() near to each other on separate CPUs and one of the regulators has rdev->supply_name specified. There is currently nothing guaranteeing atomicity between the rdev->supply check and set steps. Thus, both tasks can observe rdev->supply==NULL in their regulator_resolve_supply() calls. This then results in both creating a struct regulator for the supply. One ends up actually stored in rdev->supply and the other is lost (though still present in the supply's consumer_list). Here is a kernel log snippet showing the issue: [ 12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent '17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level' already present! Avoid this race condition by holding the rdev->mutex lock inside of regulator_resolve_supply() while checking and setting rdev->supply. Signed-off-by: David Collins <collinsd@codeaurora.org> Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
55cca739 |
|
25-Nov-2020 |
Claudiu Beznea <claudiu.beznea@microchip.com> |
regulator: core: return zero for selectors lower than linear_min_sel Selectors lower than linear_min_sel should not be considered invalid. Thus return zero in case _regulator_list_voltage(), regulator_list_hardware_vsel() or regulator_list_voltage_table() receives such selectors as argument. Fixes: bdcd1177578c ("regulator: core: validate selector against linear_min_sel") Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1606325147-606-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ab97800e |
|
13-Nov-2020 |
Claudiu Beznea <claudiu.beznea@microchip.com> |
regulator: core: do not continue if selector match Do not continue if selector has already been located. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605290164-11556-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
bdcd1177 |
|
13-Nov-2020 |
Claudiu Beznea <claudiu.beznea@microchip.com> |
regulator: core: validate selector against linear_min_sel There are regulators who's min selector is not zero. Selectors loops (looping b/w zero and regulator::desc::n_voltages) might throw errors because invalid selectors are used (lower than regulator::desc::linear_min_sel). For this situations validate selectors against regulator::desc::linear_min_sel. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1605280870-32432-2-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0917c9db |
|
12-Nov-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: debug early supply resolving Help debugging the case when set_machine_constraints() needs to be repeated. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/f9cba575580369e46661a9278ee6c6a8d8564c2a.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f5c042b2 |
|
12-Nov-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: workaround self-referent regulators Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4b639e25 |
|
12-Nov-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: avoid resolve_supply() infinite recursion When a regulator's name equals its supply's name the regulator_resolve_supply() recurses indefinitely. Add a check so that debugging the problem is easier. The "fixed" commit just exposed the problem. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
57a6ad48 |
|
12-Nov-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: fix memory leak with repeated set_machine_constraints() Fixed commit introduced a possible second call to set_machine_constraints() and that allocates memory for rdev->constraints. Move the allocation to the caller so it's easier to manage and done once. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c088a498 |
|
05-Nov-2020 |
Pi-Hsun Shih <pihsun@chromium.org> |
regulator: core: don't disable regulator if is_enabled return error. In regulator_late_cleanup when is_enabled failed, don't try to disable the regulator since it would likely to fail too and causing confusing error messages. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
cf1ad559 |
|
02-Nov-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: defer probe when trying to get voltage from unresolved supply regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reported-by: Ondřej Jirman <megous@megous.com> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Tested-by: Ondřej Jirman <megous@megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d73e873b |
|
23-Oct-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
regulator: fix a kernel-doc markup It seems that the function was renamed. kernel-doc markup should follow it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/dffad16d4d6427d7d0fc89797e4126fe7c69d5de.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c845f21a |
|
05-Oct-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
regulator: Make constraint debug processing conditional on DEBUG If debugging is disabled, print_constraints() does not print the actual constraints, but still performs some processing and string formatting, only to throw away the result later. Fix this by moving all constraint debug processing to a separate function, and replacing it by a dummy when debugging is disabled. This reduces kernel size by almost 800 bytes (on arm/arm64). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201005131546.22448-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e9bb4a06 |
|
26-Sep-2020 |
AngeloGioacchino Del Regno <kholk11@gmail.com> |
regulator: core: Enlarge max OF property name length to 64 chars Some regulator drivers may be defining very long names: this is the case with the qcom_smd and qcom_spmi regulators, where we need to parse the regulator parents from DT. For clarity, this is an example: { "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, "vdd_l8_l9_l10_l11_l12_l13_l14" }, pm660-regulators { ... vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04> ... }; Now, with a 32 characters limit, the function is trying to parse, exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of the right one, which is 37 chars long in this specific case. ... And this is not only the case with PM660/PM660L, but also with PMA8084, PM8916, PM8950 and others that are not implemented yet. The length of 64 chars was chosen based on the longest parsed property name that I could find, which is in PM8916, and would be 53 characters long. At that point, rounding that to 64 looked like being the best idea. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
aea6cb99 |
|
26-Sep-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: resolve supply after creating regulator When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
61aab5ad |
|
26-Sep-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: print symbolic errors in kernel messages Change all error-printing messages to include error name via %pe instead of numeric error or nothing. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/1dcf25f39188882eb56918a9aa281ab17b792aa5.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
99ad5f6e |
|
26-Sep-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: print state at boot Make the initial state of the regulator shown when debugging. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/53c4f3d394d68f0989174f89e3b0882cebbbd787.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
be35cc46 |
|
20-Sep-2020 |
Colin Ian King <colin.king@canonical.com> |
regulator: fix indentation issue There is a return statement that is indented with an extra space, fix this by removing it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200920142454.33352-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4c9db393 |
|
19-Sep-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: unexport regulator_lock/unlock() regulator_lock/unlock() was used only to guard regulator_notifier_call_chain(). As no users remain, make the functions internal. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/d3381aabd2632aff5e7b839d55868bec6e85c811.1600550732.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3bca239d |
|
09-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: don't require mutex for regulator_notifier_call_chain() Since 3801b86aa482 ("regulator: Refactor supply implementation to work as regular consumers") we no longer cascade notifications and so notifier head's built-in rwsem is enough to protect the notifier chain. Remove the requirement to fix one case where rdev->mutex might be forced to be taken recursively. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/5a0da9017c69a4dbc3f9b50f44476fce80a73387.1597032945.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0a7416f9 |
|
31-Aug-2020 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive() 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 <digetx@gmail.com> Link: https://lore.kernel.org/r/20200831204335.19489-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
7d819664 |
|
09-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: Remove pointer table overallocation The code allocates sizeof(regulator_dev) for a pointer. Make it less generous. Let kcalloc() calculate the size, while at it. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/407fbd06a02caf038a9ba3baa51c7d6d47cd6517.1597000795.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0955f5be |
|
04-Aug-2020 |
Stephen Boyd <swboyd@chromium.org> |
regulator: Avoid grabbing regulator lock during suspend/resume I see it takes about 5us per regulator to grab the lock, check that this regulator isn't going to do anything for suspend, and then release the lock. When that is combined with PMICs that have dozens of regulators we get into a state where we spend a few miliseconds doing a bunch of locking operations synchronously to figure out that there's nothing to do. Let's reorganize the code here a bit so that we don't grab the lock until we're actually going to do something so that suspend is a little faster. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200804070837.1084024-1-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a577f345 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: remove superfluous lock in regulator_resolve_coupling() 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 <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2dbf0855 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: cleanup regulator_ena_gpio_free() Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it guarantees that same gpiod gets same pin structure, it is enough to compare just the pointers. Also we know there can be only one matching entry on the list. Rework the code take advantage of the facts. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/3ff002c7aa3bd774491af4291a9df23541fcf892.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d3c73156 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: plug of_node leak in regulator_register()'s error path 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 <mirq-linux@rere.qmqm.pl> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5c065401 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: push allocation in set_consumer_device_supply() out of lock 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 <mirq-linux@rere.qmqm.pl> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
87fe29b6 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: push allocations in create_regulator() outside of lock 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/0x2c0 but task is already holding lock: cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8 which 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 <mirq-linux@rere.qmqm.pl> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
467bf301 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: push allocation in regulator_ena_gpio_request() out of lock 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/0x2c0 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: -> #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 <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
73a32129 |
|
11-Aug-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: push allocation in regulator_init_coupling() outside of lock 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_reclaim Possible 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 <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9177514c |
|
23-Jul-2020 |
Vladimir Zapolskiy <vz@mleia.com> |
regulator: fix memory leak on error path of regulator_register() 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: [<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0 [<40c0ad48>] kvasprintf+0x64/0xd4 [<109abd29>] kvasprintf_const+0x70/0x84 [<c4215946>] kobject_set_name_vargs+0x34/0xa8 [<62282ea2>] dev_set_name+0x40/0x64 [<a39b6757>] regulator_register+0x3a4/0x1344 [<16a9543f>] devm_regulator_register+0x4c/0x84 [<51a4c6a1>] 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 <vz@mleia.com> Cc: Wen Yang <wenyang@linux.alibaba.com> Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e1794aa4 |
|
15-Jul-2020 |
Saravana Kannan <saravanak@google.com> |
regulator: core: Add destroy_regulator() Part of the regulator_get() code is already factored out into create_regulator(). This patch factors out some of the regulator_put() code into destroy_regulator() so that create_regulator() has a corresponding unwind function. Subsequent patches will use this function. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200716042053.1927676-3-saravanak@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f7d7ad42 |
|
22-Jun-2020 |
Sumit Semwal <sumit.semwal@linaro.org> |
regulator: Allow regulators to verify enabled during enable() Some regulators might need to verify that they have indeed been enabled after the enable() call is made and enable_time delay has passed. This is implemented by repeatedly checking is_enabled() upto poll_enabled_time, waiting for the already calculated enable delay in each iteration. Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20200622124110.20971-2-sumit.semwal@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
48325655 |
|
29-May-2020 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
regulator: core: Add regulator bypass trace points Add new trace points for the start and end of enabling bypass on a regulator, to allow monitoring of when regulators are moved into bypass and how long that takes. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200529152216.9671-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
752db83a |
|
29-May-2020 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulator: extract voltage balancing code to the separate function Move the coupled regulators voltage balancing code to the separate function and allow to call it from the custom regulator couplers. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200529124940.10675-2-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2a15483b |
|
29-Apr-2020 |
John Stultz <john.stultz@linaro.org> |
regulator: Revert "Use driver_deferred_probe_timeout for regulator_init_complete_work" This reverts commit dca0b44957e5 ("regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work"), as we ended up reverting the default deferred_probe_timeout value back to zero, to preserve behavior with 5.6 we need to decouple the regulator timeout which was previously 30 seconds. This avoids breaking some systems that depend on the regulator timeout but don't require the deferred probe timeout. Cc: linux-pm@vger.kernel.org Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200429172349.55979-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6b576eb0 |
|
03-Apr-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: use consumer->supply_name in debugfs/regulator_summary Make it easier to identify regulator consumers when consumer device uses more than one supply. Before: regulator ena use open bypass voltage current min max ----------------------------------------------------------------------------------- regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV 1-0010 0mV 0mV 1-0010 0mV 0mV After: regulator ena use open bypass voltage current min max ----------------------------------------------------------------------------------- regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV 1-0010-vccio 0mV 0mV 1-0010-vcc33 0mV 0mV Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6e5505cf |
|
12-Mar-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
regulator: core: Avoid device name duplication in NORMAL_GET With current code: st-gyro-i2c i2c-PRP0001:00: i2c-PRP0001:00 supply vdd not found, using dummy regulator which looks a bit oververbose. Replace this with simplified format string for the above case, and drop "deviceless" case since for all dev_*() macros used in _regulator_get() the "(null)" will be printed anyway. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200312183245.1612-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
dca0b449 |
|
24-Feb-2020 |
John Stultz <john.stultz@linaro.org> |
regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work The regulator_init_complete_work logic defers the cleanup for an arbitrary 30 seconds of time to allow modules loaded by userland to start. This arbitrary timeout is similar to the driver_deferred_probe_timeout value, and its been suggested we align these so users have a method to extend the timeouts as needed. So this patch changes the logic to use the driver_deferred_probe_timeout value for the delay value if it is set (using a delay of 0 if it is not). Cc: linux-pm@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
3d7610e8 |
|
20-Jan-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
regulator: core: Fix exported symbols to the exported GPL version 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 <digetx@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200120123921.1204339-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e9153311 |
|
16-Jan-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage `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 <dianders@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200116094543.2847321-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6d30fc51 |
|
08-Dec-2019 |
Cristian Marussi <cristian.marussi@arm.com> |
regulator: core: avoid unneeded .list_voltage calls Inside machine_constraints_voltage() a loop is in charge of verifying that each of the defined voltages are within the configured constraints and that those constraints are in fact compatible with the available voltages' list. When the registered regulator happens to be defined with a wide range of possible voltages the above O(n) loop can be costly. Moreover since this behaviour is triggered during the registration process, it means also that it can be easily triggered at probe time, slowing down considerably some module loading. On the other side if such wide range of voltage values happens to be also continuous and without discontinuity of any kind, the above potentially cumbersome operation is also useless. For these reasons, avoid such .list_voltage poll loop when regulator is described as 'continuous_voltage_range' as is, indeed, similarly already done inside regulator_is_supported_voltage(). Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20191209125239.46054-1-cristian.marussi@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a3cde953 |
|
30-Nov-2019 |
Wen Yang <wenyang@linux.alibaba.com> |
regulator: core: fix regulator_register() error paths to properly release rdev 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 <wenyang@linux.alibaba.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4affd79a |
|
24-Nov-2019 |
Wen Yang <wenyang@linux.alibaba.com> |
regulator: fix use after free issue 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 <wenyang@linux.alibaba.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
089b3f61 |
|
13-Nov-2019 |
Pascal Paillet <p.paillet@st.com> |
regulator: core: Let boot-on regulators be powered off 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 <p.paillet@st.com> Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b59b6544 |
|
14-Nov-2019 |
Saravana Kannan <saravanak@google.com> |
regulator: core: Don't try to remove device links if add failed device_link_add() might not always succeed depending on the type of device link and the rest of the dependencies in the system. If device_link_add() didn't succeed, then we shouldn't try to remove the link later on as it might remove a link someone else created. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20191115000438.45970-1-saravanak@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e381bfe4 |
|
24-Oct-2019 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Allow generic coupling only for always-on regulators The generic voltage balancer doesn't work correctly if one of regulator couples turns off. Currently there are no users in kernel for that case, although let's explicitly show that this case is unsupported for those who will try to use that feature. Link: https://lore.kernel.org/linux-samsung-soc/20191008170503.yd6GscYPLxjgrXqDuCO7AJc6i6egNZGJkVWHLlCxvA4@z/ Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20191025002240.25288-2-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
26c2c997 |
|
24-Oct-2019 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Release coupled_rdevs on regulator_init_coupling() error 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 <digetx@gmail.com> Link: https://lore.kernel.org/r/20191025002240.25288-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f8970d34 |
|
17-Sep-2019 |
Marco Felsch <m.felsch@pengutronix.de> |
regulator: core: make regulator_register() EPROBE_DEFER aware Sometimes it can happen that the regulator_of_get_init_data() can't retrieve the config due to a not probed device the regulator depends on. Fix that by checking the return value of of_parse_cb() and return EPROBE_DEFER in such cases. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20190917154021.14693-4-m.felsch@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c82f27df |
|
10-Sep-2019 |
H. Nikolaus Schaller <hns@goldelico.com> |
regulator: core: Fix error return for /sys access regulator_uV_show() is missing error handling if regulator_get_voltage_rdev() returns negative values. Instead it prints the errno as a string, e.g. -EINVAL as "-22" which could be interpreted as -22 µV. We also do not need to hold the lock while converting the integer to a string. Reported-by: Adam Ford <aford173@gmail.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Tested-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/f37f2a1276efcb34cf3b7f1a25481175be048806.1568143348.git.hns@goldelico.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
55576cf1 |
|
04-Sep-2019 |
Mark Brown <broonie@kernel.org> |
regulator: Defer init completion for a while after late_initcall The kernel has no way of knowing when we have finished instantiating drivers, between deferred probe and systems that build key drivers as modules we might be doing this long after userspace has booted. This has always been a bit of an issue with regulator_init_complete since it can power off hardware that's not had it's driver loaded which can result in user visible effects, the main case is powering off displays. Practically speaking it's not been an issue in real systems since most systems that use the regulator API are embedded and build in key drivers anyway but with Arm laptops coming on the market it's becoming more of an issue so let's do something about it. In the absence of any better idea just defer the powering off for 30s after late_initcall(), this is obviously a hack but it should mask the issue for now and it's no more arbitrary than late_initcall() itself. Ideally we'd have some heuristics to detect if we're on an affected system and tune or skip the delay appropriately, and there may be some need for a command line option to be added. Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org
|
#
81eeb0a3 |
|
14-Aug-2019 |
Nishka Dasgupta <nishkadg.linux@gmail.com> |
regulator: core: Add label to collate of_node_put() statements In function of_get_child_regulator(), the loop for_each_child_of_node() contains two mid-loop return statements, each preceded by a statement putting child. In order to reduce this repetition, create a new label, err_node_put, that puts child and then returns the required value; edit the mid-loop return blocks to instead go to this new label. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190815053704.32156-1-nishkadg.linux@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
db2a1732 |
|
04-Aug-2019 |
Nishka Dasgupta <nishkadg.linux@gmail.com> |
regulator: core: Add of_node_put() before return Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return in two places. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190804162023.5673-1-nishkadg.linux@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2da8d947 |
|
03-Jul-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
regulator: implement selector stepping Some regulators require that the requested voltage be reached gradually by setting all or some of the intermediate values. Implement a new field in the regulator description struct that allows users to specify the number of selectors by which the regulator API should step when ramping the voltage up/down. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190703161035.31808-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d22b85a1 |
|
23-Jun-2019 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Expose some of core functions needed by couplers Expose some of internal functions that are required for implementation of customized regulator couplers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d8ca7d18 |
|
23-Jun-2019 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Introduce API for regulators coupling customization Right now regulator core supports only one type of regulators coupling, the "voltage max-spread" which keeps voltages of coupled regulators in a given range from each other. A more sophisticated coupling may be required in practice, one example is the NVIDIA Tegra SoCs which besides the max-spreading have other restrictions that must be adhered. Introduce API that allow platforms to provide their own customized coupling algorithms. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f2c6203f |
|
17-Jun-2019 |
Mark Brown <broonie@kernel.org> |
regulator: core: Make entire header comment C++ style Makes things look more consistent. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
458f69ef |
|
12-Jun-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
docs: timers: convert docs to ReST and rename to *.rst The conversion here is really trivial: just a bunch of title markups and very few puntual changes is enough to make it to be parsed by Sphinx and generate a nice html. The conversion is actually: - add blank lines and identation in order to identify paragraphs; - fix tables markups; - add some lists markups; - mark literal blocks; - adjust title markups. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
2874c5fd |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
68ce3a44 |
|
03-May-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Slightly improve readability of _regulator_get_enable_time The logic is equivalent, but it looks more straightforward this way: If rdev->desc->ops->enable_time is set, call it. Otherwise fallback to return rdev->desc->enable_time. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
49820944 |
|
22-Apr-2019 |
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> |
regulator: core: simplify return value on suported_voltage All the current clients of this API assume that 0 corresponds to a failure and non-zero to a pass therefore ignoring the need to handle a negative error code. This commit modifies the API to follow that standard since returning a negative (EINVAL) doesn't seem to provide enough value to justify the need to handle it. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b9816363 |
|
17-Apr-2019 |
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> |
regulator: core: do not report EPROBE_DEFER as error but as debug Temporary failures to get a regulator (EPROBE_DEFER) should be logged as debug information instead of errors. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
78927aa4 |
|
20-Apr-2019 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: core: Actually put the gpiod after use I went to great lengths to hand over the management of the GPIO descriptors to the regulator core, and some stray rebased oneliner in the old patch must have been assuming the devices were still doing devres management of it. We handed the management over to the regulator core, so of course the regulator core shall issue gpiod_put() when done. Sorry for the descriptor leak. Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
06377301 |
|
04-Apr-2019 |
Charles Keepax <ckeepax@opensource.cirrus.com> |
regulator: core: Avoid potential deadlock on regulator_unregister Lockdep reports the following issue on my setup: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&rdev->disable_work)->work)); lock(regulator_list_mutex); lock((work_completion)(&(&rdev->disable_work)->work)); lock(regulator_list_mutex); The problem is that regulator_unregister takes the regulator_list_mutex and then calls flush_work on disable_work. But regulator_disable_work calls regulator_lock_dependent which will also take the regulator_list_mutex. Resulting in a deadlock if the flush_work call actually needs to flush the work. Fix this issue by moving the flush_work outside of the regulator_list_mutex. The list mutex is not used to guard the point at which the delayed work is queued, so its use adds no additional safety. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
70b46491 |
|
18-Mar-2019 |
Steve Twiss <stwiss.opensource@diasemi.com> |
regulator: core: fix error path for regulator_set_voltage_unlocked During several error paths in the function regulator_set_voltage_unlocked() the value of 'ret' can take on negative error values. However, in calls that go through the 'goto out' statement, this return value is lost and return 0 is used instead, indicating a 'pass'. There are several cases where this function should legitimately return a fail instead of a pass: one such case includes constraints check during voltage selection in the call to regulator_check_voltage(), which can have -EINVAL for the case when an unsupported voltage is incorrectly requested. In that case, -22 is expected as the return value, not 0. Fixes: 9243a195be7a ("regulator: core: Change voltage setting path") Cc: stable <stable@vger.kernel.org> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a48f1275 |
|
18-Feb-2019 |
Mark Brown <broonie@kernel.org> |
regulator: core: Fix application of "drop lockdep annotation in drms_uA_update()" [The original commit was sent against -next but needed to be sent as a bugfix, however -next had some additional changes which needed to be reverted. Now everything is all in one branch applying the rest of the changes to fix up the merge issue -- broonie] commit e5e21f70bfd3 ("regulator: core: Take lock before applying system load") took the regulator lock before calling drms_uA_update() in order to silence a lockdep warning during regulator_register(). However, we are not supposed to need locks at this point as the regulator is in the process of being registered, so there should be no possibility of concurrent access. Instead, remove the unnecessary locking and simply drop the lockdep annotation, since it is no longer valid. Fixes: e5e21f70bfd3 ("regulator: core: Take lock before applying system load") Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
74a569ee |
|
20-Feb-2019 |
Marc Gonzalez <marc.w.gonzalez@free.fr> |
regulator: core: Log forbidden DRMS operation When REGULATOR_CHANGE_DRMS is not set, drms_uA_update is a no-op. It used to print a debug message, which was dropped in commit 8a34e979f684 ("regulator: refactor valid_ops_mask checking code") Let's bring the debug message back, because it helps find missing regulator-allow-set-load properties. Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c407438f |
|
18-Feb-2019 |
Niklas Cassel <niklas.cassel@linaro.org> |
regulator: core: Drop lockdep annotation in drms_uA_update() commit e5e21f70bfd3 ("regulator: core: Take lock before applying system load") took the regulator lock before calling drms_uA_update() in order to silence a lockdep warning during regulator_register(). However, we are not supposed to need locks at this point as the regulator is in the process of being registered, so there should be no possibility of concurrent access. Instead, remove the unnecessary locking and simply drop the lockdep annotation, since it is no longer valid. Fixes: e5e21f70bfd3 ("regulator: core: Take lock before applying system load") Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
075ddd75 |
|
17-Feb-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
regulator: core: remove unused rdev_get_supply() This is a remnant of commit 70a7fb80e85a ("regulator: core: Fix nested locking of supplies"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e5e21f70 |
|
15-Feb-2019 |
Niklas Cassel <niklas.cassel@linaro.org> |
regulator: core: Take lock before applying system load Take the regulator lock before applying system load. Fixes the following lockdep splat: [ 5.583581] WARNING: CPU: 1 PID: 16 at drivers/regulator/core.c:925 drms_uA_update+0x114/0x360 [ 5.588467] Modules linked in: [ 5.596833] CPU: 1 PID: 16 Comm: kworker/1:0 Not tainted 5.0.0-rc6-next-20190213-00002-g0fce66ab480f #18 [ 5.599933] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 5.609544] Workqueue: events qcom_channel_state_worker [ 5.616209] pstate: 60000005 (nZCv daif -PAN -UAO) [ 5.621152] pc : drms_uA_update+0x114/0x360 [ 5.626006] lr : drms_uA_update+0x110/0x360 [ 5.630084] sp : ffff0000124b3490 [ 5.634242] x29: ffff0000124b3490 x28: ffff800005326e00 [ 5.637735] x27: ffff0000124b35f8 x26: 000000000032bc48 [ 5.643117] x25: ffff800004c7e800 x24: ffff800004c6d500 [ 5.648411] x23: ffff800004c38a80 x22: 00000000000000d1 [ 5.653706] x21: 00000000001ab3f0 x20: ffff800004c7e800 [ 5.659001] x19: ffff0000114c3000 x18: ffffffffffffffff [ 5.664297] x17: 0000000000000000 x16: 0000000000000000 [ 5.669592] x15: ffff0000114c3808 x14: 0720072007200720 [ 5.674888] x13: 00000000199c9b28 x12: ffff80002bcccc40 [ 5.680183] x11: ffff000012286000 x10: ffff0000114c3808 [ 5.685477] x9 : 0720072007200720 x8 : ffff000010e9e808 [ 5.690772] x7 : ffff0000106da568 x6 : 0000000000000000 [ 5.696067] x5 : 0000000000000000 x4 : 0000000000000000 [ 5.701362] x3 : 0000000000000004 x2 : 0000000000000000 [ 5.706658] x1 : 0000000000000000 x0 : 0000000000000000 [ 5.711952] Call trace: [ 5.717223] drms_uA_update+0x114/0x360 [ 5.719405] regulator_register+0xb30/0x1140 [ 5.723230] devm_regulator_register+0x4c/0xa8 [ 5.727745] rpm_reg_probe+0xfc/0x1b0 [ 5.731992] platform_drv_probe+0x50/0xa0 [ 5.735727] really_probe+0x20c/0x2b8 [ 5.739718] driver_probe_device+0x58/0x100 [ 5.743368] __device_attach_driver+0x90/0xd0 [ 5.747363] bus_for_each_drv+0x64/0xc8 [ 5.751870] __device_attach+0xd8/0x138 [ 5.755516] device_initial_probe+0x10/0x18 [ 5.759341] bus_probe_device+0x98/0xa0 [ 5.763502] device_add+0x3d0/0x640 [ 5.767319] of_device_add+0x48/0x58 [ 5.770793] of_platform_device_create_pdata+0xb0/0x128 [ 5.774629] of_platform_bus_create+0x174/0x370 [ 5.779569] of_platform_populate+0x78/0xe0 [ 5.784082] qcom_smd_rpm_probe+0x80/0xa0 [ 5.788245] rpmsg_dev_probe+0x114/0x1a0 [ 5.792411] really_probe+0x20c/0x2b8 [ 5.796401] driver_probe_device+0x58/0x100 [ 5.799964] __device_attach_driver+0x90/0xd0 [ 5.803960] bus_for_each_drv+0x64/0xc8 [ 5.808468] __device_attach+0xd8/0x138 [ 5.812115] device_initial_probe+0x10/0x18 [ 5.815936] bus_probe_device+0x98/0xa0 [ 5.820099] device_add+0x3d0/0x640 [ 5.823916] device_register+0x1c/0x28 [ 5.827391] rpmsg_register_device+0x4c/0x90 [ 5.831216] qcom_channel_state_worker+0x170/0x298 [ 5.835651] process_one_work+0x294/0x6e8 [ 5.840241] worker_thread+0x40/0x450 [ 5.844318] kthread+0x11c/0x120 [ 5.847961] ret_from_fork+0x10/0x18 [ 5.851260] irq event stamp: 9090 [ 5.854820] hardirqs last enabled at (9089): [<ffff000010160798>] console_unlock+0x3e0/0x5b0 [ 5.858086] hardirqs last disabled at (9090): [<ffff0000100817cc>] do_debug_exception+0x104/0x140 [ 5.866596] softirqs last enabled at (9086): [<ffff000010082024>] __do_softirq+0x474/0x574 [ 5.875446] softirqs last disabled at (9079): [<ffff0000100f2254>] irq_exit+0x13c/0x148 [ 5.883598] ---[ end trace 6984ef7f081afa21 ]--- Fixes: fa94e48e13a1 ("regulator: core: Apply system load even if no consumer loads") Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
82874ba4 |
|
08-Feb-2019 |
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> |
regulator: fix device unlinking Device links are refcounted, device_link_remove() has to be called as many times as device_link_add(). Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
541d052d |
|
29-Jan-2019 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: core: Only support passing enable GPIO descriptors Now that we changed all providers to pass descriptors into the core for enable GPIOs instead of a global GPIO number, delete the support for passing GPIO numbers in, and we get a cleanup and size reduction in the core, and from a GPIO point of view we use the modern, cleaner interface. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
01dc79cd |
|
29-Jan-2019 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: fixed/gpio: Pull inversion/OD into gpiolib This pushes the handling of inversion semantics and open drain settings to the GPIO descriptor and gpiolib. All affected board files are also augmented. This is especially nice since we don't have to have any confusing flags passed around to the left and right littering the fixed and GPIO regulator drivers and the regulator core. It is all just very straight-forward: the core asks the GPIO line to be asserted or deasserted and gpiolib deals with the rest depending on how the platform is configured: if the line is active low, it deals with that, if the line is open drain, it deals with that too. Cc: Alexander Shiyan <shc_work@mail.ru> # i.MX boards user Cc: Haojian Zhuang <haojian.zhuang@gmail.com> # MMP2 maintainer Cc: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP1 maintainer Cc: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> # EM-X270 maintainer Cc: Robert Jarzmik <robert.jarzmik@free.fr> # EZX maintainer Cc: Philipp Zabel <philipp.zabel@gmail.com> # Magician maintainer Cc: Petr Cvek <petr.cvek@tul.cz> # Magician Cc: Robert Jarzmik <robert.jarzmik@free.fr> # PXA Cc: Paul Parsons <lost.distance@yahoo.com> # hx4700 Cc: Daniel Mack <zonque@gmail.com> # Raumfeld maintainer Cc: Marc Zyngier <marc.zyngier@arm.com> # Zeus maintainer Cc: Geert Uytterhoeven <geert+renesas@glider.be> # SuperH pinctrl/GPIO maintainer Cc: Russell King <rmk+kernel@armlinux.org.uk> # SA1100 Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> #OMAP1 Amstrad Delta Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
03c87b95 |
|
09-Jan-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
regulator: provide rdev_get_regmap() Provide a helper allowing to access regulator's regmap. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
48f1b4ef |
|
08-Jan-2019 |
Krzysztof Kozlowski <krzk@kernel.org> |
regulator: Fix trivial language typos Fix few trivial language typos in core and drivers. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3e60b4fc |
|
15-Dec-2018 |
Yangtao Li <tiny.windzz@gmail.com> |
regulator: convert to DEFINE_SHOW_ATTRIBUTE Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
05f224ca |
|
06-Dec-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Clean enabling always-on regulators + their supplies At the end of regulator_resolve_supply() we have historically turned on our supply in some cases. This could be for one of two reasons: 1. If resolving supplies was happening before the call to set_machine_constraints() we needed to predict if set_machine_constraints() was going to turn the regulator on and we needed to preemptively turn the supply on. 2. Maybe set_machine_constraints() happened before we could resolve supplies (because we failed the first time to resolve) and thus we might need to propagate an enable that already happened up to our supply. Historically regulator_resolve_supply() used _regulator_is_enabled() to decide whether to turn on the supply. Let's change things a little bit. Specifically: 1. Let's try to enable the supply and the regulator in the same place, both in set_machine_constraints(). This means that we have exactly the same logic for enabling the supply and the regulator. 2. Let's properly set use_count when we enable always-on or boot-on regulators even for those that don't have supplies. The previous commit 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") only did this right for regulators with supplies. 3. Let's make it clear that the only time we need to enable the supply in regulator_resolve_supply() is if the main regulator is currently in use. By using use_count (like the rest of the code) to decide if we're going to enable our supply we keep everything consistent. Overall the new scheme should be cleaner and easier to reason about. In addition to fixing regulator_summary to be more correct (because of the more correct use_count), this change also has the effect of no longer using _regulator_is_enabled() in this code path. _regulator_is_enabled() could return an error code for some regulators at bootup (like RPMh) that can't read their initial state. While one can argue that the design of those regulators is sub-optimal, the new logic sidesteps this brokenness. This fix in particular fixes observed problems on Qualcomm sdm845 boards which use the above-mentioned RPMh regulator. Those problems were made worse by commit 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") because now we'd think at bootup that the SD regulators were already enabled and we'd never try them again. Fixes: 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") Reported-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0edb040d |
|
06-Dec-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: core: Track dangling GPIO descriptors If a GPIO descriptor is passed to the regulator_register() function inside the config->ena_gpiod callers must be sure that once they call this API the regulator core owns that descriptor and will make sure to issue gpiod_put() on it, no matter whether the call is successful or not. For device tree regulators, the regulator core will automatically set up regulator init data from the device tree when registering a regulator by calling regulator_of_get_init_data() which in turn calls down to the regulator driver's .of_parse_cb() callback. This callback (in drivers such as for max77686) may also choose to fill in the config->ena_gpiod field with a GPIO descriptor. Harden the errorpath of regulator_register() to properly gpiod_put() any passed in cfg->ena_gpiod or any gpiod coming from the device tree on any type of error. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fa94e48e |
|
26-Nov-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Apply system load even if no consumer loads Prior to commit 5451781dadf8 ("regulator: core: Only count load for enabled consumers") we used to always add up the total load on every enable in _regulator_enable(). After that commit we only updated the total load when enabling / disabling a regulator where a consumer specified a load or when changing the consumer load on an enabled regulator. The problem with the new scheme is that if there is a system load specified for a regulator but no consumers specify a load then we never account for it. Let's account for the system load in set_machine_constraints(). NOTE: with the new scheme we end up with a bit of a quandry. What if someone specifies _both_ an initial mode and a system load? If we take the system load into account right at init time then it will effectively clobber the initial mode. We'll resolve this by saying that if both are specified then the initial mode will win. The system load will then only take effect if/when a consumer specifies a load. If no consumers ever specify a load then the initial mode will persist and the system load will have no effect. Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Reported-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2bb16663 |
|
26-Nov-2018 |
Olliver Schinagl <oliver@schinagl.nl> |
regulator: core: enable power when setting up constraints When a regulator is marked as always on, it is enabled early on, when checking and setting up constraints. It makes the assumption that the bootloader properly initialized the regulator, and just in case enables the regulator anyway. Some constraints however currently get missed, such as the soft-start and ramp-delay. This causes the regulator to be enabled, without the soft-start and ramp-delay being applied, which in turn can cause high-currents or other start-up problems. By moving the always-enabled constraints later in the constraints check, we can at least ensure all constraints for the regulator are followed. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1fc12b05 |
|
20-Nov-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Avoid propagating to supplies when possible When we called regulator_enable() on a regulator we'd end up propagating that call all the way up the chain every time. This is a bit of a waste of time. A child regulator already refcounts its own enables so it should avoid passing on to its parent unless the refcount transitioned between 0 and 1. Historically this hasn't been a huge problem since we skipped dealing with enable for always-on regulators. In a previous patch, however, we removed the always-on optimization. On one system, the debugfs regulator_summary was now showing a "use_count" of 33 for a top-level regulator. Let's implement this optimization. This turns out to be fairly trivial with the recent reorganization of the regulator core. NOTE: as part of this patch I'll make "always-on" regulators start with a use count of 1. This keeps the counts clean when recursively resolving regulators. ALSO NOTE: this commit also contains somewhat of a bug fix to regulator_force_disable(). It was incorrectly looping over "rdev->open_count" when it should have been looping over use_count. We have to touch that code anyway (since we should no longer loop at all), so we'll fix it together in one patch. Also: since this comes after commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") we can now move to use _regulator_disable() for our supply and keep it in the lock. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5451781d |
|
20-Nov-2018 |
Douglas Anderson <dianders@chromium.org> |
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>
|
#
8ff00ba7 |
|
19-Nov-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Don't double-disable supplies in regulator_disable_deferred() In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") disabling of the supply was moved into _regulator_disable(). That means regulator_disable_work() shouldn't be disabling since that double-disables the supply. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7b51a821 |
|
19-Nov-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Properly expose requested_microamps in sysfs The "requested_microamps" sysfs attribute was only being exposed for "current" regulators. This didn't make sense. Allow it to be exposed always. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
14a74272 |
|
19-Nov-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Export regulator_lock and regulator_unlock This fixes compiling regulator drivers that use these function when these drivers are built as kernel modules. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ff9b34b6 |
|
18-Nov-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Keep regulators-list locked while traversing the list It's unlikely that regulators may disappear/appear while regulators debug-summary is being prepared, but let's be consistent and avoid that situation. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
089e2cc2 |
|
18-Nov-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Properly handle case where supply is the couple Check whether supply regulator is the couple to avoid infinite recursion during of locking. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f8702f9e |
|
18-Nov-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Use ww_mutex for regulators locking Wait/wound mutex shall be used in order to avoid lockups on locking of coupled regulators. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Suggested-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fe06051d |
|
14-Nov-2018 |
zoro <long17.cool@163.com> |
regulator/of_get_regulator: add child path to find the regulator supplier when the VIR_LDO1 regulator supplier is it's brother, we can't find the supplier. example code : &vir_regulator { ldo0_vir: ldo0-virtual { regulator-compatible = "VIR_LDO0"; regulator-name= "VIR_LDO0"; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <2000000>; }; ldo1_vir: ldo1-virtual { regulator-compatible = "VIR_LDO1"; regulator-name= "VIR_LDO1"; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <3000000>; ldo1-supply = <&ldo0_vir>; }; ... } so we add the child ptah to find the suppier. Signed-off-by: zoro <long17.cool@163.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6303f3e7 |
|
05-Oct-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Decouple regulators on regulator_unregister() Regulators shall be uncoupled if one of the couples disappear. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
85254bcf |
|
05-Oct-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Add new max_uV_step constraint On NVIDIA Tegra30 there is a requirement for regulator "A" to have voltage higher than voltage of regulator "B" by N microvolts, the N value changes depending on the voltage of regulator "B". This is similar to min-spread between voltages of regulators, the difference is that the spread value isn't fixed. This means that extra carefulness is required for regulator "A" to drop its voltage without violating the requirement, hence its voltage should be changed in steps so that its couple "B" could follow (there is also max-spread requirement). Add new "max_uV_step" constraint that breaks voltage change into several steps, each step is limited by the max_uV_step value. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
79d6f049 |
|
05-Oct-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Don't allow to get regulator until all couples resolved Don't allow to get regulator until all of its couples resolved because consumer will get EPERM and coupling shall be transparent for the drivers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f9503385 |
|
05-Oct-2018 |
Dmitry Osipenko <digetx@gmail.com> |
regulator: core: Mutually resolve regulators coupling If registered regulator found a couple, then the couple can find the registered regulator too and hence coupling can be mutually resolved at the registration time. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9243a195 |
|
05-Oct-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Change voltage setting path On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Uncoupled regulators should be a special case of coupled regulators, so they should share a common voltage setting path. When enabling, disabling or setting voltage of a coupled regulator, all coupled regulators should be locked. Regulator's supplies should be locked, when setting voltage of a single regulator. Enabling a coupled regulator or setting its voltage should not be possible if some of its coupled regulators, has not been registered. Add function for locking coupled regulators and supplies. Extract a new function regulator_set_voltage_rdev() from regulator_set_voltage_unlocked(), which is called when setting voltage of a single regulator. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c054c6c7 |
|
05-Oct-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Add voltage balancing mechanism On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Introduce new function regulator_balance_voltage(), which keeps max_spread constraint fulfilled between a group of coupled regulators. It should be called if a regulator changes its voltage or after disabling or enabling. Disabled regulators should follow changes of the enabled ones, but their consumers' demands shouldn't be taken into account while calculating voltage of other coupled regulators. Find voltages, which are closest to suiting all the consumers' demands, while fulfilling max_spread constraint, keeping the following rules: - if one regulator is about to rise its voltage, rise others voltages in order to keep the max_spread - if a regulator, which has caused rising other regulators, is lowered, lower other regulators if possible - if one regulator is about to lower its voltage, but it hasn't caused rising other regulators, change its voltage so that it doesn't break the max_spread Change regulators' voltages step by step, keeping max_spread constraint fulfilled all the time. Function regulator_get_optimal_voltage() should find the best possible change for the regulator, which doesn't break max_spread constraint. In function regulator_balance_voltage() optimize number of steps by finding highest voltage difference on each iteration. If a regulator, which is about to change its voltage, is not coupled, method regulator_get_optimal_voltage() should simply return the lowest voltage fulfilling consumers' demands. Coupling should be checked only if the system is in PM_SUSPEND_ON state. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
18e4b55f |
|
14-Sep-2018 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: Support regulators where voltage ranges are selectable For example ROHM BD71837 and ROHM BD71847 Power management ICs have regulators which provide multiple linear ranges. Ranges can be selected by individual non contagious bit in vsel register. Add regmap helper functions for selecting ranges. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fb6de923 |
|
19-Sep-2018 |
Yu Zhao <yuzhao@google.com> |
regulator: fix crash caused by null driver data dev_set_drvdata() needs to be called before device_register() exposes device to userspace. Otherwise kernel crashes after it gets null pointer from dev_get_drvdata() when userspace tries to access sysfs entries. [Removed backtrace for length -- broonie] Signed-off-by: Yu Zhao <yuzhao@google.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
1efef7cc |
|
04-Sep-2018 |
Randy Dunlap <rdunlap@infradead.org> |
regulator: fix kernel-doc for regulator_suspend() Fix kernel-doc warning: ../drivers/regulator/core.c:4479: warning: Excess function parameter 'state' description in 'regulator_suspend' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
cd7e36ab |
|
03-Sep-2018 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulator: Fix useless O^2 complexity in suspend/resume regulator_pm_ops with regulator_suspend and regulator_resume functions are assigned to every regulator device registered in the system, so there is no need to iterate over all again in them. Replace class_for_each_device() construction with direct operation on the rdev embedded in the given regulator device. This saves a lots of useless operations in suspend and resume paths. Fixes: f7efad10b5c4: regulator: add PM suspend and resume hooks Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3edd79cf |
|
03-Sep-2018 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulator: Fix 'do-nothing' value for regulators without suspend state Some regulators don't have all states defined and in such cases regulator core should not assume anything. However in current implementation of of_get_regulation_constraints() DO_NOTHING_IN_SUSPEND enable value was set only for regulators which had suspend node defined, otherwise the default 0 value was used, what means DISABLE_IN_SUSPEND. This lead to broken system suspend/resume on boards, which had simple regulator constraints definition (without suspend state nodes). To avoid further mismatches between the default and uninitialized values of the suspend enabled/disabled states, change the values of the them, so default '0' means DO_NOTHING_IN_SUSPEND. Fixes: 72069f9957a1: regulator: leave one item to record whether regulator is enabled Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
7e4d9683 |
|
16-Aug-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Add locking to debugfs regulator_summary Most functions that access the rdev lock the rdev mutex before looking at data. ...but not the code that implements the debugfs regulator_summary. It probably should though, so let's do it. Note: this fixes no known issues. The problem was found only by code inspection. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7d3827b5 |
|
16-Aug-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Add consumer-requested load in regulator_summary It's handy to see the load requested by a regulator consumer in the regulator_summary. Add it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
01de19d0 |
|
16-Aug-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Add the opmode to regulator_summary It's handy to know what opmode a regulator has been configured to in the summary. Add it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ed1ae2dd |
|
05-Jul-2018 |
pascal paillet <p.paillet@st.com> |
regulator: core: Link consumer with regulator driver Add a device link between the consumer and the driver so that the consumer is not suspended before the driver. The goal is to avoid implementing suspend_late ops in regulator drivers. Signed-off-by: pascal paillet <p.paillet@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0380cf7d |
|
05-Jul-2018 |
pascal paillet <p.paillet@st.com> |
regulator: core: Change suspend_late to suspend Change suspend_late ops to suspend normal ops. The goal is to avoid requesting all the regulator drivers to be operational in suspend late phase. Signed-off-by: pascal paillet <p.paillet@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
38de19fa |
|
30-May-2018 |
Mark Brown <broonie@kernel.org> |
regulator: Revert coupled regulator support again Revert the last two commits of the voltage coupling mechanism patch set: 456e7cdf3b1a14e2606b8 regulator: core: Change voltage setting path 696861761a58d8c93605b regulator: core: Add voltage balancing mechanism as they broke boot on OMAP again. Reported-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
456e7cdf |
|
23-Apr-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Change voltage setting path On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Uncoupled regulators should be a special case of coupled regulators, so they should share a common voltage setting path. When enabling, disabling or setting voltage of a coupled regulator, all coupled regulators should be locked. Regulator's supplies should be locked, when setting voltage of a single regulator. Enabling a coupled regulator or setting its voltage should not be possible if some of its coupled regulators, has not been registered. Add function for locking coupled regulators and supplies. Extract a new function regulator_set_voltage_rdev() from regulator_set_voltage_unlocked(), which is called when setting voltage of a single regulator. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
69686176 |
|
23-Apr-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Add voltage balancing mechanism On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Introduce new function regulator_balance_voltage(), which keeps max_spread constraint fulfilled between a group of coupled regulators. It should be called if a regulator changes its voltage or after disabling or enabling. Disabled regulators should follow changes of the enabled ones, but their consumers' demands shouldn't be taken into account while calculating voltage of other coupled regulators. Find voltages, which are closest to suiting all the consumers' demands, while fulfilling max_spread constraint, keeping the following rules: - if one regulator is about to rise its voltage, rise others voltages in order to keep the max_spread - if a regulator, which has caused rising other regulators, is lowered, lower other regulators if possible - if one regulator is about to lower its voltage, but it hasn't caused rising other regulators, don't change its voltage if it breaks the max_spread Change regulators' voltages step by step, keeping max_spread constraint fulfilled all the time. Function regulator_get_optimal_voltage() should find the best possible change for the regulator, which doesn't break max_spread constraint. In function regulator_balance_voltage() optimize number of steps by finding highest voltage difference on each iteration. If a regulator, which is about to change its voltage, is not coupled, method regulator_get_optimal_voltage() should simply return the lowest voltage fulfilling consumers' demands. Coupling should be checked only if the system is in PM_SUSPEND_ON state. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d3d64537 |
|
23-Apr-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Resolve coupled regulators On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Fill coupling descriptor with data obtained from DTS using previously defined of_functions. Fail to register a regulator, if some data inconsistency occurs. If some coupled regulators are not yet registered, don't fail to register, but try to resolve them in late init call. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
66cf9a7e |
|
23-Apr-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Make locks re-entrant Setting voltage, enabling/disabling regulators requires operations on all regulators related with the regulator being changed. Therefore, all of them should be locked for the whole operation. With the current locking implementation, adding additional dependency (regulators coupling) causes deadlocks in some cases. Introduce a possibility to attempt to lock a mutex multiple times by the same task without waiting on a mutex. This should handle all reasonable coupling-supplying combinations, especially when two coupled regulators share common supplies. The only situation that should be forbidden is simultaneous coupling and supplying between a pair of regulators. The idea is based on clk core. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
84b3a7c9 |
|
15-May-2018 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Allow for regulators that can't be read at bootup Regulators attached via RPMh on Qualcomm sdm845 apparently are write-only. Specifically you can send a request for a certain voltage but you can't read back to see what voltage you've requested. What this means is that at bootup we have absolutely no idea what voltage we could be at. As discussed in the patches to try to support the RPMh regulators [1], the fact that regulators are write-only means that its driver's get_voltage_sel() should return an error code if it's called before any calls to set_voltage_sel(). This causes problems in machine_constraints_voltage() when trying to apply the constraints. A proposed fix was to come up with an error code that could be returned by get_voltage_sel() which would cause the regulator framework to simply try setting the voltage with the current constraints. In this patch I propose the error code -ENOTRECOVERABLE. In errno.h this error is described as "State not recoverable". Though the error code was originally intended "for robust mutexes", the description of the error code seems to apply here because we can't read the state of the regulator. Also note that the only existing user of this error code in the regulator framework is tps65090-regulator.c which returns this error code from the enable() call (not get_voltage() or get_voltage_sel()), so there should be no existing regulators that might accidentally get the new behavior. (Side note is that tps65090 seems to interpret this error code to mean an error that you can't recover from rather than some data that can't be recovered). [1] https://patchwork.kernel.org/patch/10340897/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d3e4eccb |
|
22-Mar-2018 |
Mark Brown <broonie@kernel.org> |
regulator: core: Add missing blank line between functions Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
35b5f14e |
|
13-Feb-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
regulator: Fix resume from suspend to idle When resuming from idle with the new suspend mode configuration support we go through the resume callbacks with a state of PM_SUSPEND_TO_IDLE which we don't have regulator constraints for, causing an error: dpm_run_callback(): regulator_resume_early+0x0/0x64 returns -22 PM: Device regulator.0 failed to resume early: error -22 Avoid this and similar errors by treating missing constraints as a noop. See also commit 57a0dd187956ea04 ("regulator: Fix suspend to idle"), which fixed the suspend part. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e45e290a |
|
12-Feb-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: core: Support passing an initialized GPIO enable descriptor We are currently passing a GPIO number from the global GPIO numberspace into the regulator core for handling enable GPIOs. This is not good since it ties into the global GPIO numberspace and uses gpio_to_desc() to overcome this. Start supporting passing an already initialized GPIO descriptor to the core instead: leaf drivers pick their descriptors, associated directly with the device node (or from ACPI or from a board descriptor table) and use that directly without any roundtrip over the global GPIO numberspace. This looks messy since it adds a bunch of extra code in the core, but at the end of the patch series we will delete the handling of the GPIO number and only deal with descriptors so things end up neat. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
57a0dd18 |
|
29-Jan-2018 |
Mark Brown <broonie@kernel.org> |
regulator: Fix suspend to idle When suspending to idle with the new suspend mode configuration support we go through the suspend callbacks with a state of PM_SUSPEND_TO_IDLE which we don't have regulator constraints for, causing an error. Avoid this and similar errors by treating missing constraints as a noop. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
00cb9f4f |
|
26-Jan-2018 |
Mark Brown <broonie@kernel.org> |
regulator: Fix build error 3d67fe950707 (regulator: core: Refactor regulator_list_voltage()) missed one user of regulator_list_voltage(), update for that. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3d67fe95 |
|
22-Jan-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Refactor regulator_list_voltage() Change _regulator_list_voltage() argument from regulator to regulator_dev in order to provide better separation of core layers. Allow calling _regulator_list_voltage() from functions, with regulator_dev argument. This refactoring is needed in order to implement setting voltage of coupled regulators. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
148096af |
|
22-Jan-2018 |
Maciej Purski <m.purski@samsung.com> |
regulator: core: Move of_find_regulator_by_node() to of_regulator.c As of_find_regulator_by_node() is an of function it should be moved from core.c to of_regulator.c. It provides better separation of device tree functions from the core and allows other of_functions in of_regulator.c to resolve device_node to regulator_dev. This will be useful for implementation of parsing coupled regulators properties. Declare of_find_regulator_by_node() function in internal.h as well as regulator_class and dev_to_rdev(), as they are needed by of_find_regulator_by_node(). Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f7efad10 |
|
26-Jan-2018 |
Chunyan Zhang <zhang.chunyan@linaro.org> |
regulator: add PM suspend and resume hooks In this patch, consumers are allowed to set suspend voltage, and this actually just set the "uV" in constraint::regulator_state, when the regulator_suspend_late() was called by PM core through callback when the system is entering into suspend, the regulator device would act suspend activity then. And it assumes that if any consumer set suspend voltage, the regulator device should be enabled in the suspend state. And if the suspend voltage of a regulator device for all consumers was set zero, the regulator device would be off in the suspend state. This patch also provides a new function hook to regulator devices for resuming from suspend states. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
aa27bbc6 |
|
26-Jan-2018 |
Chunyan Zhang <zhang.chunyan@linaro.org> |
regulator: empty the old suspend functions Regualtor suspend/resume functions should only be called by PM suspend core via registering dev_pm_ops, and regulator devices should implement the callback functions. Thus, any regulator consumer shouldn't call the regulator suspend/resume functions directly. In order to avoid compile errors, two empty functions with the same name still be left for the time being. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
72069f99 |
|
26-Jan-2018 |
Chunyan Zhang <zhang.chunyan@linaro.org> |
regulator: leave one item to record whether regulator is enabled The items "disabled" and "enabled" are a little redundant, since only one of them would be set to record if the regulator device should keep on or be switched to off in suspend states. So in this patch, the "disabled" was removed, only leave the "enabled": - enabled == 1 for regulator-on-in-suspend - enabled == 0 for regulator-off-in-suspend - enabled == -1 means do nothing when entering suspend mode. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c360a6df |
|
26-Jan-2018 |
Chunyan Zhang <zhang.chunyan@linaro.org> |
regulator: make regulator voltage be an array to support more states Some regulator consumers would like to make the regulator device keeping a voltage range output when the system entering into suspend states. Making regulator voltage be an array can allow consumers to set voltage for normal state as well as for suspend states through the same code. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0d5c8633 |
|
07-Dec-2017 |
Colin Ian King <colin.king@canonical.com> |
regulator: fix incorrect indentation of two assignment statements Remove extraneous space to fix indentation on a couple of assignment statements. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c9ccaa0c |
|
12-Jul-2017 |
Tirupathi Reddy <tirupath@codeaurora.org> |
regulator: core: fix a possible race in disable_work handling A race condition between queueing and processing the disable_work instances results in having a work instance in the queue and the deferred_disables variable of regulator device structure having a value '0'. If no new regulator_disable_deferred() call later from clients, the deferred_disables variable value remains '0' and hits BUG() in regulator_disable_work() when the queued instance scheduled for processing the work. The race occurs as below: Core-0 Core-1 ..... /* deferred_disables = 2 */ ..... ..... /* disable_work is queued */ ..... ..... ..... regulator_disable_deferred: regulator_disable_work: mutex_lock(&rdev->mutex); ..... rdev->deferred_disables++; ..... mutex_unlock(&rdev->mutex); ..... queue_delayed_work(...) mutex_lock(&rdev->mutex); ..... count =rdev->deferred_disables; ..... rdev->deferred_disables = 0; ..... ..... ..... mutex_unlock(&rdev->mutex); ..... ..... ..... return; ..... ..... /* No new regulator_disable_deferred() calls from clients */ /* The newly queued instance is scheduled for processing */ ..... ..... regulator_disable_work: ..... mutex_lock(&rdev->mutex); BUG_ON(!rdev->deferred_disables); /* deferred_disables = 0 */ The race is fixed by removing the work instance that is queued while processing the previous queued instance. Cancel the newly queued instance from disable_work() handler just after reset the deferred_disables variable to value '0'. Also move the work queueing step before mutex_unlock in regulator_disable_deferred(). Also use mod_delayed_work() in the pace of queue_delayed_work() as queue_delayed_work() always uses the delay requested in the first call when multiple consumers call regulator_disable_deferred() close in time and does not guarantee the semantics of regulator_disable_deferred(). Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7799167b |
|
18-Jul-2017 |
Rob Herring <robh@kernel.org> |
regulator: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
dbc55955 |
|
29-Jun-2017 |
Haishan Zhou <zhssmail@gmail.com> |
regulator: core: Fix size limit of supply_map Now the debugfs file supply_map has a size limit PAGE_SIZE and the user can not see the whole content of regulator_map_list when it is larger than this limit. This patch uses seq_file instead to make sure supply_map shows the full information of regulator_map_list. Signed-off-by: Haishan Zhou <zhssmail@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2c2874b1 |
|
25-May-2017 |
Tirupathi Reddy <tirupath@codeaurora.org> |
regulator: core: Fix voltage change propagations to supply regulators Some regulators support get_voltage() and some support get_voltage_sel() operations but currently we only propagate changes if the regulator has a get_voltage() operation. Also do this if we've got get_voltage_sel() [Rewite commit message for clarity -- broonie] Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
06217197 |
|
13-Jun-2017 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Prioritise consumer mappings over regulator name Currently, when looking up a regulator supply, the regulator name takes priority over the consumer mappings. As there are a lot of regulator names that are in fairly common use (VDD, MICVDD, etc.) this can easily lead to obtaining the wrong supply, when a system contains two regulators that share a name. The explicit consumer mappings contain much less ambiguity as they specify both a name and a consumer device. As such prioritise those if one exists and only fall back to the regulator name if there are no matching explicit mappings. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3ffad468 |
|
16-May-2017 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: Allow for asymmetric settling times Some regulators have different settling times for voltage increases and decreases. To avoid a time penalty on the faster transition allow for different settings for up- and downward transitions. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c93609ab |
|
11-Apr-2017 |
Mark Brown <broonie@kernel.org> |
regulator: core: Allow dummy regulators for supplies Rather than just not resolving the supply when there is explicitly no supply mapping fall through and allow a dummy supply to be substituted. This fixes issues with constant retries reported by Dong Aisheng. Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Dong Aisheng <aisheng.dong@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
|
#
43fc99f2 |
|
13-Apr-2017 |
Mark Brown <broonie@kernel.org> |
regulator: core: Only propagate voltage changes to if it can change voltages When we are propagating voltage changes to parent regulators don't bother if the parent does not have permission to change voltages. This simplifies error checking in the function for cases where the regulator lacks some of the voltage operations. Reported-by: Dong Aisheng <aisheng.dong@nxp.com> Tested-by: Dong Aisheng <aisheng.dong@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d6c1dc3f |
|
04-Apr-2017 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: Add settling time for non-linear voltage transition Some regulators (some PWM regulators) have the voltage transition non-linear i.e. exponentially. On such cases, the settling time for voltage transition can not be presented in the voltage-ramp-delay. Add new property for non-linear voltage transition and handle this in getting the voltage settling time. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fd086045 |
|
27-Mar-2017 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Limit propagation of parent voltage count and list Commit 26988efe11b1 ("regulator: core: Allow to get voltage count and list from parent") introduces the propagation of the parent voltage count and list for regulators that don't provide this information themselves. The goal is to support simple switch regulators, however as a side effect normal continuous regulators can leak details of their supplies and provide consumers with inconsistent information. Limit the propagation of the voltage count and list to switch regulators. Fixes: 26988efe11b1 ("regulator: core: Allow to get voltage count and list from parent") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fffd1133 |
|
28-Mar-2017 |
Tamara Diaconita <diaconitatamara@gmail.com> |
regulator: core: Fix kerneldoc comments Remove the description for the non-existing 'ret' to fix the build warning: ./drivers/regulator/core.c:1467: warning: Excess function parameter 'ret' description in 'regulator_dev_lookup'. The description found for the return value is: @ret: 0 on success, -ENODEV if lookup fails permanently, -EPROBE_DEFER if lookup could succeed in the future. Signed-off-by: Tamara Diaconita <diaconita.tamara@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
264b88c9 |
|
23-Feb-2017 |
Harald Geyer <harald@ccbib.org> |
regulator: core: Add new notification for enabling of regulator This is useful for devices, which need some time to start up, to help the drivers track how long the supply has been up already. Ie whether it can safely talk to the HW or needs to wait. Signed-off-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0630b614 |
|
16-Mar-2017 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Mark supply_name const and duplicate it as such The supply_name member of struct regulator can be const as we don't change it in the regulator core. Furthermore, when we copy the supply name we can use kstrdup_const() here to avoid a copy if the name is in the ro data section. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b7cd1b13 |
|
06-Mar-2017 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
regulator: core: use snprintf() instead of scnprintf() When creating the link to the device sysfs entry, the regulator core calls scnprintf() and then checks if the returned value is greater or equal than the buffer size. The former can never happen as scnprintf() returns the number of bytes that were actually written to the buffer, not the bytes that *would* have been written. Use the right function in this case: snprintf(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3827b64d |
|
16-Feb-2017 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: core: Resolve supplies before disabling unused regulators After commit 66d228a2bf03 ("regulator: core: Don't use regulators as supplies until the parent is bound"), input supplies aren't resolved if the input supplies parent device has not been bound. This prevent regulators to hold an invalid reference if its supply parent device driver probe is deferred. But this causes issues on some boards where a PMIC's regulator use as input supply a regulator from another PMIC whose driver is registered after the driver for the former. In this case the regulators for the first PMIC will fail to resolve input supplies on regulators registration (since the other PMIC wasn't probed yet). And when the core attempts to resolve again latter when the other PMIC registers its own regulators, it will fail again since the parent device isn't bound yet. This will cause some parent supplies to never be resolved and wrongly be disabled on boot due taking them as unused. To solve this problem, also attempt to resolve the pending regulators input supplies before disabling the unused regulators. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e42a46b6 |
|
14-Feb-2017 |
Leonard Crestez <leonard.crestez@nxp.com> |
regulator: Fix regulator_summary for deviceless consumers It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
a4d7641f |
|
06-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: simplify _regulator_get() The code in _regulator_get() got a bit confusing over time, with control flow jumping to a label from couple of places. Let's untangle it a bit by doing the following: 1. Make handling of missing supplies and substituting them with dummy regulators more explicit: - check if we not have full constraints and refuse considering dummy regulators with appropriate message; - use "switch (get_type)" to handle different types of request explicitly as well. "Normal" requests will get dummies, exclusive will not and will notify user about that; optional will fail silently. 2. Stop jumping to a label in the middle of the function but instead have proper conditional flow. I believe jumps should be reserved for error handling, breaking from inner loop, or restarting a loop, but not for implementing normal conditional flow. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
163478da |
|
04-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: have regulator_dev_lookup() return ERR_PTR-encoded errors Instead of returning both regulator_dev structure as return value and auxiliary error code in 'ret' argument, let's switch to using ERR_PTR encoded values. This makes it more obvious what is going on at call sites. Also, let's not unlock the mutex in the middle of a loop, but rather break out and have single unlock path. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d1642ea7 |
|
03-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: fix typo in regulator_bulk_disable() "re-enable" was misspelled as "reename". Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b8c77ff6 |
|
03-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: simplify regulator_bulk_force_disable() There is no need to have two loops there, we can store error for subsequent reporting. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a8bd42a9 |
|
03-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: have _regulator_get() accept get_type argument Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3 valid combinations (normal, exclusive and optional) and an invalid one, let's accept explicit "get_type", like we did in devm-managed code. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7d245afa |
|
03-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: remove dead code in _regulator_get() There is no point in assigning value to 'ret' before calling regulator_dev_lookup() as it will clobber 'ret' anyway. Also, let's explicitly return -PROBE_DEFER when try_module_get() fails, instead of relying that earlier initialization of "regulator" carries correct value. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
66d228a2 |
|
11-Jan-2017 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: core: Don't use regulators as supplies until the parent is bound When regulators are successfully registered, we check to see if the regulator is a supply for any other registered regulator and if so add the new regulator as the supply for the existing regulator(s). Some devices, such as Power Management ICs, may register a series of regulators when probed and there are cases where one of the regulators may fail to register and defer the probing of the parent device. In this case any successfully registered regulators would be unregistered so that they can be re-registered at some time later when the probe is attempted again. However, if one of the regulators that was registered was added as a supply to another registered regulator (that did not belong to the same parent device), then this supply regulator was unregister again because the parent device is probe deferred, then a regulator could be holding an invalid reference to a supply regulator that has been unregistered. This will lead to a system crash if that regulator is then used. Although it would be possible to check when unregistering a regulator if any other regulator in the system is using it as a supply, it still may not be possible to remove it as a supply if this other regulator is in use. Therefore, fix this by preventing any regulator from adding another regulator as a supply if the parent device for the supply regulator has not been bound and if the parent device for the supply and the regulator are different. This will allow a parent device that is registering regulators to be probe deferred and ensure that none of the regulators it has registered are used as supplies for any other regulator from another device. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b2661e98 |
|
04-Dec-2016 |
David Lechner <david@lechnology.com> |
regulator: core: add newline in debug message This adds a trailing newline to a debug message. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
109c75af |
|
29-Nov-2016 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Correct type of mode in regulator_mode_constrain Every function handling the mode within the regulator core uses an unsigned int for mode, except for regulator_mode_constrain. This patch changes the type of mode within regulator_mode_constrain which fixes several instances where we are passing pointers to unsigned ints then treating them as an int within this function. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1b5b4221 |
|
02-Nov-2016 |
Axel Haslam <ahaslam@baylibre.com> |
regulator: core: Add new API to poll for error conditions Regulator consumers can receive event notifications when errors are reported to the driver, but currently, there is no way for a regulator consumer to know when the error is over. To allow a regulator consumer to poll for error conditions add a new API: regulator_get_error_flags. Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ba14fa1a |
|
27-Oct-2016 |
H. Nikolaus Schaller <hns@goldelico.com> |
regulator: core: silence warning: "VDD1: ramp_delay not set" commit 73e705bf81ce ("regulator: core: Add set_voltage_time op") introduced a new rdev_warn() if the ramp_delay is 0. Apparently, on omap3/twl4030 platforms with dynamic voltage management this results in non-ending spurious messages like [ 511.143066] VDD1: ramp_delay not set [ 511.662322] VDD1: ramp_delay not set [ 513.903625] VDD1: ramp_delay not set [ 514.222198] VDD1: ramp_delay not set [ 517.062835] VDD1: ramp_delay not set [ 517.382568] VDD1: ramp_delay not set [ 520.142791] VDD1: ramp_delay not set [ 520.502593] VDD1: ramp_delay not set [ 523.062896] VDD1: ramp_delay not set [ 523.362701] VDD1: ramp_delay not set [ 526.143035] VDD1: ramp_delay not set I have observed this on GTA04 while it is reported to occur on N900 as well: https://bugzilla.kernel.org/show_bug.cgi?id=178371 This patch makes the warning appear only in debugging mode. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
57776617 |
|
19-Sep-2016 |
Joonwoo Park <joonwoop@codeaurora.org> |
regulator: core: don't return error with inadequate reason drms_uA_update() always returns failure when it cannot find regulator's input voltage. But if hardware supports load configuration with ops->set_load() and the input regulator isn't specified with valid reason such as the input regulator is battery, not finding input voltage is normal so such case should not return with an error. Avoid such inadequate error return by checking input/output voltages only when drms_uA_update() is about to configure load with enum based ops->set_mode(). Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
73e705bf |
|
14-Sep-2016 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Add set_voltage_time op The new op is analogous to set_voltage_time_sel. It can be used by regulators which don't have a table of discrete voltages. The function returns the time for the regulator output voltage to stabilize after being set to a new value, in microseconds. If the op is not set a default implementation is used to calculate the delay. This change also removes the ramp_delay calculation in the PWM regulator, since the driver now uses the core code for the calculation of the delay. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d89564ef |
|
14-Sep-2016 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Don't skip set_voltage_time when ramp delay disabled The current code assumes that only the ramp_delay is used to determine the time needed for the voltage to stabilize. This may be true for the calculation done by regulator_set_voltage_time_sel(), however regulators can implement their own set_voltage_time_sel() op which would be skipped if no ramp delay is specified. Remove the check in _regulator_do_set_voltage(), the functions calculating the ramp delay return 0 anyway when the ramp delay is not configured. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
31dfe686 |
|
14-Sep-2016 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Simplify error flow in _regulator_do_set_voltage() If the voltage can not be set jump to the end of the function. This avoids having to check for an error multiple times and eliminates one level of nesting in a follow-up change. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
57995a48 |
|
14-Sep-2016 |
Matthias Kaehlcke <mka@chromium.org> |
regulator: core: Use local ops variable in _regulator_do_set_voltage() Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
565f9b07 |
|
16-Aug-2016 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
regulator: Remove support for optional supplies in the bulk API The patch was based on my missinterpretation of the API and only accidentally worked for me. Let's clean it out to not confuse others. This reverts commit 3ff3f518a135fa4592fe2817e9ac2cce1fa23dc2. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fc1e1c4a |
|
09-Jun-2016 |
Mark Brown <broonie@kernel.org> |
regulator: Remove regulator_can_change_voltage() There is little obvious use case for a regualtor driver to know if it is possible to vary voltages at all by itself. If a consumer needs to limit what voltages it tries to set based on the system configuration then it will need to enumerate the possible voltages, and without that even if it is possible to change voltages that doesn't mean that constraints or other consumers will allow whatever change the driver is trying to do at a given time. It doesn't even indicate if _set_voltage() calls will work as noop _set_voltage() calls return success. There were no users of this API that weren't abusing it and now they're all gone so remove the API. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
45389c47 |
|
26-Apr-2016 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: core: Add early supply resolution for regulators The call to set_machine_constraints() in regulator_register(), will attempt to get the voltage for the regulator. If a regulator is in bypass will fail to get the voltage (ie. it's bypass voltage) and hence register the regulator, because the supply for the regulator has not been resolved yet. To fix this, add a call to regulator_resolve_supply() before we call set_machine_constraints(). If the call to regulator_resolve_supply() fails, rather than returning an error at this point, allow the registration of the regulator to continue because for some regulators resolving the supply at this point may not be necessary and it will be resolved later as more regulators are added. Furthermore, if the supply is still not resolved for a bypassed regulator, this will be detected when we attempt to get the voltage for the regulator and an error will be propagated at this point. If a bypassed regulator does not have a supply when we attempt to get the voltage, rather than returing -EINVAL, return -EPROBE_DEFER instead to allow the registration of the regulator to be deferred and tried again later. Please note that regulator_resolve_supply() will call regulator_dev_lookup() which may acquire the regulator_list_mutex. To avoid any deadlocks we cannot hold the regulator_list_mutex when calling regulator_resolve_supply(). Therefore, rather than holding the lock around a large portion of the registration code, just hold the lock when aquiring any GPIOs and setting up supplies because these sections may add entries to the regulator_map_list and regulator_ena_gpio_list, respectively. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8a34e979 |
|
23-Apr-2016 |
WEN Pingbo <pingbo.wen@linaro.org> |
regulator: refactor valid_ops_mask checking code To make the code more compat and centralized, this patch add a unified function - regulator_ops_is_valid. So we can add some extra checking code easily later. Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c438b9d0 |
|
21-Apr-2016 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: core: Move registration of regulator device The public functions to acquire a regulator, such as regulator_get(), internally look-up the regulator from the list of regulators that have been registered with the regulator device class. The registration of a new regulator with the regulator device class happens before the regulator has been completely setup. Therefore, it is possible that the regulator could be acquired before it has been setup successfully. To avoid this move the device registration of the regulator to the end of the regulator setup and update the error exit path accordingly. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8e5356a7 |
|
21-Apr-2016 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: core: Clear the supply pointer if enabling fails During the resolution of a regulator's supply, we may attempt to enable the supply if the regulator itself is already enabled. If enabling the supply fails, then we will call _regulator_put() for the supply. However, the pointer to the supply has not been cleared for the regulator and this will cause a crash if we then unregister the regulator and attempt to call regulator_put() a second time for the supply. Fix this by clearing the supply pointer if enabling the supply after fails when resolving the supply for a regulator. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7ddede6a |
|
21-Apr-2016 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: core: Don't terminate supply resolution early The function regulator_register_resolve_supply() is called from the context of class_for_each_dev() (during the regulator registration) to resolve any supplies added. regulator_register_resolve_supply() will return an error if a regulator's supply cannot be resolved and this will terminate the loop in class_for_each_dev(). This means that we will not attempt to resolve any other supplies after one has failed. Hence, this may delay the resolution of other regulator supplies until the failing one itself can be resolved. Rather than terminating the loop early, don't return an error code and keep attempting to resolve any other supplies for regulators that have been registered. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2d80a91b |
|
21-Apr-2016 |
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> |
regulator: core: Add debugfs to show constraint flags There are debugfs entries for voltage and current, but not for the constraint flags. It's useful for debugging to be able to see what these flags are so this patch adds a new debugfs file. We can't use debugfs_create_bool for this because the flags are bitfields, so as this needs a special read callback they have been collected into a single file that lists all the flags. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
07c5c3ad |
|
18-Apr-2016 |
Tero Kristo <t-kristo@ti.com> |
regulator: core: remove lockdep assert from suspend_prepare suspend_prepare can be called during regulator init time also, where the mutex is not locked yet. This causes a false lockdep warning. To avoid the problem, remove the lockdep assertion from the function causing the issue. An alternative would be to lock the mutex during init, but this would cause other problems (some APIs used during init will attempt to lock the mutex also, causing deadlock.) Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2c0a303a |
|
12-Apr-2016 |
Mark Brown <broonie@kernel.org> |
regulator: core: Fix locking of GPIO list on free When we acquire a shareable enable GPIO on probe we do so with the regulator_list_mutex held. However when we release the GPIOs we do this immediately after dropping the mutex meaning that the list could become corrupted. Move the release into the locked region to avoid this. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
469b640e |
|
11-Apr-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
regulator: reorder initialization steps in regulator_register() device_register() is calling ->get_voltage() as part of it's sysfs attribute initialization process, and this functions might need to know the regulator constraints to return a valid value. This is at least true for the pwm regulator driver (when operating in continuous mode) which needs to know the minimum and maximum voltage values to calculate the current voltage: min_uV + (((max_uV - min_uV) * dutycycle) / 100); Move device_register() after set_machine_constraints() to make sure those constraints are correctly initialized when ->get_voltage() is called. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Stephen Barber <smbarber@chromium.org> Tested-by: Caesar Wang <wxt@rock-chips.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fef95019 |
|
07-Apr-2016 |
Mark Brown <broonie@kernel.org> |
regulator: core: Use parent voltage from the supply when bypassed When a regulator is in bypass mode it is functioning as a switch returning the voltage set in the regulator will not give the voltage being output by the regulator as it's just passing through its supply. This means that when we are getting the voltage from a regulator we should check to see if it is in bypass mode and if it is we should report the voltage from the supply rather than that which is set on the regulator. Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> [treding@nvidia.com: return early for bypass mode] Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a2151374 |
|
30-Mar-2016 |
Jon Hunter <jonathanh@nvidia.com> |
regulator: Fix deadlock during regulator registration Commit 5e3ca2b349b1 ("regulator: Try to resolve regulators supplies on registration") added a call to regulator_resolve_supply() within regulator_register() where the regulator_list_mutex is held. This causes a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC is registered because regulator_register_resolve_supply() calls regulator_dev_lookup() which may try to acquire the regulator_list_mutex again. Fix this by releasing the mutex before calling regulator_register_resolve_supply() and update the error exit path to ensure the mutex is released on an error. [Made commit message more legible -- broonie] Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
45a91e8f |
|
29-Mar-2016 |
Mark Brown <broonie@kernel.org> |
regulator: core: Log when we bring constraints into range This aids in debugging problems triggered by the regulator core applying its constraints, we could potentially crash immediately after updating the voltage if the constraints are buggy. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5e3ca2b3 |
|
23-Mar-2016 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: Try to resolve regulators supplies on registration Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") moved the regulator supplies lookup logic from the regulators registration to the regulators get time. Unfortunately, that changed the behavior of the regulator core since now a parent supply with a child regulator marked as always-on, won't be enabled unless a client driver attempts to get the child regulator during boot. This patch tries to resolve the parent supply for the already registered regulators each time that a new regulator is registered. So the regulators that have child regulators marked as always on will be enabled regardless if a driver gets the child regulator or not. That was the behavior before the mentioned commit, since parent supplies were looked up at regulator registration time instead of during child get. Since regulator_resolve_supply() checks for rdev->supply, most of the times it will be a no-op. Errors aren't checked to keep the possible out of order dependencies which was the motivation for the mentioned commit. Also, the supply being available will be enforced on regulator get anyways in case the resolve fails on regulators registration. Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> # 4.1+
|
#
fa93fd4e |
|
21-Mar-2016 |
Mark Brown <broonie@kernel.org> |
regulator: core: Ensure we are at least in bounds for our constraints Currently we only attempt to set the voltage during constraints application if an exact voltage is specified. Extend this so that if the currently set voltage for the regulator is outside the bounds set in constraints we will move the voltage to the nearest constraint, raising to the minimum or lowering to the maximum as needed. This ensures that drivers can probe without the hardware being driven out of spec. Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e437b900 |
|
24-Mar-2016 |
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> |
regulator: core: Remove duplicate copy of active-discharge parsing Apparently due to a wrongly resolved merge conflict between two branches, which contained the same commit, the commit contents partially was added two times in a row. This change reverts the latter wrong inclusion of commit 909f7ee0b5f3 ("regulator: core: Add support for active-discharge configuration"). The first applied commit 670666b9e0af ("regulator: core: Add support for active-discharge configuration") is not touched. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
95a293c7 |
|
20-Mar-2016 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: Remove unneded check for regulator supply The regulator_resolve_supply() function checks if a supply has been associated with a regulator to avoid enabling it if that is not the case. But the supply was already looked up with regulator_resolve_supply() and set with set_supply() before the check and both return on error. So the fact that this statement has been reached means that neither of them failed and a supply must be associated with the regulator. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
909f7ee0 |
|
02-Mar-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: core: Add support for active-discharge configuration Add support to enable/disable active discharge of regulator via machine constraints. This configuration is done when setting machine constraint during regulator register and if regulator driver implemented the callback ops. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
670666b9 |
|
02-Mar-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: core: Add support for active-discharge configuration Add support to enable/disable active discharge of regulator via machine constraints. This configuration is done when setting machine constraint during regulator register and if regulator driver implemented the callback ops. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
32165230 |
|
24-Feb-2016 |
Krzysztof Adamski <krzysztof.adamski@tieto.com> |
regulator: core: fix crash in error path of regulator_register This problem was introduced by: commit daad134d6649 ("regulator: core: Request GPIO before creating sysfs entries") The error path was not updated correctly after moving GPIO registration code and in case regulator_ena_gpio_free failed, device_unregister() was called even though device_register() was not yet called. This problem breaks the boot at least on all Tegra 32-bit devices. It will also crash each device that specifices GPIO that is unavaiable at regulator_register call. Here's error log I've got when forced GPIO to be invalid: [ 1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22 [ 1.122794] Unable to handle kernel NULL pointer dereference at virtual address 00000044 [ 1.130894] pgd = c0004000 [ 1.133598] [00000044] *pgd=00000000 [ 1.137205] Internal error: Oops: 5 [#1] SMP ARM and here's backtrace from KDB: Exception stack(0xef11fbd0 to 0xef11fc18) fbc0: 00000000 c0738a14 00000000 00000000 fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff [<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8) [<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58) [<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68) [<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c) [<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4) [<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c) [<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac) [<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84) [<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0) [<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0) [<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440) [<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120) [<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98) [<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138) [<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20) [<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c) [<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc) [<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454) [<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510) [<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104) [<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c) Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com> Reported-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
daad134d |
|
22-Feb-2016 |
Krzysztof Adamski <krzysztof.adamski@tieto.com> |
regulator: core: Request GPIO before creating sysfs entries regulator_attr_is_visible (which is a .is_visible callback of regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if "status" file should be present in sysfs. This field is set at the end of regulator_ena_gpio_request so it has to be called before device_register() otherwise this test will always fail, causing "status" file to not be visible. Since regulator_attr_is_visible also tests for is_enabled() op, this problem is only visible for regulators that does not define this callback, like regulator-fixed.c. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6333ef46 |
|
26-Jan-2016 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Rely on regulator_dev_release to free constraints As we now free the constraints in regulator_dev_release we will still call free on the constraints pointer even if we went down an error path in regulator_register, because it is only allocated after the device_register. As such we no longer need to free rdev->constraints on the error paths, so this patch removes said frees. Fixes: 29f5f4860a8e ("regulator: core: Move more deallocation into class unregister") Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
70dc6daf |
|
07-Jan-2016 |
Dan Carpenter <dan.carpenter@oracle.com> |
regulator: core: remove some dead code Originally queue_delayed_work() used to negative error codes or 0 and 1 on success depending if the work was queued or not. It caused a lot of bugs where people treated all non-zero returns as failures so we changed it to return bool instead in d4283e937861 ('workqueue: make queueing functions return bool'). Now it never returns failure. Checking for negative values causes a static checker warning since it is impossible based on the bool type. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
83080a14 |
|
05-Jan-2016 |
Geliang Tang <geliangtang@163.com> |
regulator: core: use dev_to_rdev Use dev_to_rdev() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
70a7fb80 |
|
02-Dec-2015 |
Thierry Reding <treding@nvidia.com> |
regulator: core: Fix nested locking of supplies Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning") introduced a subtle change in how supplies are locked. Where previously code was always locking the regulator of the current iteration, the new implementation only locks the regulator if it has a supply. For any given power tree that means that the root will never get locked. On the other hand the regulator_unlock_supply() will still release all the locks, which in turn causes the lock debugging code to warn about a mutex being unlocked which wasn't locked. Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
49a6bb7a |
|
01-Dec-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Ensure we lock all regulators The latest workaround for the lockdep interface's not using the second argument of mutex_lock_nested() changed the loop missed locking the last regulator due to a thinko with the loop termination condition exiting one regulator too soon. Reported-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
bb41897e |
|
27-Nov-2015 |
Arnd Bergmann <arnd@arndb.de> |
regulator: core: fix regulator_lock_supply regression As noticed by Geert Uytterhoeven, my patch to avoid a harmless build warning in regulator_lock_supply() was total crap and introduced a real bug: > [ BUG: bad unlock balance detected! ] > kworker/u4:0/6 is trying to release lock (&rdev->mutex) at: > [<c0247b84>] regulator_set_voltage+0x38/0x50 we still lock the regulator supplies, but not the actual regulators, so we are missing a lock, and the unlock is unbalanced. This rectifies it by first locking the regulator device itself before using the same loop as before to lock its supplies. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 716fec9d1965 ("[SUBMITTED] regulator: core: avoid unused variable warning") Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fa731ac7 |
|
20-Nov-2015 |
Arnd Bergmann <arnd@arndb.de> |
regulator: core: avoid unused variable warning The second argument of the mutex_lock_nested() helper is only evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we get this build warning for the new regulator_lock_supply function: drivers/regulator/core.c: In function 'regulator_lock_supply': drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable] To avoid the warning, this restructures the code to make it both simpler and to move the 'i++' outside of the mutex_lock_nested call, where it is now always used and the variable is not flagged as unused. We had some discussion about changing mutex_lock_nested to an inline function, which would make the code do the right thing here, but in the end decided against it, in order to guarantee that mutex_lock_nested() does not introduced overhead without CONFIG_DEBUG_LOCK_ALLOC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9f01cd4a915 ("regulator: core: introduce function to lock regulators and its supplies") Link: http://permalink.gmane.org/gmane.linux.kernel/2068900 Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3ff3f518 |
|
09-Nov-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
regulator: Make bulk API support optional supplies Make it possible to use the bulk API with optional supplies, by allowing the consumer to marking supplies as optional in the regulator_bulk_data. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d9b96d35 |
|
02-Nov-2015 |
Mark Brown <broonie@kernel.org> |
regulator: Use regulator_lock_supply() for get_voltage() too Since we need to read voltages of parents as part of setting supply voltages we need to be able to do get_voltage() internally without taking locks so reorganize the locking to take locks on the full tree on entry rather than as we recurse when called externally. Reported-by: John Stultz <john.stultz@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
fc42112c |
|
20-Oct-2015 |
Sascha Hauer <s.hauer@pengutronix.de> |
regulator: core: Propagate voltage changes to supply regulators Until now changing the voltage of a regulator only ever effected the regulator itself, but never its supplies. It's a common pattern though to put LDO regulators behind switching regulators. The switching regulators efficiently drop the input voltage but have a high ripple on their output. The output is then cleaned up by the LDOs. For higher energy efficiency the voltage drop at the LDOs should be minimized. For this scenario we need to propagate the voltage change to the supply regulators. Another scenario where voltage propagation is desired is a regulator which only consists of a switch and thus cannot regulate voltages itself. In this case we can pass setting voltages to the supply. This patch adds support for voltage propagation. We do voltage propagation when the current regulator has a minimum dropout voltage specified or if the current regulator lacks a get_voltage operation (indicating it's a switch and not a regulator). Changing the supply voltage must be done carefully. When we are increasing the current regulators output we must first increase the supply voltage and then the regulator itself. When we are decreasing the current regulators voltage we must decrease the supply voltage after changing the current regulators voltage. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a204f41e |
|
20-Oct-2015 |
Sascha Hauer <s.hauer@pengutronix.de> |
regulator: core: Factor out regulator_map_voltage _regulator_call_set_voltage has code to translate a minimum/maximum voltage pair into a selector. This code is useful for others aswell, so create a regulator_map_voltage function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a9f226bc |
|
12-Oct-2015 |
Sascha Hauer <s.hauer@pengutronix.de> |
regulator: core: create unlocked version of regulator_set_voltage The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3a40cfc3 |
|
30-Sep-2015 |
Sascha Hauer <s.hauer@pengutronix.de> |
regulator: core: create unlocked version of regulator_list_voltage The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9f01cd4a |
|
30-Sep-2015 |
Sascha Hauer <s.hauer@pengutronix.de> |
regulator: core: introduce function to lock regulators and its supplies Each regulator_dev is locked with its own mutex. This is fine as long as only one regulator_dev is locked, but makes lockdep unhappy when we have to walk up the supply chain like it can happen in regulator_get_voltage: regulator_get_voltage -> mutex_lock(®ulator->rdev->mutex) -> _regulator_get_voltage(regulator->rdev) -> regulator_get_voltage(rdev->supply) -> mutex_lock(®ulator->rdev->mutex); This causes lockdep to issue a possible deadlock warning. There are at least two ways to work around this: - We can always lock the whole supply chain using the functions introduced with this patch. - We could store the current voltage in struct regulator_rdev so that we do not have to walk up the supply chain for the _regulator_get_voltage case. Anyway, regulator_lock_supply/regulator_unlock_supply will be needed once we allow regulator_set_voltage to optimize the supply voltages. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
06423121 |
|
01-Oct-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Handle probe deferral from DT when resolving supplies When resolving regulator-regulator supplies we ignore probe deferral returns from regulator_dev_lookup() (such as are generated for DT when we can see a supply is registered) and just fall back to the dummy regulator if there are full constraints (as is the case for DT). This means that probe deferral is broken for DT systems, fix that by paying attention to -EPROBE_DEFER return codes like we do -ENODEV. A further patch will simplify this further, this is a minimal fix for the specific issue. Fixes: 9f7e25edb1575a6d2 (regulator: core: Handle full constraints systems when resolving supplies) Reported-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonnie@kernel.org> Cc: stable@vger.kernel.org
|
#
85f3b431 |
|
21-Sep-2015 |
Tomeu Vizoso <tomeu.vizoso@collabora.com> |
regulator: core: Remove regulator_list As we are already registering a device with regulator_class for each regulator device, regulator_list is redundant and can be replaced with calls to class_find_device() and class_for_each_device(). Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
23c3f310 |
|
17-Sep-2015 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Correct return value check in regulator_resolve_supply The ret pointer passed to regulator_dev_lookup is only filled with a valid error code if regulator_dev_lookup returned NULL. Currently regulator_resolve_supply checks this ret value before it checks if a regulator was returned, this can result in valid regulator lookups being ignored. Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
7ebcf26c |
|
16-Sep-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: core: Make error messages more informative The same error print exists 4 times in the regulator core <rdev>: operation not allowed Unfortunately, seeing this in the dmesg is not very informative. Add what type of operation is not allowed to the message so that these errors are unique, hopefully pointing developers in the right direction <rdev>: drms operation not allowed <rdev>: voltage operation not allowed <rdev>: current operation not allowed <rdev>: mode operation not allowed Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9f8df6ad |
|
02-Sep-2015 |
Sudip Mukherjee <sudipm.mukherjee@gmail.com> |
regulator: core: fix possible NULL dereference We were checking rdev->supply for NULL after dereferencing it. Lets check for rdev->supply along with _regulator_is_enabled() and call regulator_enable() only if rdev->supply is not NULL. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
099982fa |
|
28-Aug-2015 |
Archit Taneja <architt@codeaurora.org> |
regulator: core: use debug level print in regulator_check_drms When calling regulator_set_load, regulator_check_drms prints and returns an error if the regulator device's flag REGULATOR_CHANGE_DRMS isn't set. drms_uA_update, however, bails out without reporting an error. Replace the error print with a debug level print so that we don't get such prints when the underlying regulator doesn't support DRMS. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
93576842 |
|
16-Aug-2015 |
Viresh Kumar <viresh.kumar@linaro.org> |
regulator: core: Use IS_ERR_OR_NULL() Use IS_ERR_OR_NULL() rather than open coding it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ad3a942b |
|
01-Jun-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: core: Print at debug level on debugfs creation failure Failure to create a debugfs node is not an error, but we print a warning upon failure to create the node. Downgrade this to a debug printk so that we're quiet here. This allows multiple drivers to request a CPU's regulator so that CPUfreq and AVSish drivers can coexist. The downside of this approach is that whoever gets to debugfs first the others who come later to not have any debugfs attributes associated with them. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
d3fb9800 |
|
13-Aug-2015 |
Viresh Kumar <viresh.kumar@linaro.org> |
regulator: core: Spelling fix Trivial spell fix, s/succesfully/successfully. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
609ca5f3 |
|
10-Aug-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Use class device list for regulator_list in late init The regulator_list has exactly the same contents as the list that the driver core maintains of regulator_class members so is redundant. As a first step in converting over to use the class device list convert our iteration in late_initcall() to use the class device iterator. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
29f5f486 |
|
07-Aug-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Move more deallocation into class unregister We really ought to be using the class dvice lifetime management features more than we are rather than open coding them so take a step towards that by moving some of the simplest deallocations to the dev_release() function. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1768514e |
|
07-Aug-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Reduce rdev locking region when releasing regulator When we release a regulator we need to remove references to it from the rdev which means locking the rdev. Currently we also free resources associated with the regulator inside the rdev lock but there is no need to do this, we can reduce the region the lock is held by restricting it to just actions that affect the rdev. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7cd71c3b |
|
07-Aug-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Drop regulator_list_mutex when we're done with it on remove When removing a regulator we hold regulator_list_mutex in order to ensure the regualtor doesn't become removed again. However we only need to protect the list until we remove the regulator from the list so move the unlock earlier to reduce the locked region. Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3a003bae |
|
17-Jul-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add over current protection (OCP) support Some regulators can automatically shut down when they detect an over current event. Add an op (set_over_current_protection) and a DT property + constraint to support this capability. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
36a1f1b6 |
|
15-Jul-2015 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: core: Fix memory leak in regulator_resolve_supply() The regulator_resolve_supply() function calls set_supply() which in turn calls create_regulator() to allocate a supply regulator. If an error occurs after set_supply() succeeded, the allocated regulator has to be freed before propagating the error code. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e2c09ae7 |
|
15-Jul-2015 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: core: Increase refcount for regulator supply's module When a regulator is unregistered with regulator_unregister(), a call to regulator_put() is made for its input supply if there is one. This does a module_put() to decrement the refcount of the module that owns the supply but there isn't a corresponding try_module_get() in set_supply() to make the calls balanced. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9f7e25ed |
|
14-Jul-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Handle full constraints systems when resolving supplies When resolving device supplies if we fail to look up the regulator we substitute in the dummy supply instead if the system has fully specified constraints. When resolving supplies for regulators we do not have the equivalent code and instead just directly use the regulator_dev_lookup() result causing spurious failures. This does not affect DT systems since we are able to detect missing mappings directly as part of regulator_dev_lookup() and so have appropriate handling in the DT specific code. Reported-by: Christian Hartmann <cornogle@googlemail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
70cfef26 |
|
28-Jun-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
regulator: Add lockdep asserts to help detecting locking misuse Add lockdep_assert_held_once() to functions explicitly mentioning that rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't pollute the dmesg to much. The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain regulators calling regulator_notifier_call_chain() without rdev->mutex held. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
36e4f839 |
|
11-Jun-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add input current limit support Some regulators can limit their input current (typically annotated as ilim). Add an op (set_input_current_limit) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
57f66b78 |
|
11-Jun-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add soft start support Some regulators support a "soft start" feature where the voltage ramps up slowly when the regulator is enabled. Add an op (set_soft_start) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
23c779b9 |
|
11-Jun-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add pull down support Some regulators need to be configured to pull down a resistor when the regulator is disabled. Add an op (set_pull_down) and a DT property + constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
22a10bca |
|
11-Jun-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add system_load constraint Some regulators have a fixed load that isn't captured by consumers that the kernel knows about. Add a constraint to support this. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5751a99f |
|
10-Jun-2015 |
Stefan Wahren <stefan.wahren@i2se.com> |
regulator: core: replace sprintf with scnprintf In order to avoid potential overflows in print_constraints we better replace sprintf() with scnprintf(). Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a7068e39 |
|
09-Jun-2015 |
Stefan Wahren <stefan.wahren@i2se.com> |
regulator: core: fix constraints output buffer The buffer for condtraints debug isn't big enough to hold the output in all cases. So fix this issue by increasing the buffer. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
|
#
c456b89a |
|
09-Jun-2015 |
Mark Brown <broonie@kernel.org> |
regulator: core: Don't corrupt display when printing uV offsets We weren't taking into account the already used buffer when telling sprintf() where to print to. Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
ff268b56 |
|
01-Jun-2015 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: core: Don't spew backtraces on duplicate sysfs We don't consider a failure to add the sysfs node as a problem, so use sysfs_create_link_nowarn() so that we don't print a backtrace when duplicated files exist. Also, downgrade the printk message to a debug statement so that we're quiet here. This allows multiple drivers to request a CPU's regulator so that CPUfreq and AVSish drivers can coexist. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
23296099 |
|
10-Apr-2015 |
Heiko Stübner <heiko@sntech.de> |
regulator: output current-limit for all regulators in summary Voltage regulators can have (unregulated) current limits too, so we should probably output both voltage and current for all regulators. Holding the rdev->mutex actually conflicts with _regulator_get_current_limit but also is not really necessary, as the global regulator_list_mutex already protects us from the regulator vanishing while we go through the list. On the rk3288-firefly the summary now looks like: regulator use open bypass voltage current min max ------------------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 0mA 5000mV 5000mV vcc_lan 1 1 0 3300mV 0mA 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 0mA 3300mV 3300mV vcca_18 0 0 0 1800mV 0mA 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 0mA 1000mV 1000mV [...] Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7c225ec9 |
|
07-Apr-2015 |
Heiko Stübner <heiko@sntech.de> |
regulator: add a summary tree in debugfs On modern systems the regulator hierarchy can get quite long and nested with regulators supplying other regulators. In some cases when debugging it might be nice to get a tree of these regulators, their consumers and the regulation constraints in one go. To achieve this add a regulator_summary sysfs node, similar to clk_summary in the common clock framework, that walks the regulator list and creates a tree out of the regulators, their consumers and core per-regulator settings. On a rk3288-firefly the regulator_summary would for example look something like: regulator use open bypass value min max ----------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 5000mV 5000mV vcc_lan 1 1 0 3300mV 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 3300mV 3300mV vcca_18 0 0 0 1800mV 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 1000mV 1000mV vccio_sd 0 0 0 3300mV 3300mV 3300mV vcc_20 0 3 0 2000mV 2000mV 2000mV vcc18_lcd 0 0 0 1800mV 1800mV 1800mV vcc_18 0 2 0 1800mV 1800mV 1800mV ff100000.saradc 0mV 0mV ff0d0000.dwmmc 1650mV 1950mV vdd_10 0 0 0 1000mV 1000mV 1000mV vdd_log 0 0 0 1100mV 1100mV 1100mV vcc_io 0 3 0 3300mV 3300mV 3300mV ff0f0000.dwmmc 3300mV 3400mV vcc_flash 1 1 0 1800mV 1800mV 1800mV ff0f0000.dwmmc 1700mV 1950mV vcc_sd 1 1 0 3300mV 3300mV 3300mV ff0c0000.dwmmc 3300mV 3400mV vcc_ddr 0 0 0 1200mV 1200mV 1200mV vdd_gpu 0 0 0 1000mV 850mV 1350mV vdd_cpu 0 1 0 900mV 850mV 1350mV cpu0 900mV 900mV vcc_5v 0 2 0 5000mV 5000mV 5000mV vcc_otg_5v 0 0 0 5000mV 5000mV 5000mV vcc_host_5v 0 0 0 5000mV 5000mV 5000mV regulator-dummy 0 0 0 0mV 0mV 0mV Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6261b06d |
|
24-Mar-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
regulator: Defer lookup of supply to regulator_get Instead of resolving regulator supplies during registration move this to the time of a consumer retrieving a handle. The benefit is that it's possible for one driver to register regulators with internal dependencies out of order. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a9eaa813 |
|
17-Oct-2014 |
Guenter Roeck <linux@roeck-us.net> |
regulator: Ensure unique regulator debugfs directory names If multiple regulator devices of the same type exist in a system, the regulator driver assigns generic names for the regulators it provides, and debugfs is enabled, the regulator subsystem attempts to create multiple entries with the same name in the regulator debugfs directory. This fails for all but the first regulator, resulting in multiple "Failed to create debugfs directory" log entries. To avoid the problem, prepend the debugfs directory name for a regulator with its parent device name if available, but only if no explicit regulator name was provided. Cc: Alan Tull <atull@opensource.altera.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e39ce48f |
|
11-Feb-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
regulator: Rename regulator_set_optimum_mode Rename the regulator_set_optimum_mode() function regulator_set_load() to better represent what's going on. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
29d62ec5 |
|
03-Mar-2015 |
Doug Anderson <dianders@chromium.org> |
regulator: core: Fix enable GPIO reference counting Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list") Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
0548bf4f |
|
02-Mar-2015 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: Only enable disabled regulators on resume The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
cde72ccf |
|
03-Mar-2015 |
Takashi Iwai <tiwai@suse.de> |
regulator: Fix regression due to NULL constraints check The commit [39f802d6b6d9: 'regulator: Build sysfs entries with static attribute groups'] converted the sysfs entry creation to static attribute groups, but this resulted in a regression due to the NULL check of rdev->constraints. At the point where the device is registered, rdev->constraints isn't set, so the attributes depending on it are missing. We may fix it by shuffling the code order in regulator_register(), but a quicker fix is to just remove this NULL check. rdev->constraints is in anyway always set to non-NULL in set_machine_constraints(), thus the check there is basically superfluous. Fixes: 39f802d6b6d9 ('regulator: Build sysfs entries with static attribute groups') Signed-off-by: Takashi Iwai <tiwai@suse.de> Reportded-by: Steve Twiss <stwiss.opensource@diasemi.com> Tested-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8f4490e0 |
|
11-Feb-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
regulator: core: Introduce set_load op Expose the requested load directly to the regulator implementation for hardware that does not support the normal enum based set_mode(). Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
39f802d6 |
|
30-Jan-2015 |
Takashi Iwai <tiwai@suse.de> |
regulator: Build sysfs entries with static attribute groups Instead of calling device_create_file() manually after the device registration, put all in attribute groups and filter the unwanted ones via is_visible callback. This not only simplifies the code but also avoids the possible race between the device registration and sysfs registration. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8460ef38 |
|
27-Jan-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
regulator: core: Consolidate drms update handling Refactor drms_uA_update() slightly to allow regulator_set_optimum_mode() to utilize the same logic instead of duplicating it. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f47531b1 |
|
12-Jan-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
regulator: Update documentation after renaming function argument Update documentation for regulator_register() function after renaming its argument. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
bfa21a0d |
|
04-Jan-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
regulator: Allow parsing custom properties when using simplified DT parsing When drivers use simplified DT parsing method (they provide 'regulator_desc.of_match') they still may want to parse custom properties for some of the regulators. For example some of the regulators support GPIO enable control. Add a driver-supplied callback for such case. This way the regulator core parses common bindings offloading a lot of code from drivers and still custom properties may be used. The callback, called for each parsed regulator, may modify the 'regulator_config' initially passed to regulator_register(). Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1b3de223 |
|
04-Jan-2015 |
Krzysztof Kozlowski <krzk@kernel.org> |
regulator: Copy config passed during registration Copy the 'regulator_config' structure passed to regulator_register() function so the driver could safely modify it after parsing init data. The driver may want to change the config as a result of specific init data parsed by regulator core (e.g. when core handled parsing device tree). Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
83b0302d |
|
08-Jan-2015 |
Ashay Jaiswal <ashayj@codeaurora.org> |
regulator: core: fix race condition in regulator_put() The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
|
#
39138818 |
|
29-Dec-2014 |
Aniroop Mathur <aniroop.mathur@gmail.com> |
regulator: core: Fix format specifier warning Signed-off-by: Aniroop Mathur <a.mathur@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
72dca06f |
|
28-Dec-2014 |
Aniroop Mathur <aniroop.mathur@gmail.com> |
regulator: core: Avoid negative regulator no & initialize it to -1 This patch initializes regulator_no to -1 to avoid extra subtraction operation performed every time we register a regulator and avoid negative regulator no in its name. Signed-off-by: Aniroop Mathur <a.mathur@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
60a2362f |
|
04-Dec-2014 |
Seung-Woo Kim <sw0312.kim@samsung.com> |
regulator: core: Fix regualtor_ena_gpio_free not to access pin after freeing After freeing pin from regulator_ena_gpio_free, loop can access the pin. So this patch fixes not to access pin after freeing. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a1c8a551 |
|
24-Nov-2014 |
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> |
regulator: core: Add PRE_DISABLE notification Add a PRE_DISABLE notification so that consumers can use a notifier to run any steps required to prepare for the regulator being switched off. Since the regulator disable can fail an abort notification is also added. Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
194dbaef |
|
31-Oct-2014 |
Mark Brown <broonie@kernel.org> |
regulator: Lower priority of constraint logging Some systems have very large numbers of regulators so the constraint logging done at startup can end up being a very big part of the boot output which is both verbose and slows things down if the console is a serial console. Lower to dev_dbg() instead, we may want to provide a boot parameter to raise this in future but for now people can edit the source. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
|
#
76f439df |
|
08-Oct-2014 |
Markus Pargmann <mpa@pengutronix.de> |
regulator: Add ena_gpio_initialized to regulator_config Most drivers do not set the ena_gpio field of struct regulator_config before passing it to the regulator core. This is fine as long as the gpio identifier that is passed is a positive integer. But the gpio identifier 0 is also valid. So we are not able to decide wether we got a real gpio identifier or not based on a 0 in ena_gpio. To be able to decide if it is a valid gpio that got passed, this patch adds a ena_gpio_initialized field that should be set if was initialized with a correct value, either a gpio >= 0 or a negative error number. The core then checks if ena_gpio or ena_gpio_initialized before handling it as a gpio. This way we maintain backwards compatibility and fix the behaviour for gpio number 0. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a0c7b164 |
|
09-Sep-2014 |
Mark Brown <broonie@kernel.org> |
regulator: of: Provide simplified DT parsing method Currently regulator drivers which support DT all repeat very similar code to supply a list of known regulator identifiers to be matched with DT, convert that to platform data which is then matched up with the regulators as they are registered. This is both fiddly to get right and for devices which can use the standard helpers to provide their operations is the main source of code in the driver. Since this code is essentially identical for most drivers we can factor it out into the core, moving the identifiers in the match table into the regulator descriptors and also allowing drivers to pass in the name of the subnode to search. When a driver provides an of_match string for the regulator the core will attempt to use that to obtain init_data, allowing the driver to remove all explicit code for DT parsing and simply provide data instead. The current code leaks the phandles for the child nodes, this will be addressed incrementally and makes no practical difference for FDT anyway as the DT data structures are never freed. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
7179569a |
|
28-Aug-2014 |
Heiko Stübner <heiko@sntech.de> |
regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT) In some cases we need to know when a regulator is about to be changed. Add a way for clients to be notified. Note that for set_voltage() we don't necessarily know what voltage we'll end up with, so we tell the client what the range will be so they can prepare. Signed-off-by: Heiko Stübner <heiko@sntech.de> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie+linaro@kernel.org>
|
#
39f5460d |
|
19-Aug-2014 |
Guodong Xu <guodong.xu@linaro.org> |
regulator: core: add const to regulator_ops and fix build error in mc13892 Commit 272e2315fac3 ("regulator: core: add const qualifier to ops in struct regulator_desc") introduced const qualifier to ops in regulator_desc. This patch adds 'const' to regulator_ops vars in newly added core APIs for v3.17-rc1: - regulator_get_hardware_vsel_register() - regulator_list_hardware_vsel() This patch also fix a build error in mc13892-regulator.c due to const regulator_desc.ops. Modification of regulator_desc.ops' member fields is not allowed. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
871f5650 |
|
13-Aug-2014 |
Guodong Xu <guodong.xu@linaro.org> |
regulator: core: add guard delay between calling regulator_disable and _enable Some regulator require a minimum delay between its disable and next enable. This is to avoid damages when out-of-range frequent disable/enable of a single regulator can bring to the regulator chip. Add @off_on_delay to struct regulator_desc. Device drivers' can use this field to set this guard time. Add @last_off_jiffy to struct regulator_dev. When @off_on_delay is set by driver, regulator core can store its last off (disable) time into this field. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
79fd1141 |
|
13-Aug-2014 |
Guodong Xu <guodong.xu@linaro.org> |
regulator: core: factor out delay function from _regulator_do_enable A common delay function can be helpful when implementing new features. Factor it out to maximize code reusability. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
272e2315 |
|
13-Aug-2014 |
Guodong Xu <guodong.xu@linaro.org> |
regulator: core: add const qualifier to ops in struct regulator_desc struct regulator_ops *ops is a member in struct regulator_desc, which gets its value from individual regulator driver upon regulator_register() and is used by regulator core APIs. It's not allowed for regulator core to modify any of these callbacks in *ops. Add 'const' qualifier to enforce that. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
26988efe |
|
29-Jul-2014 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: core: Allow to get voltage count and list from parent Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So, the drivers for these switches usually neither provide a .list_voltage handler not set a .n_voltages count. But there is code in the kernel that assumes that all regulators should be able to provide this information (e.g: cpufreq and mmc subsystems). If the voltage count and list are not available for a regulator and it has a parent input supply, then use the parent values. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
e303996e |
|
29-Jul-2014 |
Javier Martinez Canillas <javier@osg.samsung.com> |
regulator: core: Get voltage from parent if not available Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So the drivers for these switches usually don't provide a .get_voltage function handler but there is code in the kernel that assumes that all regulators should be able to provide its current voltage rail. So, if the output voltage for a regulator is not available and it has a parent supply, then pass the voltage of its parent. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
04eca28c |
|
21-Jul-2014 |
Tuomas Tynkkynen <ttynkkynen@nvidia.com> |
regulator: Add helpers for low-level register access Add helper functions that allow regulator consumers to obtain low-level details about the regulator hardware, like the voltage selector register address and such. These details can be useful when configuring hardware or firmware that want to do low-level access to regulators, with no involvement from the kernel. The use-case for Tegra is a voltage-controlled oscillator clocksource which has control logic to change the supply voltage via I2C to achieve a desired output clock rate. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
778b28b4 |
|
29-Jun-2014 |
Russell King <rmk+kernel@arm.linux.org.uk> |
regulator: core: convert to use gpio_desc internally Convert the regulator GPIO handling to use a gpio descriptor rather than numbers. This allows us to revise the interfaces to permit all GPIOs to be used with the regulator core. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
69d58839 |
|
04-Jun-2014 |
Nishanth Menon <nm@ti.com> |
regulator: core: print error value when constraints are not applied With commit 064d5cd110f94ce41ca5681dcda8b77fa63d5b95 (regulator: core: Fix the init of DT defined fixed regulators) We ensure that regulator must be capable of providing it's current voltage when constraints are used, however adding the return value in the print is a little more informative to explain the nature of the failure involved. So, instead of providing message such as: smps9: failed to get the current voltage having error value added to the message such as: smps9: failed to get the current voltage(-22) is a little more informative for debugging the error. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
064d5cd1 |
|
19-May-2014 |
Alban Bedel <alban.bedel@avionic-design.de> |
regulator: core: Fix the init of DT defined fixed regulators When a regulator is defined using DT and it has a single voltage the regulator init always tries to apply this voltage. However it fails if the regulator isn't settable because it is using an internal low level function. To overcome this we now first query the regulator and only set it if needed. Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
fd482a3e |
|
23-Apr-2014 |
Saravana Kannan <skannan@codeaurora.org> |
regulator: core: Disable unused regulators after deferred probing is done regulator_init_complete does a scan of regulators which dont have always-on or consumers are automatically disabled as being unused. However, with deferred probing, late_initcall() is too soon to declare a regulator as unused as the regulator itself might not have registered due to defferal - Example: A regulator deffered due to i2bus not available which in turn is deffered due to pinctrl availability. Since deferred probing is done in late_initcall(), do the cleanup of unused regulators by regulator_init_complete in late_initcall_sync instead of late_initcall. Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [nm@ti.com: minor rewording] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
e9535834 |
|
01-Jun-2014 |
Mark Brown <broonie@linaro.org> |
regulator: Don't disable unused regulators we don't have permission for In the spirit of conservatism that governs our general approach to permissions it is better if we don't touch regulators we weren't explicitly given permissions to control. This avoids the need to explicitly specify unknown regulators in DT as always on, if a regulator is not otherwise involved in software control it can be omitted from the DT. Regulators explicitly given constraints in DT still need to have an always on constraint specified as before. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
69c3f723 |
|
28-May-2014 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Fix regulator_get_{optional,exclusive}() documentation regulator_get_optional() doesn't hold an exclusive reference to the regulator. Fix the documentation and reword the exclusive documentation to fix the grammatical error "this reference is held". Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
36698627 |
|
23-May-2014 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Use map_voltage_linear_range by default for list_voltage_linear_range Use map_voltage_linear_range() if list_voltage_linear_range() is in use and nothing is set. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
9f8c0fe9 |
|
23-May-2014 |
Lee Jones <lee.jones@linaro.org> |
regulator: Constify the pointer to alias name array Toughen-up checks for read-only regulator names. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
63c7c9e1 |
|
03-Apr-2014 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Get and put regulator of_node Currently the regulator core does not take an additional reference to the of_node it is passed. This means that the caller must ensure that the of_node is valid for the duration of the regulator's existance. It is reasonable for the framework to assume it is passed a valid of_node but seems onerous for it to assume the caller will keep the node valid for the life-time of the regulator, especially when devm_regulator_register is used and there will likely be no code in the driver called at the point it would be safe to put the of_node. This patch adds an additional of_node_get when the regulator is registered and an of_node_put when it is unregistered in the core. This means individual drivers are free to put their of_node references at the end of probe letting the regulator core handling it from there. This simplifies code on the driver side. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
66fda75f |
|
20-Feb-2014 |
Markus Pargmann <mpa@pengutronix.de> |
regulator: core: Replace direct ops->disable usage There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
30c21971 |
|
20-Feb-2014 |
Markus Pargmann <mpa@pengutronix.de> |
regulator: core: Replace direct ops->enable usage There are some direct ops->enable in the regulator core driver. This is a potential issue as the function _regulator_do_enable() handles gpio regulators and the normal ops->enable calls. These gpio regulators are simply ignored when ops->enable is called directly. One possible bug is that boot-on and always-on gpio regulators are not enabled on registration. This patch replaces all ops->enable calls by _regulator_do_enable. [Handle missing enable operations -- broonie] Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> regulator: Handle invalid enable operation for always/boot on regulators Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
acc3d5ce |
|
20-Feb-2014 |
Shuah Khan <shuah@kernel.org> |
regulator: core: Change dummy supplies error message to a warning Change "dummy supplies not allowed" error message to warning instead, as this is a just warning message with no change to the behavior. [Added a CC to stable since some other bug fixes cause this to come up more frequently on PCs which is how it was noticed -- broonie] Signed-off-by: Shuah Khan <shuah.kh@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
|
#
e227867f |
|
18-Feb-2014 |
Masanari Iida <standby24x7@gmail.com> |
treewide: Fix typo in Documentation/DocBook This patch fix spelling typo in Documentation/DocBook. It is because .html and .xml files are generated by make htmldocs, I have to fix a typo within the source files. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
c00dc359 |
|
05-Feb-2014 |
Bjorn Andersson <bjorn@kryo.se> |
regulator: core: Allow regulator_set_voltage for fixed regulators Make it okay to call regulator_set_voltage on regulators with fixed voltage if the requested range overlaps the current/configured voltage. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
317b5684 |
|
27-Jan-2014 |
Mark Brown <broonie@linaro.org> |
regulator: core: Correct default return value for full constraints Once we have full constraints then all supply mappings should be known to the regulator API. This means that we should treat failed lookups as fatal rather than deferring in the hope of further registrations but this was broken by commit 9b92da1f1205bd25 "regulator: core: Fix default return value for _get()" which was targeted at DT systems but unintentionally broke non-DT systems by changing the default return value. Fix this by explicitly returning -EPROBE_DEFER from the DT lookup if we find a property but no corresponding regulator and by having the non-DT case default to -ENODEV when we have full constraints. Fixes: 9b92da1f1205bd25 "regulator: core: Fix default return value for _get()" Signed-off-by: Mark Brown <broonie@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org
|
#
0d25d09d |
|
07-Jan-2014 |
Jingoo Han <jg1.han@samsung.com> |
regulator: core: Fix checkpatch issue Fix the following checkpatch errors and warnings. ERROR: trailing whitespace ERROR: return is not a function, parentheses are not required WARNING: braces {} are not necessary for single statement blocks Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
0781719b |
|
17-Dec-2013 |
Hans de Goede <hdegoede@redhat.com> |
regulator: core: don't print an error when no regulator is found Only print an error when _regulator_get() is expected to return a valid regulator, that is when _regulator_get() is called from regulator_get() and we're not using the dummy because we don't have full-constraints, or when _regulator_get() is called from regulator_get_exclusive() in which case returning a dummy is not allowed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
75bc9641 |
|
27-Nov-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Check for DT every time we check full constraints Eliminate the gap between DT becoming available and this being used to say we have full constraints by checking directly for DT every time we check for full constraints. This improves interoperaton with optional regulator support. Signed-off-by: Mark Brown <broonie@linaro.org> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
|
#
87b28417 |
|
27-Nov-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Replace checks of have_full_constraints with a function Simple code reorganisation so we can change the logic for deciding what full constraints are more easily. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
f446043f |
|
12-Nov-2013 |
Guennadi Liakhovetski <g.liakhovetski@gmx.de> |
regulator: fixed: fix regulator_list_voltage() for regression Commit c368e5fc2a190923b786f2de3e79430ea3566a25 "regulator: fixed: get rid of {get|list}_voltage()" broke regulator_list_voltage() for the fixed regulator, because an earlier commit 5a523605afa7d3b54b2e7041f8c9e6bc39872a7e "regulator: core: provide fixed voltage in desc for single voltage rail" missed to add support for the fixed-voltage special case to that function. This patch fixes that regression. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
a06ccd9c |
|
15-Oct-2013 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Add ability to create a lookup alias for supply These patches add the ability to create an alternative device on which a lookup for a certain supply should be conducted. A common use-case for this would be devices that are logically represented as a collection of drivers within Linux but are are presented as a single device from device tree. It this case it is necessary for each sub device to locate their supply data on the main device. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
4040394e |
|
04-Oct-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Always warn when using a dummy regulator This helps people spot if they have missed a supply from a device tree or equivalent data structure. Suggested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
5df529d4 |
|
20-Sep-2013 |
Thierry Reding <thierry.reding@gmail.com> |
regulator: core: Reduce busy-wait looping Keep busy-wait looping to a minimum while waiting for a regulator to ramp-up to the target voltage. This follows the guidelines set forth in Documentation/timers/timers-howto.txt and assumes that regulators are never enabled in atomic context. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
ef60abbb |
|
23-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Always use return value when regulator_dev_lookup() fails Ensure that the return value is always set when we return now that the logic has changed for regulator_get_optional() so we don't get missing codes leaking out. Reported-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
043c998f |
|
19-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Fix return code for invalid parameters We should be returning an error, a repeated call will never succeed. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
9b92da1f |
|
19-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Fix default return value for _get() Now that we are defaulting to providing dummy regulators fix the logic for substituting a dummy by making the default return code -EPROBE_DEFER. Reported-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
f8c1700d |
|
20-Sep-2013 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: core: set current constraints while setting machine constraints Machine constraints is configured during regulator register. If current constraints are provided through machine constraints then it is observed that sometime the current configured on rail is out of range what machine constraint has. Set the current constraints when setting machine constraints to make sure that rail's current is within the range of given machine constraints. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
00c877c6 |
|
18-Sep-2013 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: core: add support for configuring turn-on time through constraints The turn-on time of the regulator depends on the regulator device's electrical characteristics. Sometimes regulator turn-on time also depends on the capacitive load on the given platform and it can be more than the datasheet value. The driver provides the enable-time as per datasheet. Add support for configure the enable ramp time through regulator constraints so that regulator core can take this value for enable time for that regulator. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
4f0ac6da |
|
13-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Remove unused regulator_use_dummy_regulator() No boards have used this functionality and the new default of providing dummy regulators by default provides a better solution to the problem it was trying to solve. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
4ddfebd3 |
|
13-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Provide a dummy regulator with full constraints When a system has said that it has fully specified constraints for its regulators it is still possible that some supplies may be missing, especially if regulator support has been added to a driver after the board was integrated. We can handle such situations more gracefully by providing a dummy regulator. Unless the caller has specifically indicated that the system design may not include a given regulator by using regulator_get_optional() or that it needs its interactions to have an effect using regulator_get_exclusive() provide a dummy regulator if we can't locate a real one. The kconfig option REGULATOR_DUMMY that provided similar behaviour for all regulators has been removed, systems that need it should flag that they have full constraints instead. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
0cdfcc0f |
|
11-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Split devres code out into a separate file Cut down on the size of core.c a bit more and ensure that the devres versions of things don't do too much peering inside the internals of the APIs they wrap. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
cee8e355 |
|
31-Aug-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Refactor devm_regulator_get* APIs The implementation of devm_regulator_get, devm_regulator_get_exclusive and devm_regulator_get_optional are almost the same. Introduce _devm_regulator_get helper function and refactor the code. Also move devm_regulator_get_exclusive to proper place, put it after regulator_get_exclusive() function. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
42141f22 |
|
04-Sep-2013 |
Sachin Kamat <sachin.kamat@linaro.org> |
regulator: core: Fix a trivial typo Changed automaticall -> automatically. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
b33e46bc |
|
31-Aug-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Provide managed regulator registration Many regulator drivers have a remove function that consists solely of calling regulator_unregister() so provide a devm_regulator_register() in order to allow this repeated code to be removed and help eliminate error handling code. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
5a523605 |
|
10-Sep-2013 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: core: provide fixed voltage in desc for single voltage rail If given rail has the single voltage (n_voltages = 1) then provide the rail voltage through regulator descriptor so that core can use this value for finding voltage. This will avoid the implementation of the callback for get_voltage() or list_voltage() callback on regulator driver. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
9efdd276 |
|
25-Aug-2013 |
Matthias Kaehlcke <matthias.list@kaehlcke.net> |
regulator: Add devm_regulator_get_exclusive() Add a resource managed regulator_get_exclusive() Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
84fcf447 |
|
18-Aug-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Use bool for exclusivitity flag Just for neatness. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
d295f767 |
|
09-Aug-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Move list_voltage_{linear,linear_range,table} to helpers.c Move regulator_list_voltage_{linear,linear_range,table} helper functions to helpers.c. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
c4a54b8d |
|
05-Aug-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Move helpers for drivers out into a separate file Reduce the size of core.c a bit. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
de1dd9fd |
|
29-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Provide hints to the core about optional supplies While the majority of supplies on devices are mandatory and can't be physically omitted for electrical reasons some devices do have optional supplies and need to know if they are missing, MMC being the most common of these. Currently the core accurately reports all errors when regulators are requested since it does not know if the supply is one that must be provided even if by a regulator software does not know about or if it is one that may genuinely be disconnected. In order to allow this behaviour to be changed and stub regulators to be provided in the former case add a new regulator request function regulator_get_optional() which provides a hint to the core that the regulator may genuinely not be connected. Currently the implementation is identical to the current behaviour, future patches will add support in the core for returning stub regulators in the case where normal regulator_get() fails and the board has requested it. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Chris Ball <cjb@laptop.org>
|
#
587cea27 |
|
24-Jul-2013 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
regulator: core: convert class code to use dev_groups The dev_attrs field of struct class is going away soon, dev_groups should be used instead. This converts the regulator class code to use the correct field. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
6c918d22 |
|
18-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Ensure selector is mapped Clearly the testing only covered the bottom range. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
a56d66a2 |
|
18-Jul-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Allow fixed voltage range in multiple linear ranges Current code does not allow fixed voltage range in multiple linear ranges. If someone does set range->uV_step == 0 in one of the linear ranges, we hit divided by zero bug. This patch fixes this issue. For fixed voltage range, return any selector means the same voltage. Thus just return 0. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
070260f0 |
|
18-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Use the power efficient workqueue for delayed powerdown There is no need to use a normal per-CPU workqueue for delayed power downs as they're not timing or performance critical and waking up a core for them would defeat some of the point. Signed-off-by: Mark Brown <broonie@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
|
#
5b175952 |
|
29-Jun-2013 |
Yadwinder Singh Brar <yadi.brar@samsung.com> |
regulator: core: Remove redundant checks In function _regulator_do_set_voltage(), old_selector gets intialised only if (_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel && rdev->desc->ops->get_voltage_sel)) is true. Before calling set_voltage_time_sel() we checks if (old_selector >= 0) and it will true if it got intialised properly. so we don't need to check again _regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel before calling set_voltage_time_sel(). Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
1653ccf4 |
|
29-Jun-2013 |
Yadwinder Singh Brar <yadi.brar@samsung.com> |
regulator: core: Add support for disabling ramp delay Some hardwares support disabling ramp delay, so adding ramp_disable flag to constraints. It will be used to figure out whether ramp_delay in constraints is explicitly set to zero or its unintialized (zero by default). And we don't need to call set_voltage_time_sel() for regulators for whom ramp delay is disabled in constraints. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
94d33c02 |
|
02-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Add helpers for multiple linear ranges Many regulators have several linear ranges of selector with different step sizes, for example offering better resolution at lower voltages. Provide regulator_{map,list}_voltage_linear_range() allowing these regulators to use generic code. To do so a table of regulator_linear_range structs needs to be pointed to from the descriptor. This was inspired by similar code included in a driver submission from Chao Xie and Yi Zhang at Marvell. Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
891636ea |
|
08-Jul-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Drop references on supply regulator when unregistering Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
2a668a8b |
|
07-Jun-2013 |
Paul Walmsley <pwalmsley@nvidia.com> |
regulator: core: add regulator_get_linear_step() Add regulator_get_linear_step(), which returns the voltage step size between VSEL values for linear regulators. This is intended for use by regulator consumers which build their own voltage-to-VSEL tables. Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com> Reviewed-by: Andrew Chew <achew@nvidia.com> Cc: Matthew Longnecker <mlongnecker@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
ce0d10f8 |
|
21-May-2013 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Correct spelling mistake in comment Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
31d6eebf |
|
02-May-2013 |
Robert P. J. Day <rpjday@crashcourse.ca> |
regulator: Fix kernel-doc generation warnings. Add a couple kernel-doc lines to get rid of kernel-doc generation warnings, no functional change. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
fcf371ee |
|
17-Apr-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Add regulator_map_voltage_ascend() API A lot of regulator hardware has ascendant voltage list. This patch adds regulator_map_voltage_ascend() and export it. Drivers that have ascendant voltage list can use this as their map_voltage() operation, this is more efficient than default regulator_map_voltage_iterate() function. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
1e4b545c |
|
16-Apr-2013 |
Nishanth Menon <nm@ti.com> |
regulator: core: return err value for regulator_get if there is no DT binding commit 6d191a5fc7a969d972f1681e1c23781aecb06a61 (regulator: core: Don't defer probe if there's no DT binding for a supply) Attempted to differentiate between regulator_get() with an actual DT binding for the supply and when there is none to avoid unnecessary deferal. However, ret value supplied by regulator_dev_lookup() is being ignored by regulator_get(). So, exit with the appropriate return value. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
0f7b87f0 |
|
04-Apr-2013 |
Andrew Bresticker <abrestic@chromium.org> |
regulator: core: don't require a supply when supply_name is specified Regulator drivers may specify regulator_desc->supply_name which regulator_register() will use to find the supply node for a regulator. If no supply was specified in the device tree or the supply has yet to be registered regulator_register() will fail, deferring the probe of the regulator. In the case where no supply node was specified in the device tree, there is no supply and it is pointless to try and find one later, so go ahead and add the regulator without the supply. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
167d41dc |
|
23-Mar-2013 |
Maxime Ripard <mripard@kernel.org> |
regulator: Fix typo in of_get_regulator function comments Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
51dcdafc |
|
04-Mar-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Add enable_is_inverted flag to indicate set enable_mask bits to disable Add enable_is_inverted flag to indicate set enable_mask bits to disable when using regulator_enable_regmap and friends APIs. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
7b74d149 |
|
17-Feb-2013 |
Kim, Milo <Milo.Kim@ti.com> |
regulator: core: use regulator_ena_pin member The regulator_dev has regulator_enable_gpio structure. 'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio. regulator_dev ---> regulator_enable_gpio .ena_gpio .gpio .ena_gpio_invert .ena_gpio_invert Pointer, 'ena_pin' is used for checking valid enable GPIO pin. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
967cfb18 |
|
17-Feb-2013 |
Kim, Milo <Milo.Kim@ti.com> |
regulator: core: manage enable GPIO list To support shared enable GPIO pin, replace GPIO code with new static functions Reference count: 'enable_count' Balance the reference count of each GPIO and actual pin control. The count is incremented with enabling GPIO. On the other hand, it is decremented on disabling GPIO. Actual GPIO pin is enabled at the initial use.(enable_count = 0) The pin is disabled if it is not used(shared) any more. (enable_count <=1) Regardless of the enable count, update GPIO state of the regulator. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
f19b00da |
|
17-Feb-2013 |
Kim, Milo <Milo.Kim@ti.com> |
regulator: core: support shared enable GPIO concept A Regulator can be enabled by external GPIO pin. This is configurable in the regulator_config. At this moment, the GPIO can be owned by only one regulator device. In some devices, multiple regulators are enabled by shared one GPIO pin. This patch extends this limitation, enabling shared enable GPIO of regulators. New list for enable GPIO: 'regulator_ena_gpio_list' This manages enable GPIO list. New structure for supporting shared enable GPIO: 'regulator_enable_gpio' The enable count is used for balancing GPIO control count. This count is incremented when GPIO is enabled. On the other hand, it's decremented when GPIO is disabled. Reference count: 'request_count' The reference count, 'request_count' is incremented/decremented on requesting/freeing the GPIO. This count makes sure only free the GPIO when it has no users. How it works If the GPIO is already used, skip requesting new GPIO usage. The GPIO is new one, request GPIO function and add it to the list of enable GPIO. This list is used for balancing enable GPIO count and pin control. Updating a GPIO and invert code moved 'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to new function, regulator_ena_gpio_request(). Use regulator_enable_pin structure rather than regulator_dev. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
fbe31057 |
|
28-Feb-2013 |
Andrzej Hajda <a.hajda@samsung.com> |
regulator: fixed regulator_bulk_enable unwinding code Unwinding code disables all successfully enabled regulators. Error is logged for every failed regulator. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
9345dfb8 |
|
28-Feb-2013 |
Nishanth Menon <nm@ti.com> |
regulator: core: fix documentation error in regulator_allow_bypass commit f59c8f9f (regulator: core: Support bypass mode) has a short documentation error around the regulator_allow_bypass parameter 'enable' which is documented as 'allow'. This generates kernel-doc warning as follows: ./scripts/kernel-doc drivers/regulator/core.c >/dev/null Warning(drivers/regulator/core.c:2841): No description found for parameter 'enable' Warning(drivers/regulator/core.c:2841): Excess function parameter 'allow' description in 'regulator_allow_bypass' Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
9c7b4e8a |
|
14-Feb-2013 |
Russ Dill <Russ.Dill@ti.com> |
regulator: Fix memory garbage dev_err printout. commit dd8004af: 'regulator: core: Log when a device causes a voltage constraint fail', tried to print out some information about the check consumer min/max uV fixup, however, it uses a garbage pointer left over from list_for_each_entry leading to boot messages in the form: '[ 2.079890] <RANDOM ASCII>: Restricting voltage, 3735899821-4294967295uV' Because it references regulator->dev, it could potentially read memory from anywhere causing a panic. This patch instead uses rdev and the updated min/max uV values. Signed-off-by: Russ Dill <Russ.Dill@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
c66a566a |
|
05-Feb-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Optimize _regulator_do_set_voltage if voltage does not change Optimize _regulator_do_set_voltage() for the case selector is equal to old_selector. Since the voltage does not change, we don't need to call set_voltage_sel() and set_voltage_time_sel() in this case. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
896b65f3 |
|
01-Feb-2013 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
regulator: show state for GPIO-controlled regulators Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
0384618a |
|
03-Jan-2013 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Fix comment for regulator_register() regulator_register() does not return 0 on success, fix the comment. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
c8520b4c |
|
17-Dec-2012 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Allow specify apply_[reg|bit] for regmap based voltage_sel operations Some DVM regulators needs to update apply_bit after setting vsel_reg to initiate voltage change on the output. This patch adds apply_reg and apply_bit to struct regulator_desc and update regulator_set_voltage_sel_regmap() to set apply_bit of apply_reg when apply_bit is set. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
19280e40 |
|
11-Dec-2012 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Fix continuous_voltage_range case in regulator_can_change_voltage Regulator drivers with continuous_voltage_range flag set allows not setting n_voltages. Thus if continuous_voltage_range is set, check the constraint range instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
92d7a558 |
|
13-Dec-2012 |
Paolo Pisati <paolo.pisati@canonical.com> |
regulator: core: if voltage scaling fails, restore original voltage values Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Tested-by: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
8a23b4e0 |
|
11-Dec-2012 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Fix logic to determinate if regulator can change voltage Having a linear_min_sel setting means the first linear_min_sel selectors are invalid. We need to subtract linear_min_sel when use n_voltages to determinate if regulator can change voltage. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
d1e7de30 |
|
04-Dec-2012 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulators: add regulator_can_change_voltage() function Introduce a regulator_can_change_voltage() function for the subsytems or drivers which might check if applying voltage change is possible and use special workaround code when the driver is used with fixed regulators or regulators with disabled ability to change the voltage. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
fff15bef |
|
27-Nov-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Say what unsupportable voltage constraints are Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
dd8004af |
|
28-Nov-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Log when a device causes a voltage constraint fail Helps with figuring out when things went wrong. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
33234e79 |
|
26-Nov-2012 |
Axel Lin <axel.lin@ingics.com> |
regulator: core: Allow specific minimal selector for starting linear mapping Some drivers (at least 3 drivers) have such variant of linear mapping that the first few selectors are invalid and the reset are linear mapping. Let's support this case in core. This patch adds linear_min_sel in struct regulator_desc, so we can allow specific minimal selector for starting linear mapping. Then extends regulator_[map|list]_voltage_linear() to support this feature. Note that for selectors less than min_linear_index, we need count them to n_voltages so regulator_list_voltage() won't fail while checking the boundary for selector before calling list_voltage callback. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
f0f98b19 |
|
13-Nov-2012 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulator: fix voltage check in regulator_is_supported_voltage() regulator_is_supported_voltage() should return true only if the voltage of fixed/constant regulator is between min_uV and max_uV. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org
|
#
23ff2f0f |
|
14-Nov-2012 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Avoid deadlock when regulator_register fails When regulator_register fails and exits through the scrub path the regulator_put function was called whilst holding the regulator_list_mutex, causing deadlock. This patch adds a private version of the regulator_put function which can be safely called whilst holding the mutex, replacing the aforementioned call. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
b2da55d9 |
|
28-Oct-2012 |
Andrew Lunn <andrew@lunn.ch> |
Regulator: core: Unregister when gpio request fails. If the gpio_request_one() fails, or returns EPROBE_DEFER, the regulator must be device_unregister()ed. When this is not done, there are WARNING: from sysfs: WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x238/0x268() Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
bd7a2b60 |
|
24-Sep-2012 |
Pawel Moll <pawel.moll@arm.com> |
regulator: core: Support for continuous voltage range Some regulators can set any voltage within the constraints range, not being limited to specified operating points. This patch makes it possible to describe such regulator and makes the regulator_is_supported_voltage() function behave correctly. Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
df367931 |
|
27-Aug-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Provide regmap get/set bypass operations Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
f59c8f9f |
|
31-Aug-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Support bypass mode Many regulators support a bypass mode where they simply switch their input supply to the output. This is mainly used in low power retention states where power consumption is extremely low so higher voltage or less clean supplies can be used. Support this by providing ops for the drivers and a consumer API which allows the device to be put into bypass mode if all consumers enable it and the machine enables permission for this. This is not supported as a mode since the existing modes are rarely used due to fuzzy definition and mostly redundant with modern hardware which is able to respond promptly to load changes. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Graeme Gregory <gg@slimlogic.co.uk>
|
#
52b84dac |
|
07-Sep-2012 |
AnilKumar Ch <anilkumar@ti.com> |
regulator: core: Try using the parent device for the default regmap If the device doesn't have a regmap specified by the driver and we can't find one on the device itself try its parent, providing a useful defualt for many MFDs. [Rewrite commit message -- broonie] Signed-off-by: AnilKumar Ch <anilkumar@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
2b5a24a0 |
|
06-Sep-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Fast path non-deferred disables Users (especially framework code) may end up passing in a zero deferral time depending on runtime conditions or configuration. If they do then just call regulator_disable() directly to save scheduling. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
f2889e65 |
|
27-Aug-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Report microvolts in sysfs even with only list_voltage() If a regulator only supports a single voltage list_voltage() can be used to report what that voltage is so add this as one of the criteria for creating the microvolts file in sysfs. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
dedae957 |
|
18-Aug-2012 |
Randy Dunlap <rdunlap@infradead.org> |
regulator: fix kernel-doc warnings in drivers/regulator/core.c Fix regulator kernel-doc warnings: Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev' Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Liam Girdwood <lrg@ti.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
43829731 |
|
20-Aug-2012 |
Tejun Heo <tj@kernel.org> |
workqueue: deprecate flush[_delayed]_work_sync() flush[_delayed]_work_sync() are now spurious. Mark them deprecated and convert all users to flush[_delayed]_work(). If you're cc'd and wondering what's going on: Now all workqueues are non-reentrant and the regular flushes guarantee that the work item is not pending or running on any CPU on return, so there's no reason to use the sync flushes at all and they're going away. This patch doesn't make any functional difference. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Mattia Dongili <malattia@linux.it> Cc: Kent Yoder <key@linux.vnet.ibm.com> Cc: David Airlie <airlied@linux.ie> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Bryan Wu <bryan.wu@canonical.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alasdair Kergon <agk@redhat.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-wireless@vger.kernel.org Cc: Anton Vorontsov <cbou@mail.ru> Cc: Sangbeom Kim <sbkim73@samsung.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Petr Vandrovec <petr@vandrovec.name> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Avi Kivity <avi@redhat.com>
|
#
296c6566 |
|
18-Aug-2012 |
Randy Dunlap <rdunlap@infradead.org> |
regulator: fix kernel-doc warnings in drivers/regulator/core.c Fix regulator kernel-doc warnings: Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev' Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Liam Girdwood <lrg@ti.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
b2a1ef47 |
|
09-Aug-2012 |
Marek Szyprowski <m.szyprowski@samsung.com> |
regulator: core: request only valid gpio pins for regulator enable Commit 65f735082de3 ("regulator: core: Add core support for GPIO controlled enable lines") introduced enable gpio entry in regulator configuration structure. Some drivers use '-1' as a placeholder for marking that such gpio line is not available, because '0' is considered as a valid gpio number. This patch fixes initialization of such drivers (like MAX8952 on UniversalC210 board), when '-1' is provided as enable gpio pin in the regulator's platform data. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
f7df20ec |
|
09-Aug-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Use list_voltage() to read single voltage regulators If the regulator doesn't supply a way of reading back the voltage but does provide a list_voltage() operation then use that with a selector of zero to read the voltage. Regulators doing this means that we have the list operation there for consumers that want to configure themselves. Reported-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
215b8b05 |
|
07-Aug-2012 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
regulator: make the dummy regulator's print_constraint more helpful This prevents the output of just dummy: in the boot log. Now it says: regulator-dummy: no parameters which at least doesn't make it look like an accidental printk and also doesn't only use "dummy" which could mean anything. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
2f6c797f |
|
06-Aug-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Fix cast to pointer from integer of different size warning This is to address the following warning during compilation time: (Compile on x86_64) CC drivers/regulator/core.o drivers/regulator/core.c: In function '_regulator_do_set_voltage': drivers/regulator/core.c:2183:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] This patch adds a temporary variable to avoid double cast. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
57ad526a |
|
23-Jul-2012 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: core: increment open_count when regulator supply is set When registering the regulator and setting supply for the regulator then increment open_count to reflect correct number of users. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
2955b47d |
|
09-Jul-2012 |
Dan Williams <dan.j.williams@intel.com> |
[SCSI] async: introduce 'async_domain' type This is in preparation for teaching async_synchronize_full() to sync all pending async work, and not just on the async_running domain. This conversion is functionally equivalent, just embedding the existing list in a new async_domain type. The .registered attribute is used in a later patch to distinguish between domains that want to be flushed by async_synchronize_full() versus those that only expect async_synchronize_{full|cookie}_domain to be used for flushing. [jejb: add async.h to scsi_priv.h for struct async_domain] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: Eldad Zack <eldad@fogrefinery.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
#
1beaf762 |
|
12-Jul-2012 |
Krystian Garbaciak <krystian.garbaciak@diasemi.com> |
regulator: Add REGULATOR_STATUS_UNDEFINED. REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state doesn't really apply. Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
03ffcf3d |
|
12-Jul-2012 |
Krystian Garbaciak <krystian.garbaciak@diasemi.com> |
regulator: Fix a typo in regulator_mode_to_status() core function. Case REGULATOR_STATUS_STANDBY -> REGULATOR_MODE_STANDBY. Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
86f5fcfc |
|
06-Jul-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Mark all DT based boards as having full constraints Since DT doesn't provide an idiomatic mechanism for enabling full constraints and since it's much more natural with DT to provide them just assume that a DT enabled system has full constraints. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
e2c98eaf |
|
05-Jul-2012 |
Shawn Guo <shawn.guo@linaro.org> |
regulator: core: remove sysfs entry properly in regulator_put With changes introduced by commit 222cc7b (regulator: core: Allow multiple requests of a single supply mapping) on create_regulator, regulator_put needs a corresponding update on sysfs entry removing. Also regulator->dev still needs to get assigned in create_regulator, otherwise, sysfs_remove_link call in regulator_put will get bypassed. Reported-by: Fabio Estevam <festevam@gmail.com> Tested-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
65f73508 |
|
27-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Add core support for GPIO controlled enable lines It is very common for regulators to support having their enable signal controlled by a GPIO. Since there are a bunch of fiddly things to get right like handling the operations when the enable signal is tied to a rail and it's just replicated code add support for this to the core. Drivers should set ena_gpio in their config if they have a GPIO control, using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for the initial state) and ena_gpio_invert if the GPIO is active low. The core will then override any enable and disable operations the driver has and instead control the specified GPIO. This will in the future also allow us to further extend the core by identifying when several enable signals have been tied together and handling this properly. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
5c5659d0 |
|
27-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Factor out enable and disable operations some more Create new _regulator_do_enable() and _regulator_do_disable() operations which deal with the mechanics of performing the enable and disable, partly to cut down on the levels of indentation and partly to support some future work. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
79511ed3 |
|
27-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Allow fixed enable_time to be set in the regulator_desc Many regulators have a fixed specification for their enable time. Allow this to be set in the regulator_desc as a number to save them having to implement an explicit operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
e113d792 |
|
26-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Check that the selector from map_voltage() is valid Lots of regulator drivers have checks in their map_voltage() functions to verify that the result of the mapping is in the range originally specified. Factor these out in the core and provide a bit of extra defensiveness for other drivers by doing the check in the core. Since we're now doing a list_voltage() earlier move the current mapping back to a voltage out into the set_voltage() call to save redoing it. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
c5f3939b |
|
02-Jul-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Support fixed voltages in regulator_is_supported_voltage() Currently regulator_is_supported_voltage() works by enumerating the set of voltages which can be set by the regulator but the checks we're doing to impose constraints mean that if we can't vary the voltage we'll not report any voltages as supported even though the regulator is actually set at that voltage. We could fix the voltage listing but this would mean that list_voltage() could end up going to the hardware to get the current voltage which isn't expected (it's supposed to be very cheap) so instead special case things when we can't change the voltage and compare the requested range against the current voltage. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
d92d95b6 |
|
02-Jul-2012 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Fix recursive mutex lockdep warning A recursive lockdep warning occurs if you call regulator_set_optimum_mode() on a regulator with a supply because there is no nesting annotation for the rdev->mutex. To avoid this warning, get the supply's load before locking the regulator's mutex to avoid grabbing the same class of lock twice. ============================================= [ INFO: possible recursive locking detected ] 3.4.0 #3257 Tainted: G W --------------------------------------------- swapper/0/1 is trying to acquire lock: (&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38 but task is already holding lock: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rdev->mutex); lock(&rdev->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by swapper/0/1: #0: (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c #1: (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c #2: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224 stack backtrace: [<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080) [<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10) [<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8) [<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4) [<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38) [<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224) ... Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
bf2516cd |
|
27-Jun-2012 |
Fabio Estevam <fabio.estevam@freescale.com> |
regulator: core: Remove unused get_device_regulator commit 222cc7b1 (regulator: core: Allow multiple requests of a single supply mapping) removed the usage of get_device_regulator(). Remove the function definition too amd get rid of the following warning: drivers/regulator/core.c:112:26: warning: 'get_device_regulator' defined but not used [-Wunused-function] Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
222cc7b1 |
|
22-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Allow multiple requests of a single supply mapping Sometimes it may be useful to allow a device to request a supply multiple times, for example in order to allow framework management of some uses of the supply with some additional driver specific management or in order to allow multiple children of an MFD to work with the supply. Currently this is not possible due to the creation of Solve this by removing the requested_uA entry (we have no current users of this feature anyway) and ignoring errors creating the symlink to the consumer. We should do something nicer than this as this causes sysfs to spew enormous warnings but it allows users to run for now. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
5aff3a8b |
|
26-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Check for failed voltage sets before checking for delay There is no need to consider waiting for the voltage to ramp if we didn't manage to set it and looking at the return value is going to be cheaper than is_enabled(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
f11d08c3 |
|
18-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Use list_voltage() to get voltage in regulator_set_voltage_time_sel With this change, regulator_set_voltage_time_sel() can be more generic and not limited to linear and table based mapping now. One side-effect of this change is that list_voltage() must be implemented. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
b19dbf71 |
|
23-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Add export of regulator_set_voltage_time_sel() Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
230a5a1c |
|
15-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix double free in devm_regulator_put() Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
ea38d13f |
|
18-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Change the unit of ramp_delay from mV/uS to uV/uS This change makes it possible to set ramp_delay with 0.xxx mV/uS without truncation issue. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
398715ab |
|
17-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Support table based mapping in regulator_set_voltage_time_sel For table based mapping, we can calculate voltage difference by below equation: abs(rdev->desc->volt_table[new_selector] - rdev->desc->volt_table[old_selector]) Thus we can make regulator_set_voltage_time_sel work for table based mapping. regulator_set_voltage_time_sel() only supports linear or table based mapping. In case it is misused, also warn if neither linear nor table based mapping is used with regulator_set_voltage_time_sel(). Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
6f0b2c69 |
|
11-Jun-2012 |
Yadwinder Singh Brar <yadi.brar01@gmail.com> |
regulator: Add ramp_delay configuration to constraints For some hardwares ramp_delay for BUCKs is a configurable parameter which can be configured through DT or board file.This patch adds ramp_delay to regulator constraints and allow user to configure it for regulators which supports this feature, through DT or board file. It will provide two ways of setting the ramp_delay for a regulator: First, by setting it as constraints in board file(for configurable regulators) and set_machine_constraints() will take care of setting it on hardware by calling(the provided) .set_ramp_delay() operation(callback). Second, by setting it as data in regulator_desc(as fixed/default ramp_delay rate) for a regulator in driver. regulator_set_voltage_time_sel() will give preference to constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly users should also take care accordingly while refering ramp_delay rate(in case of implementing their private .set_voltage_time_sel() callbacks for different regulators). [Rewrote subject for 80 columns -- broonie] Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
8b96de31 |
|
14-Jun-2012 |
Philip Rakity <prakity@marvell.com> |
regulator: core.c Only delay when setting voltage requires this minor optimization: move delay code to where delay is set and thus where it is used vs in the main line path. Signed-off-by: Philip Rakity <prakity@marvell.com> Acked-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
2f7baf89 |
|
15-Jun-2012 |
Philip Rakity <prakity@marvell.com> |
regulator: core.c Pass voltage to notifier when setting voltage The voltage being set should be passed to the call in handler requesting the callback. Currently this is not done. The calling handler cannot call regulator_get_voltage() to get the information since the mutex is held by the regulator and deadlock occurs. Without this change the receiver of the call in cannot know what action to take. This is used, for example, to set PAD voltages when doing SD vccq voltage changes. [Review and spelling fix in the commit log from Pankaj Jangra] Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
d8493d21 |
|
15-Jun-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Actually use the data in _notifier_call_chain() Reported-by: Pankaj Jangra <jangra.pankaj9@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
578df8ba |
|
10-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Return correct delay time in regulator_set_voltage_time_sel rdev->desc->uV_step * abs(new_selector - old_selector) returns uV. The unit of ramp_delay is mV/us. Current code multiples 1000 at wrong place. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
98a175b6 |
|
09-Jun-2012 |
Yadwinder Singh Brar <yadi.brar01@gmail.com> |
regulator: core: Add regulator_set_voltage_time_sel to calculate ramp delay. This patch adds regulator_set_voltage_time_sel(), to move into core, the commonly used code by drivers to provide the .set_voltage_time_sel callback. It will also allow us to configure different ramp delay for different regulators easily. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
5a6881e8 |
|
06-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Handle fixed voltage in map_voltage_linear Fixed voltage is a kind of linear mapping where n_voltages is 1. This change allows [list|map]_voltage_linear to be used for fixed voltage. For fixed voltage, n_voltages is 1 and the only valid selector is 0. Thus we actually don't care the uV_step setting. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
0bdc81e4 |
|
06-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Properly handle the case min_uV < rdev->desc->min_uV in map_voltage_linear Properly handle the case if the specified min_uV is less than the voltage given by the lowest selector. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
9152c36a |
|
03-Jun-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Use map_voltage_linear() if list_voltage_linear() is in use and nothing is set Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
3a4b0a07 |
|
08-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Use dev_get_regmap() to find the regmap If no regmap is explicitly specified then use dev_get_regmap() to obtain one. The driver must explicitly enable any actual usage of the regmap so there's no concern with unwanted usage. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
361ff501 |
|
07-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Use newly added devres_release() rather than open coding devres_release() will call the destructor for the resource as well as freeing the devres data. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
8b7485ef |
|
20-May-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Call set_voltage_time_sel() only when the regulator is on If the regulator is not on, it won't take time setting new voltage. So only call set_voltage_time_sel() to get the necessary delay when the regulator is on. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
cffc9592 |
|
19-May-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Allow drivers to set voltage mapping table in regulator_desc Some regulator hardware use table based mapping can set volt_table in regulator_desc and use regulator_list_voltage_table() for their list_voltage callback. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
b1a86831 |
|
13-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Don't open code _regulator_is_enabled() Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
e81dba85 |
|
13-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Release regulator-regulator supplies on error If we fail while registering a regulator make sure we release the supply for the regulator if there is one. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Cc: stable@vger.kernel.org
|
#
ccfcb1c3 |
|
13-May-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Ensure simple linear voltage mappings falls within the specified range Integer division may truncate the result. Use DIV_ROUND_UP to ensure simple linear voltage mappings falls within the specified range. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
bca7bbff |
|
09-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Allow drivers to set simple linear voltage maps as data A lot of regulator hardware maps selectors on to voltages with a simple linear mapping function selector = base + (selector * step size) Provide off the shelf list_voltage() and map_voltage() operations which use new min_uV and uV_step members in the regulator_desc to implement this function. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
e843fc46 |
|
09-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Allow regulators to provide a voltage to selector mapping In order to allow more drivers to factor things out into data allow drivers to provide a mapping function to convert voltages into selectors. This allows any driver to use set_voltage_sel(). The existing mapping based on iterating over list_voltage() is provided as an operation which can be assigned to the new map_voltage() function though for ease of transition it is treated as the default. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
dcf70112 |
|
08-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Warn on missing struct device The core really wants a struct device to be supplied for regulators and there's no reason this should be impossible so provide one so complain if we didn't get one. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
968c2c17 |
|
07-May-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Actually free the regulator in devm_regulator_put() It turns out that (quite surprisingly) devres_destroy() only undoes the devres mapping, it doesn't destroy the underlying resource, meaning that anything using devm_regulator_put() would leak. While we wait for the new devres_release() which does what we want to get merged open code it in devm_regulator_put(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
6492bc1b |
|
19-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Optimise enable/disable path for always on regulators If a regulator is always on for any reason then cache that when the consumer is created and use it to optimise away the need to take locks or recurse up the supply tree when consumers do enable or disable calls. The scheduling of asynchronous work for bulk enables is also skipped. We don't actually check if the device physically supports control on the basis that constraints allowing status changes on physically always on regulators are nonsensical anyway. This is a very common pattern in hardware - it's normal to have some power supplies that have either no software control or are critical to system function - so many systems should be able to benefit. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
854ccbae |
|
16-Apr-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Add checking set_mode callback in regulator_set_optimum_mode regulator_set_optimum_mode needs set_mode to properly work. Add checking for set_mode callback in case it may be not implemented. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
cd6dffb4 |
|
14-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Provide standard enable operations for regmap users Since the enable(), disable() and is_enabled() operations for most regmap based regulators come down to reading and updating a single register bit we can factor out the code and allow these drivers to just define which bit to update using the enable_reg and enable_mask fields in their desc and then use operations provided by the core. As well as the code saving this opens the door to future optimisation of the bulk operations - if the core can realise that we are updating a single register for multiple regulators then it should be able to combine these updates into a single physical operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
4ab5b3d9 |
|
15-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Provide regmap based voltage_sel operations Since the voltage selector operations are intended to directly map a bitfield in the device register map into regulator API operations the code for implementing them is usually very standard we can save some code by providing standard implementations for devices using the regmap API. Drivers using regmap can pass their regmap in in the regmap_config struct, set vsel_reg and vsel_mask in their regulator_desc and then use regulator_{get,set}_voltage_sel_regmap in their ops. This saves a small amount of code from each driver. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
65b19ce6 |
|
15-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Allow drivers to pass in a regmap Since many regulators use regmap for register I/O and since there's quite a few very common patterns in the code allow drivers to pass in a regmap to the core for use in generic code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
8ac0e95d |
|
13-Apr-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Support setting suspend_[mode|voltage] if set_suspend_[en|dis]able is NULL In current implementation, to support set_suspend_voltage and set_suspend_mode the regulator code needs the regulator driver to implement both set_suspend_enable and set_suspend_disable callbacks. This patch removes this limitation. In the case set_suspend_enable and/or set_suspend_disable are NULL, the regulator code assumes we don't need to do any thing to enable/disable regulator when system is suspended and then will continue to handle set_suspend_mode and set_suspend_voltage. Currently the regulator core creates suspend state related sysfs entries only if both set_suspend_enable and set_suspend_disable callbacks are not NULL. A side-effect of this change is that the regulator core will create suspend state related sysfs entries unconditionally now. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
3f24f5ad |
|
13-Apr-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: core: Fix getting input_uV when supplied by another regulator When supplied by another regulator, returns the supply regulator's output voltage for inpu_uV. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
32c8fad4 |
|
11-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Appease smatch in regulator_register() We don't support missing configs at all so segfaulting isn't that bad but since we've got checks in the code move the dereference after them. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
c172708d |
|
03-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Use a struct to pass in regulator runtime configuration Rather than adding new arguments to regulator_register() every time we want to add a new bit of dynamic information at runtime change the function to take these via a struct. By doing this we avoid needing to do further changes like the recent addition of device tree support which required each regulator driver to be updated to take an additional parameter. The regulator_desc which should (mostly) be static data is still passed separately as most drivers are able to configure this statically at build time. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
eba41a5e |
|
03-Apr-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Support set_voltage_time_sel for drivers implement set_voltage In currently implementation of _regulator_do_set_voltage, set_voltage_time_sel will only be called if set_voltage_sel is implemented. set_voltage_time_sel actually only needs get_voltage_sel to get old_selector. This patch makes regulator core support set_voltage_time_sel for drivers implement either set_voltage or set_voltage_sel. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
65f26846 |
|
03-Apr-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Constify the regulator_desc passed in when registering Drivers should be able to declare their descriptors const and the framework shouldn't ever be modifying the desciptor. Make the parameter and the pointer in regulator_dev const to enforce this. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
576ca436 |
|
29-Mar-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Pull non-DT supply mapping into regulator_dev_lookup() Ensure we always apply the supply mapping when doing a lookup rather than only doing it in non-DT cases, ensuring that regulators with supplies specified in the regulator_desc can find their supplies on non-DT systems and generally making the code more obvious. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
6d191a5f |
|
29-Mar-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Don't defer probe if there's no DT binding for a supply When using device tree if there's no binding for a supply then there's no way that one could appear later so just fail permanently right away. This avoids wasting time trying to reprobe when that can never work. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
01e86f49 |
|
28-Mar-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: core: Complain if we can't reenable a supply When cleaning up after a failed bulk_disable() we try to reenable any supplies that we did manage to disable - complain if we fail to do that when we try. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
e032b376 |
|
28-Mar-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix deadlock on removal of regulators with supplies If a regulator with a supply is being unregistered we will call regulator_put() to release the supply with the regulator_list_mutex held but this deadlocks as regulator_put() takes the same lock. Fix this by releasing the supply before we take the mutex in regulator_unregister(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
16fbcc3b |
|
16-Mar-2012 |
Rajendra Nayak <rnayak@ti.com> |
regulator: Fix up a confusing dev_warn when DT lookup fails of_parse_phandle() returns NULL either if the property name itself does not exist or if it (exists and) does not reference a valid phandle. Giving out a warn like the one below (that the property references an invalid phandle) can be confusing when the property itself does not exist in the node. Fix it with a more sensible message and make it a dev_dbg instead of a dev_warn. Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
04bf3011 |
|
11-Mar-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Support driver probe deferral If we fail to locate a requested regulator return -EPROBE_DEFER. If drivers pass this error code through to their caller (which they really should) then this will ensure that the probe is retried later when further devices become available. In the unusual case where a driver doesn't want this it can override the default behaviour. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
07351233 |
|
24-Feb-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Set delay to 0 if set_voltage_time_sel callback returns error rdev->desc->ops->set_voltage_time_sel may return negative error code. Set delay to 0 and also show warning if set_voltage_time_sel returns error. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
24751434 |
|
20-Feb-2012 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Remove ifdefs for debugfs code If CONFIG_DEBUG_FS=y debugfs functions will never return an ERR_PTR. Instead they'll return NULL. The intent is to remove ifdefs in calling code. Update the code to reflect this. We gain an extra dentry pointer per struct regulator and struct regulator_dev but that should be ok because most distros have debugfs compiled in anyway. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
f4d562c6 |
|
20-Feb-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Clean up debugfs error handling a bit Use IS_ERR_OR_NULL() rather than open coding it and ignore errors from failure to create the supply map. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
b29c7690 |
|
19-Feb-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Simplify regulator_bulk_get and regulator_bulk_enable error paths Start unwind from the point the error happens instead of iterating over all consumers, then unwind code can be simpler. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
5bc78015 |
|
18-Feb-2012 |
Axel Lin <axel.lin@gmail.com> |
regulator: Remove obsolete consumer_dev related comment consumer_dev is remove by commit 737f36 "regulator: Remove support for supplies specified by struct device". Thus remove the obsolete comment. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
4a682922 |
|
09-Feb-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Complain if a voltage range is specified but can't be used It doesn't make much sense to specify a range of voltages consumers can use if they haven't been given permission to change the voltage. Log if this happens, probably the user forgot to specify CHANGE_VOLTAGE. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
43f674a3 |
|
09-Feb-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Don't add the function name to pr_fmt Liam pointed out via IM that since we now use the pure function name for all regulator logging a lot of the messages such as those logging the constraints are getting a bit noisy due to the implementation detail that is the function name: print_constraints: VDDARM: 1000 <--> 1300 mV at 1300 mV at 0 mA In discussion it seemed like the best thing was to just drop the pr_fmt and clarify individual log messages where there is an issue otherwise we get into silly things like renaming the functions to suit the logging. This is mostly an issue as we have a moderate amount of non-error logging in the boot sequence to aid debug if something goes wrong since regulator misconfiguration can kill the system pretty quickly. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
737f360d |
|
01-Feb-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Remove support for supplies specified by struct device This has been deprecated for a very long time now. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
49e22632 |
|
24-Jan-2012 |
Sylwester Nawrocki <s.nawrocki@samsung.com> |
regulator: Reverse the disable sequence in regulator_bulk_disable() Often there is a need for disabling a set of regulators in order opposite to the enable order. Currently the function regulator_bulk_disable() walks list of regulators in same order as regulator_bulk_enable(). This may cause trouble, especially for devices with mixed analogue and digital circuits. So reverse the disabling sequence of regulator_bulk_disable(). While at it, also correct the comment. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
4a7cbb56 |
|
24-Jan-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix documentation for of_node parameter of regulator_register() Commit 5bc75a886353 ("kernel-doc: fix new warning in regulator core") added documentation for of_node to address a warning but the documentation didn't explain what the parameter is for so would be likely to be unhelpful for users. Clarify that. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
5bc75a88 |
|
21-Jan-2012 |
Randy Dunlap <rdunlap@infradead.org> |
kernel-doc: fix new warning in regulator core Fix new kernel-doc warning: Warning(drivers/regulator/core.c:2741): No description found for parameter 'of_node' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Liam Girdwood <lrg@ti.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e6e74030 |
|
20-Jan-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Provide devm_regulator_bulk_get() Allow drivers to benefit from both the bulk APIs and managed resources simultaneously. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
d5ad34f7 |
|
20-Jan-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Implement devm_regulator_free() Allow consumers to free regulators allocated using devm_regulator_get() if they need to. This will not normally be required. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
070b9079 |
|
16-Jan-2012 |
Stephen Boyd <sboyd@codeaurora.org> |
regulator: Add devm_regulator_get() Add a resource managed regulator_get() to simplify regulator usage in drivers. This allows driver authors to "get and forget" about their regulators by automatically calling regulator_put() when the driver is detached. [Fixed up a couple of coding style issues -- broonie] Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
e1de2f42 |
|
03-Jan-2012 |
Donggeun Kim <dg77.kim@samsung.com> |
regulator: add regulator_bulk_force_disable function This patch allows consumers to forcibly disable multiple regulator clients in a single API call. Signed-off-by: Donggeun Kim <dg77.kim@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
b2296bd4 |
|
02-Jan-2012 |
Laxman Dewangan <ldewangan@nvidia.com> |
regulator: Enable supply regulator if child rail is enabled. During regulator_register, the rail is set on the provided machine constraints and if it is enabled then it is also require to enable the supply regulator. This will make sure that: 1. Proper reference count for supply regulator to be maintain. 2. Supply regulator should be enable when given rail is enabled. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
32c78de8 |
|
29-Dec-2011 |
Axel Lin <axel.lin@gmail.com> |
regulator: Fix checking return value of create_regulator create_regulator() returns NULL on fail. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
bcda4321 |
|
29-Dec-2011 |
Axel Lin <axel.lin@gmail.com> |
regulator: Fix the error handling if create_regulator fails In the case of create_regulator() fails, goto the error path immediately. It does not make sense to update rdev->open_count if create_regulator fails. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
a398eaa2 |
|
27-Dec-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Export regulator_is_supported_voltage() It's part of the driver interface so should be available to modules. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
9a8f5e07 |
|
29-Nov-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow regulators to register with no init_data This allows read-only access to the device configuration which may be useful for diagnostics. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
58fb5cf5 |
|
28-Nov-2011 |
Lothar Waßmann <LW@KARO-electronics.de> |
regulator: fix use after free bug This is caused by dereferencing 'rdev' after device_unregister() in the regulator_unregister() function. 'rdev' is freed by device_unregister(), so it must not be dereferenced after this call. [Edited commit message for legibility -- broonie] Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
69511a45 |
|
18-Nov-2011 |
Rajendra Nayak <rnayak@ti.com> |
regulator: map consumer regulator based on device tree Device nodes in DT can associate themselves with one or more regulators/supply by providing a list of phandles (to regulator nodes) and corresponding supply names. For Example: devicenode: node@0x0 { ... ... vmmc-supply = <®ulator1>; vpll-supply = <®ulator2>; }; The driver would then do a regulator_get(dev, "vmmc"); to get regulator1 and do a regulator_get(dev, "vpll"); to get regulator2. of_get_regulator() extracts the regulator node for a given device, based on the supply name. Use it to look up the regulator for a given consumer from device tree, during a regulator_get(). If not found fallback and lookup through the regulator_map_list instead. Also, since the regulator dt nodes can use the same binding to associate with a parent regulator/supply, allow the drivers to specify a supply_name, which can then be used to lookup dt to find the parent phandle. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
2c043bcb |
|
18-Nov-2011 |
Rajendra Nayak <rnayak@ti.com> |
regulator: pass additional of_node to regulator_register() With device tree support for regulators, its needed that the regulator_dev->dev device has the right of_node attached. To be able to do this add an additional parameter to the regulator_register() api, wherein the dt-adapted driver can then pass this additional info onto the regulator core. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
4c78899b |
|
02-Nov-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Don't create voltage sysfs entries if we can't read voltage Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
65602c32 |
|
17-Jul-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
regulator: Add module.h to drivers/regulator users as required Another group of drivers that are taking advantage of the implicit presence of module.h -- and will break when we pull the carpet out from under them during a cleanup. Fix 'em now. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
d1685e4e |
|
14-Oct-2011 |
Heiko Stübner <heiko@sntech.de> |
regulator: Fix possible nullpointer dereference in regulator_enable() In the case where _regulator_enable returns an error it was not checked if a supplying regulator exists before trying to disable it, leading to a null pointer-dereference if no supplying regulator existed. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
aa59802d |
|
03-Oct-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix return code from regulator_disable_deferred() schedule_delayed_work() returns a bool indicating if the work was already queued when it succeeds so we need to squash a true down to zero. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
da07ecd9 |
|
11-Sep-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Implement deferred disable support It is a reasonably common pattern for hardware to require some delay after being quiesced before the disable has finalised, especially in mixed signal devices. For example, an active discharge may be required to ensure that the circuit starts up again in a known state. Avoid having to implement such delays in the regulator API by providing regulator_deferred_disable() which will do a regulator_disable() a specified number of milliseconds after it is called. Due to the reference counting done on regulators a deferred disable can be cancelled by doing another regulator_enable(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
|
#
ba55a974 |
|
23-Aug-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add debugfs file showing the supply map table Useful for working out why things aren't getting plugged together properly. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
54abd335 |
|
21-Jul-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix argument format type errors in error prints We need to dereference the pointers to print their values. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1a6958e7 |
|
14-Jul-2011 |
Axel Lin <axel.lin@gmail.com> |
regulator: Fix memory leak in set_machine_constraints() error paths Properly kfree rdev->constraints in all set_machine_constraints() error paths. Also properly kfree rdev->constraints in regulator_register() error paths. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
89f425ed |
|
11-Jul-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Make core more chatty about some errors Prevent some head scratching by making the core log about some rare but possible errors with invalid voltage ranges and modes being set. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
5de70519 |
|
19-Jun-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add basic per consumer debugfs Report the requested load and voltage for each consumer in debugfs when it is enabled. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
7d51a0db |
|
09-Jun-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add rdev_crit() macro No actual users but provide the macro so there's less surprise when it's not there. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
3801b86a |
|
09-Jun-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Refactor supply implementation to work as regular consumers Currently the regulator supply implementation is somewhat complex and fragile as it doesn't look like standard consumers but is instead a parallel implementation. This causes issues with locking and reference counting. Move the implementation over to using standard consumers to address this. Rather than only notifying the supply on the first enable/disable we do so every time the regulator is enabled or disabled, simplifying locking as we don't need to hold a lock on the consumer we are about to enable. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e0eaedef |
|
09-Jun-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Include the device name in the microamps_requested_ file We may have multiple devices requesting a supply with the same name so include the device name in the generated filename for microamps_requested to avoid duplicate files. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
f5726ae3 |
|
09-Jun-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Increase the limit on sysfs file names With verbose filenames we can easily hit 32 characters. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
f21e0e81 |
|
23-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Do bulk enables of regulators in parallel In order to reduce the impact of ramp times rather than enabling the regulators for a device in series use async tasks to run the actual enables. This means that the delays which the enables implement can all run in parallel, though it does mean that the order in which the supplies come on may be unstable. For super bonus fun points if any of the regulators are shared between multiple supplies on the same device (as is rather likely) then this will test our locking. Note that in this case we only delay once for each physical regulator so the threads shouldn't block each other while delaying. It'd be even nicer if we could coalesce writes to a shared enable registers in PMICs but that's definitely future work, and it may also be useful and is certainly more achievable to optimise out the parallelism if none of the regulators implement ramp delays. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
cb220d16 |
|
23-May-2011 |
Axel Lin <axel.lin@gmail.com> |
regulator: Fix _regulator_get_voltage if get_voltage callback is NULL In the case of get_voltage callback is NULL, current implementation in _regulator_get_voltage will return -EINVAL. Also returns proper error if ret is negative value. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
4aa922c0 |
|
14-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Only apply voltage constraints from consumers that set them When applying the set_voltage() requests from consumers skip over those consumers that haven't set anything, otherwise we'll come out with a maximum voltage of zero. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
a4b41483 |
|
14-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: If we can't configure optimum mode we're always in the best one If either a regulator driver can't tell us what the optimum mode is (or doesn't have modes in the first place) or the system doesn't allow DRMS changes then it's more helpful for users to just say that we're in the optimal mode, even if it's from a selection of one. Still report errors if the process of picking and setting a mode changes as this may indicate that we're stuck in a low power mode and unable to deliver a higher current that the consumer just asked for. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
bf5892a8 |
|
08-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Support voltage offsets to compensate for drops in system Some systems, particularly physically large systems used for early prototyping, may experience substantial voltage drops between the regulator and the consumers as a result of long traces in the system. With these systems voltages may need to be set higher than requested in order to ensure reliable system operation. Allow systems to work around such hardware issues by allowing constraints to supply an offset to be applied to any requested and reported voltages. This is not ideal, especially since the voltage drop may be load dependant, but is sufficient for most affected systems, it is not expected to be used in production hardware. The offset is applied after all constraint processing so constraints should be specified in terms of consumer values not physically configured values. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
492c826b |
|
08-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Remove supply_regulator_dev from machine configuration supply_regulator_dev (using a struct pointer) has been deprecated in favour of supply_regulator (using a regulator name) for quite a few releases now with a warning generated if it is used and there are no current in tree users so just remove the code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
82d15839 |
|
09-May-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Factor out references to rdev in regulator_force_disable() Don't go looking up the rdev pointer every time, just use a local variable like everything else. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
22c51b47 |
|
01-Apr-2011 |
Axel Lin <axel.lin@gmail.com> |
regulator: Fix the argument of calling regulator_mode_constrain The second parameter of regulator_mode_constrain takes a pointer. This patch fixes below warning: drivers/regulator/core.c: In function 'regulator_set_mode': drivers/regulator/core.c:2014: warning: passing argument 2 of 'regulator_mode_constrain' makes pointer from integer without a cast drivers/regulator/core.c:200: note: expected 'int *' but argument is of type 'unsigned int' Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@vega.(none)>
|
#
2c608234 |
|
29-Mar-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: When constraining modes fall back to higher power modes If a mode requested by a consumer is not allowed by constraints automatically fall back to a higher power mode if possible. This ensures that consumers get at least the output they requested while allowing machine drivers to transparently limit lower power modes if required. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
25985edc |
|
30-Mar-2011 |
Lucas De Marchi <lucas.demarchi@profusion.mobi> |
Fix common misspellings Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
#
88cd222b |
|
17-Mar-2011 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: provide consumer interface for fall/rise time This exposes the functionality for rise/fall fime when setting voltage to the consumers. Cc: Bengt Jonsson <bengt.g.jonsson@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
77af1b26 |
|
17-Mar-2011 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: add set_voltage_time_sel infrastructure This makes it possible to set the stabilization time for voltage regulators in the same manner as enable_time(). The interface only supports regulators that implements fixed selectors. Cc: Bengt Jonsson <bengt.g.jonsson@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
7a32b589 |
|
10-Mar-2011 |
MyungJoo Ham <myungjoo.ham@samsung.com> |
Regulator: add suspend-finish API for regulator core. The regulator core had suspend-prepare that turns off the regulators when entering a system-wide suspend. However, it did not have suspend-finish that pairs with suspend-prepare and the regulator core has assumed that the regulator devices and their drivers support autonomous recover at resume. This patch adds regulator_suspend_finish that pairs with the previously-existed regulator_suspend_prepare. The function regulator_suspend_finish turns on the regulators that have always_on set or positive use_count so that we can reset the regulator states appropriately at resume. In regulator_suspend_finish, if has_full_constraints, it disables unnecessary regulators. Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> -- Updates v3 comments corrected (Thanks to Igor) v2 disable unnecessary regulators (Thanks to Mark) Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
23c2f041 |
|
24-Feb-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: If we fail when setting up a supply say which supply Makes it a bit easier to identify if it's a problem with the supplies, the usual error would be omitting the supply name entirely. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1130e5b3 |
|
21-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add initial per-regulator debugfs support We only expose the use and open counts to userspace, providing a tiny bit of insight into what the API is up to. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
21cf891a |
|
21-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Make regulator_has_full_constraints a bool It's a boolean value so use the type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
13ce29f8 |
|
17-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Clean up logging a bit The recent introduction of standard regulator API logging macros means that all our log messages have at least the function name in them and logging that the constraints are for the regulator API is probably a bit much. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
95a3c23a |
|
16-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Optimise out noop voltage changes If a consumer sets the same voltage range as is currently configured for that consumer there's no need to run through setting the voltage again. This pattern may occur with some CPUfreq implementations where the same voltage range is used for multiple frequencies. Reported-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
606a2562 |
|
16-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add API to re-apply voltage to hardware When cooperating with an external control source the regulator setup may be changed underneath the API. Currently consumers can just redo the regulator_set_voltage() to restore a previously set configuration but provide an explicit API for doing this as optimsations in the regulator_set_voltage() implementation will shortly prevent that. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
ded06a52 |
|
16-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Only notify voltage changes when they succeed Currently we notify a voltage change whenever we exit set_voltage(), even if the change failed for some reason (eg, a constraints issue). This shouldn't cause any substantial ill effects but is wasteful as listeners get notified on noops. Fix this by moving the notification into _do_set_voltage() and only notifying if we don't return an error. Reported-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e8eef82b |
|
12-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Provide a selector based set_voltage_sel() operation Many regulator drivers implement voltage setting by looping through a table of possible values, normally because the set of available voltages can't be mapped onto selectors with simple calcuation. Factor out these loops by providing a variant of set_voltage() which takes a selector rather than a voltage range as an argument and implementing a loop through the available selectors in the core. This is not going to be suitable for use with all devices as when the regulator voltage can be mapped onto selector values with a simple calculation the linear scan through the available values will be more expensive than just doing the calculation, especially for regulators that provide fine grained voltage control. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
75790251 |
|
12-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Factor out voltage set operation into a separate function Push all the callers of the chip set_voltage() operation out into a single function to facilitiate future refactoring. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
476c2d83 |
|
10-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow drivers to report voltages as selectors Since drivers already have to provide an API for translating selectors into voltages they may as well just report the selector values directly to the core API rather than implement the lookup themselves. The old interface is left in place for now, but may be removed in future. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1bf5a1f8 |
|
10-Dec-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Use _regulator_get_voltage() consistently Rather than referencing the get_voltage() operation directly in the ops struct use the internal _regulator_get_voltage() API call to do so, facilitating refactoring. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
43e7ee33 |
|
06-Dec-2010 |
Joe Perches <joe@perches.com> |
drivers/regulator: Update WARN uses Align arguments. Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
05fda3b1a |
|
03-Dec-2010 |
Thomas Petazzoni <t-petazzoni@ti.com> |
regulator: Take into account the requirements of all consumers Extend the regulator_set_voltage() function to take into account the voltage requirements of all consumers of the regulator being changed, in order to set the voltage to the minimum voltage acceptable to all consumers. The existing behaviour was that the latest regulator_set_voltage() call would win over previous regulator_set_voltage() calls even if setting the voltage to a non-acceptable level from other consumers. Signed-off-by: Thomas Petazzoni <t-petazzoni@ti.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
5da84fd9 |
|
30-Nov-2010 |
Joe Perches <joe@perches.com> |
regulator: Add and use rdev_<level> macros On Tue, 2010-11-30 at 10:52 +0000, Mark Brown wrote: > On Mon, Nov 29, 2010 at 05:12:56PM -0800, Joe Perches wrote: > > Just to please broonie... > > Signed-off-by: Joe Perches <joe@perches.com> > As usual when fixing review issues please revise your original patch > rather than posting a fresh patch. Here's an earlier comment: On Thu, 2010-11-18 at 13:30 +0000, Mark Brown wrote: > This looks reasonable, please rebase on top of Daniel's patches and > submit it properly (with changelog and so on). Sometimes it's simpler for an upstream maintainer to do something like: git am -s <patch1.mbox> patch -p1 < patch2.mbox git commit --amend file instead of back and forthing. Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
f8c12fe3 |
|
29-Nov-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Copy constraints from regulators when initialising them Currently the regulator API uses the constraints structure passed in to the core throughout the lifetime of the object. This means that it is not possible to mark the constraints as __initdata so if the kernel supports many boards the constraints for all of them are kept around throughout the lifetime of the system, consuming memory needlessly. By copying constraints that are actually used we allow the use of __initdata, saving memory when multiple boards are supported. This also means the constraints can be const. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
50ba5ca4 |
|
22-Nov-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Remove regulator core version announcement The version hasn't been updated since the regulator API was merged in 2.6.27 so just remove it - now we're in mainline the kernel version is much more useful. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
4c35508f |
|
22-Nov-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix obfuscated log messages Don't use %s to format fixed static strings into log messages, it just makes searching for and reading the message in the kernel source needlessly hard. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1d7372e1 |
|
17-Nov-2010 |
Daniel Walker <dwalker@codeaurora.org> |
drivers: regulator: core: convert to using pr_ macros The regulator framework uses a lot of printks with a specific formatting using __func__. This converts them to use pr_ calls with a central format string. Cc: bleong@codeaurora.org Signed-off-by: Daniel Walker <dwalker@codeaurora.org> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
c5e28ed7 |
|
17-Nov-2010 |
Daniel Walker <dwalker@codeaurora.org> |
drivers: regulator: core: use pr_fmt This adds a pr_fmt line which uses the __func__ macro. I also convert the current pr_ lines to remove their __func__ usage. Cc: bleong@codeaurora.org Signed-off-by: Daniel Walker <dwalker@codeaurora.org> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
acaf6ffe |
|
10-Nov-2010 |
Bengt Jonsson <bengt.g.jonsson@stericsson.com> |
regulator: enable supply regulator only when use count is zero Supply regulators are disabled only when the last reference count is removed on the child regulator (the use count goes from 1 to 0). This patch changes the behaviour of enable so the supply regulator is enabled only when the use count of the child regulator goes from 0 to 1. Signed-off-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com> Acked-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
02fa3ec0 |
|
10-Nov-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add basic trace facilities Provide some basic trace facilities to the regulator API. We generate events on regulator enable, disable and voltage setting over the actual hardware operations (which are assumed to be the expensive ones which require interaction with the actual device). This is intended to facilitate debug of the performance and behaviour with consumers allowing unified traces to be generated including the regulator operations within the context of the other components of the system. For enable we log the explicit delay for the voltage ramp separately to the interaction with the hardware to highlight the time consumed in I/O. We should add a similar delay for voltage changes, though there the relatively small magnitude of the changes in the context of the I/O costs makes it much less critical for most regulators. Only hardware interactions are currently traced as the primary focus is on the performance and synchronisation of actual hardware interactions. Additional tracepoints for debugging of the logical operations can be added later if required. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
3a93f2a9 |
|
10-Nov-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Report actual configured voltage to set_voltage() Change the interface used by set_voltage() to report the selected value to the regulator core in terms of a selector used by list_voltage(). This allows the regulator core to know the voltage that was chosen without having to do an explict get_voltage(), which would be much more expensive as it will generally access hardware. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
63cee946 |
|
04-Nov-2010 |
Mattias Wallin <mattias.wallin@stericsson.com> |
regulator: lock supply in regulator enable This patch add locks around regulator supply enable. Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
06c63f93 |
|
18-Nov-2010 |
Randy Dunlap <randy.dunlap@oracle.com> |
regulator: fix kernel-doc for set_consumer_device_supply Fix kernel-doc warning for set_consumer_device_supply(): Warning(drivers/regulator/core.c:912): missing initial short description on line: * set_consumer_device_supply: Bind a regulator to a symbolic supply Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
f3c18a87 |
|
10-Nov-2010 |
Bengt Jonsson <bengt.g.jonsson@stericsson.com> |
regulator: enable supply regulator only when use count is zero Supply regulators are disabled only when the last reference count is removed on the child regulator (the use count goes from 1 to 0). This patch changes the behaviour of enable so the supply regulator is enabled only when the use count of the child regulator goes from 0 to 1. Signed-off-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com> Acked-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
3aa713e7 |
|
04-Nov-2010 |
Mattias Wallin <mattias.wallin@stericsson.com> |
regulator: lock supply in regulator enable This patch add locks around regulator supply enable. Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
7727da22 |
|
05-Nov-2010 |
Axel Lin <axel.lin@gmail.com> |
regulator: Return proper error for regulator_register() Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e36c1df8 |
|
05-Nov-2010 |
Axel Lin <axel.lin@gmail.com> |
regulator: Ensure enough delay time for enabling regulator Integer division will truncate the result, this patch ensures we have enough delay time for enabling regulator. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
aa7a7404 |
|
05-Nov-2010 |
Axel Lin <axel.lin@gmail.com> |
regulator: Remove a redundant device_remove_file call in create_regulator We already have device_remove_file() in error path, no need to call it before goto link_name_err. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
b12a1e29 |
|
02-Nov-2010 |
Mattias Wallin <mattias.wallin@stericsson.com> |
regulator: regulator disable supply fix This patch fixes a disable failure when regulator supply is used. A while loop in regulator disable checks for supply pointer != NULL but the pointer is not always updated, resulting in the while loop running too many times causing a disable failure. Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com> Acked-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
8cbf811d |
|
08-Oct-2010 |
Jeffrey Carlyle <jeff.carlyle@motorola.com> |
regulator: avoid deadlock when disabling regulator with supply I have a regulator A that sets regulator B as its supply. When I call set_supply to add B as the supply for A, regulator A gets added to the supply_list for regulator B. When I call regulator_disable(A), I end up with a call chain like this: regulator_disable(A) > mutex_lock(A) > _regulator_disable(A) >> _regulator_disable(B) >>> _notifier_call_chain(B) >>>> mutex_lock(A) Which results in dead lock since we are trying to acquire the mutex lock for regulator A which we already hold. This patch addresses this issue by moving the call to disable regulator B outside of the lock aquired inside the initial call to regulator_disable. This change also addresses the issue of not acquiring the mutex for regulator B before calling _regulator_disable(B). Signed-off-by: Jeffrey Carlyle <jeff.carlyle@motorola.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
688fe99a |
|
05-Oct-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add option for machine drivers to enable the dummy regulator Allow machine drivers to explicitly enable the use of the dummy regulator, enabling simpler support for systems with only a few specific supplies visible to software. It is strongly recommended that this is not used on systems with substantial software control over their PMICs, for maximum functionality constrints should be as fully specified as possible. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e4a6376b |
|
21-Sep-2010 |
Cyril Chemparathy <cyril@ti.com> |
regulator: fix typo in current units This patch fixes a typo that incorrectly reports mA numbers as uA. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
ad7725cb |
|
19-Sep-2010 |
Vasiliy Kulikov <segooon@gmail.com> |
regulator: fix device_register() error handling If device_register() fails then call put_device(). See comment to device_register. Signed-off-by: Vasiliy Kulikov <segooon@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
068a2782 |
|
28-Jul-2010 |
Guenter Roeck <guenter.roeck@ericsson.com> |
regulator: Remove owner field from attribute initialization in regulator core driver Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
500b4ac9 |
|
17-May-2010 |
Sundar R Iyer <sundar.iyer@stericsson.com> |
regulator: return set_mode is same mode is requested On Mon, 2010-05-17 at 17:34 +0200, Mark Brown wrote: > This doesn't seem like the right error handling - if the driver has a > set_mode() you'd *expect* it to have a get_mode() but there's no need > for it to be a strict requirement. True. In such a case, even a valid request would be lost! So now in the updated patch: - check if get_mode is present to avoid oops; - if get_mode is not present, proceed anyways for the request. Here is the updated patch: >From bad0d5eb51ef84be5b100e3dd0f5a590ea0529b6 Mon Sep 17 00:00:00 2001 From: Sundar R Iyer <sundar.iyer@stericsson.com> Date: Fri, 14 May 2010 15:14:17 +0530 Subject: [PATCH 1/1] regulator: return set_mode when same mode is requested save I/O costs by returning when the same mode is requested for the regulator Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@stericsson.com> Signed-off-by: Sundar R Iyer <sundar.iyer@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
d4033b54 |
|
29-Apr-2010 |
Jani Nikula <ext-jani.1.nikula@nokia.com> |
regulator: simplify regulator_register() error handling Simply remove all consumer supplies for the regulator on errors. Remove unset_consumer_device_supply() which is no longer used. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
47bd53f0 |
|
29-Apr-2010 |
Jani Nikula <ext-jani.1.nikula@nokia.com> |
regulator: fix unset_regulator_supplies() to remove all matches Remove all matching consumer supplies, not just the first, to not leave dangling pointers. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
23b5cc2a |
|
29-Apr-2010 |
Jani Nikula <ext-jani.1.nikula@nokia.com> |
regulator: prevent registration of matching regulator consumer supplies Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Pointer comparison is not sufficient for non-NULL device name matching, so use strcmp(). Otherwise the semantics remain the same. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
0178f3e2 |
|
26-Apr-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow regulator-regulator supplies to be specified by name When one regulator supplies another allow the relationship to be specified using names rather than struct regulators, in a similar manner to that allowed for consumer supplies. This allows static configuration at compile time, reducing the need for dynamic init code. Also change the references to LINE supply to be system supply since line is sometimes used for actual supplies and therefore potentially confusing. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
4f26a2ab |
|
12-Mar-2010 |
Ameya Palande <ameya.palande@nokia.com> |
regulator: Get rid of lockdep warning WARNING: at kernel/lockdep.c:2706 sysfs_add_file_mode+0x4c/0xa8() Difference between v1 and v2: Moved sysfs_attr_init() call as first one to access the structure. Signed-off-by: Ameya Palande <ameya.palande@nokia.com> CC: Liam Girdwood <lrg@slimlogic.co.uk> CC: Mark Brown <broonie@opensource.wolfsonmicro.com> CC: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
88393161 |
|
16-Mar-2010 |
Thomas Weber <swirl@gmx.li> |
Fix typos in comments [Ss]ytem => [Ss]ystem udpate => update paramters => parameters orginal => original Signed-off-by: Thomas Weber <swirl@gmx.li> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
34abbd68 |
|
12-Feb-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
9a7f6a4c |
|
11-Feb-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Assume regulators are enabled if they don't report anything If a regulator driver does not provide a way to query if the driver is enabled then assume that it is enabled. This is very likely to reflect the actual state is more useful for callers than reporting an error. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
31aae2be |
|
20-Dec-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow regulators to specify the time taken to ramp on enable Regulators may sometimes take longer to enable than the control operation used to do so, either because the regulator has ramp rate control used to limit inrush current or because the control operation is very fast (GPIO being the most common example of this). In order to ensure that consumers do not rely on the regulator before it is enabled provide an enable_time() operation and have the core delay for that time before returning to the caller. This is implemented as a function since the ramp rate may be specified in voltage per unit time and therefore the time depend on the configuration. In future it would be desirable to allow the bulk operations to run the delays for multiple enables in parallel but this is not currently supported. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
84b68263 |
|
01-Dec-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add notifier event on regulator disable The intended use case is for drivers which disable regulators to save power but need to do some work to restore the hardware state when restarting. If the supplies are not actually disabled due to board limits or sharing with other active devices this notifier allows the driver to avoid unneeded reinitialisation, particularly when used with runtime PM. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
#
973e9a27 |
|
11-Feb-2010 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix display of null constraints for regulators If the regulator constraints are empty and there is no voltage reported then nothing will be added to the text displayed for the constraints, leading to random stack data being printed. This is unlikely to happen for practical regulators since most will at least report a voltage but should still be fixed. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
eb143ac1 |
|
15-Dec-2009 |
Lars-Peter Clausen <lars@metafoo.de> |
regulator: Fix unbalanced disables/enables in regulator_bulk_{enable,disable} error path Currently it is possible for regulator_bulk_{enable,disable} operations to generate unbalanced regulator_{disable,enable} calls in its error path. In case of an error only those regulators of the bulk operation which actually had been enabled/disabled should get their original state restored. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
fa2984d4 |
|
27-Nov-2009 |
Stefan Roese <sr@denx.de> |
regulator: core.c: Small coding style cleanup (indentation fixup) Signed-off-by: Stefan Roese <sr@denx.de> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
638f85c5 |
|
22-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Handle regulators without suspend mode configuration Since some regulators in the system may not support suspend mode configuration we need to allow some regulators to have a missing suspend mode configuration. Do this by requiring that disabled regulators are explicitly flagged and then skip over regulators that have no state specified. Try to avoid surprises by warning the if we could set the state but no configuration is provided. This also ensures that an all zeros configuration generates a warning rather than silently disabling the regulator. Reported-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1083c393 |
|
22-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Factor out regulator name pretty printing Some of the regulator API functions have code to allow the machine constraints to override the device supplied name for the regulator in the constraints in order to help tie logging to supplies on the board and disambiguate when there is more than one regulator chip in the system. Factor this code out into a new rdev_get_name() function and use it throughout the regulator API so that we always use the same name. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
8f031b48 |
|
22-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Display actual settings with constraints When voltage or current constraints are either missing or specify a range display the actual setting along with the constraints if we can. This can aid debugging of configuration problems. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
af5866c9 |
|
22-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Also lift apply_uV into machine_constraints_voltage() It makes sense to do all the voltage configuration in the one split out function. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e79055d6 |
|
19-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Factor out voltage constraint setup This allows constraints to take effect on regulators that support voltage setting but for which the board does not specify a voltage range (for example, because it is fixed correctly at system startup). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
5b307627 |
|
13-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Report error codes for bulk operations If we're going to log an error we may as well log what the error code that we're failing on is. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
60ef66fc |
|
13-Oct-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Handle missing constraints in _regulator_disable() Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
a7433cff |
|
25-Aug-2009 |
Linus Walleij <linus.walleij@stericsson.com> |
REGULATOR Handle positive returncode from enable This makes _regulator_enable() properly handle the case where a regulator is already on when you try to enable it. Currently it will erroneously handle positive return values as an error. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
9a2372fa |
|
03-Aug-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: regulator_enable() permission checking The regulator_enable() code wasn't actually checking that the machine constraints had given permission to enable the regulator. Add code to do that, but only if the regulator is not already on due to something like always_on or being left on at startup since in those cases there's no physical change being introduced and the constraint wouldn't make any sense. Also add matching code for disable(). We need to do less there since either regulator_enable() should have succeeded first or the board setup makes no sense. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
9332546f |
|
03-Aug-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Push locking for regulator_is_enabled() out Allows use by more of the internal regulator API code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
f25e0b4f |
|
03-Aug-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Check for constraints in regulator_init_complete() Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
b39480ac |
|
03-Aug-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Check for constraints before using them for name Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
9ed2099e |
|
21-Jul-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix support for deviceless supply mappings The patch to add support for looking up consumers by device name had the side effect of causing us to require a device which is at best premature since at least cpufreq still operates outside the device model. Remove that requirement. Reported-by: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
6bf87d17 |
|
21-Jul-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Warn when unregistering an in-use regulator We're probably going to start oopsing fairly soon after this happens. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
a7a1ad90 |
|
21-Jul-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add regulator voltage range check API Simplify checking of support for voltage ranges by providing an API which wraps the existing count and list operations. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
5ffbd136 |
|
21-Jul-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add regulator_get_exclusive() API Some consumers require complete control of the regulator and can't tolerate sharing it with other consumers, most commonly because they need to have the regulator actually disabled so can't have other consumers forcing it on. This new regulator_get_exclusive() API call allows these consumers to explicitly request this, documenting the assumptions that they are making. In order to simplify coding of such consumers the use count for regulators they request is forced to match the enabled state of the regulator when it is requested. This is not possible for consumers which can share regulators due to the need to keep track of the ownership of use counts. A new API call is used rather than an additional argument to the existing regulator_get() in order to avoid merge headaches with driver code in other trees. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
40f9244f |
|
17-Jun-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow consumer supplies to be set up with dev_name() Follow the approach suggested by Russell King and implemented by him in the clkdev API and allow consumer device supply mapings to be set up using the dev_name() for the consumer instead of the struct device. In order to avoid making existing machines instabuggy and creating merge issues the use of struct device is still supported for the time being. This resolves problems working with buses such as I2C which make the struct device available late providing that the final device name is known, which is the case for most embedded systems with fixed setups. Consumers must still use the struct device when calling regulator_get(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
be721979 |
|
04-Aug-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Provide mode to status conversion function This is useful for implementing get_status() in terms of get_mode(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
#
3e590918 |
|
28-Apr-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix default constraints for fixed voltage regulators Default voltage constraints were being provided for fixed voltage regulator where board constraints were not provided but these constraints used INT_MIN as the default minimum voltage which is not a valid value since it is less than zero. Use 1uV instead. Also set the default values we set in the constraints themselves since otherwise the max_uV constraint we determine will not be stored in the actual constraint strucutre and will therefore not be used. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
53032daf |
|
25-Apr-2009 |
Paul Walmsley <paul@pwsan.com> |
regulator core: fix double-free in regulator_register() error path During regulator registration, any error after device_register() will cause a double-free on the struct regulator_dev 'rdev'. The bug is in drivers/regulator/core.c:regulator_register(): ... scrub: device_unregister(&rdev->dev); clean: kfree(rdev); <--- rdev = ERR_PTR(ret); goto out; ... device_unregister() calls regulator_dev_release() which frees rdev. The subsequent kfree corrupts memory and causes some OMAP3 systems to oops on boot in regulator_get(). Applies against 2.6.30-rc3. Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
cd78dfc6 |
|
13-Apr-2009 |
Diego Liziero <diegoliz@gmail.com> |
drivers/regulator: fix when type is different from REGULATOR_VOLTAGE or REGULATOR_CURRENT When regulator_desc->type is something different from REGULATOR_VOLTAGE or REGULATOR_CURRENT the if should probably return ERR_PTR(-EINVAL) The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) @@ expression E; constant C; @@ ( - !E == C + E != C ) Signed-off-by: Diego Liziero <diegoliz@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
036de8ef |
|
08-Apr-2009 |
Dan Carpenter <error27@gmail.com> |
unreachable code in drms_uA_update() I removed the extra semi-colon and indented the return statement. The unreachable code was found by smatch (http://repo.or.cz/w/smatch.git). The patch was compile tested. regards, dan carpenter Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
ca725561 |
|
16-Mar-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Support disabling of unused regulators by machines At present it is not possible for machine constraints to disable regulators which have been left on when the system starts, for example as a result of fixed default configurations in hardware. This means that power may be wasted by these regulators if they are not in use. Provide intial support for this with a late_initcall which will disable any unused regulators if the machine has enabled this feature by calling regulator_has_full_constraints(). If this has not been called then print a warning to encourage users to fully specify their constraints so that we can change this to be the default behaviour in future. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
50f07596 |
|
16-Mar-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Don't increment use_count for boot_on regulators Don't set use_count for regulators that are enabled at boot since this stops the supply being disabled by well-behaved consumers which do balanced enables and disabled. Any consumers which don't do disables which are not matched by enables are unable to share regulators - shared regulators are the common case so the API should facilitate them. Consumers that want to disable regulators that are enabled when they start have two options: - Do a regulator_enable() prior to the disable to bring the use count in sync with the hardware state; this will ensure that if the regulator was enabled by another driver then this consumer will play nicely with it. - Use regulator_force_disable(); this explicitly bypasses any checks done by the core and documents the inability of the driver to share the supply. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
cd94b505 |
|
11-Mar-2009 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: refcount fixes Fix some refcounting issues in the regulator framework, supporting regulator_disable() for regulators that were enabled at boot time via machine constraints: - Update those regulators' usecounts after enabling, so they can cleanly be disabled at that level. - Remove the problematic per-consumer usecount, so there's only one level of enable/disable. Buggy consumers could notice different bug symptoms. The main example would be refcounting bugs; also, any (out-of-tree) users of the experimental regulator_set_optimum_mode() stuff which don't call it when they're done using a regulator. This is a net minor codeshrink. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1dc60343 |
|
11-Mar-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Don't warn if we failed to get a regulator The consumer can print a message if required, some consumers may have optional regulators and wish to downgrade the logging for them or ignore their absence. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
cacf90f2 |
|
02-Mar-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow boot_on regulators to be disabled by clients Rather than incrementing the reference count for boot_on regulators (which prevents them being disabled later on) simply force the regulator to be enabled when applying the constraints. Previously boot_on was essentially equivalent to always_on. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
3e2b9abd |
|
10-Mar-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Don't warn on omitted voltage constraints Specifying voltage constraints is optional (and only needed if the consumer is allowed to change the voltage) so don't complain unless a voltage has been specified. Also avoid surprises with a dangling else while we're here. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
4367cfdc |
|
26-Feb-2009 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: enumerate voltages (v2) Add a basic mechanism for regulators to report the discrete voltages they support: list_voltage() enumerates them using selectors numbered from 0 to an upper bound. Use those methods to force machine-level constraints into bounds. (Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board constraints for that rail are 2.0V to 3.6V ... so the range of voltages is then 2.4V to 3.3V on this board.) Export those voltages to the regulator consumer interface, so for example regulator hooked up to an MMC/SD/SDIO slot can report the actual voltage options available to cards connected there. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
a308466c |
|
26-Feb-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Allow regulators to set the initial operating mode This is useful when wishing to run in a fixed operating mode that isn't the default. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
fe203ddf |
|
11-Feb-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Suggest use of datasheet supply or pin names for consumers Update the documentation to suggest the use of datasheet names for the supplies requested by regulator consumers. Doing this makes it easier to tie the design for a given platform up with the requirements of the driver for a consumer. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
0f1d747b |
|
22-Jan-2009 |
Mike Rapoport <rppt@kernel.org> |
regulator: add unset_regulator_supplies to fix regulator_unregister Currently regulator_unregister does not clear regulator <--> consumer mapping. This patch introduces unset_regulator_supplies that clear the map. Signed-off-by: Mike Rapoport <mike@compulab.co.il> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
1fa9ad52 |
|
21-Jan-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Hoist struct regulator_dev out of core to fix notifiers Commit 872ed3fe176833f7d43748eb88010da4bbd2f983 caused regulator drivers to take the struct regulator_dev lock themselves which requires that the struct be visible to them. Band aid this by making the struct visible. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
0527100f |
|
19-Jan-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Pass regulator init data as explict argument when registering Rather than having the regulator init data read from the platform_data member of the struct device that is registered for the regulator make the init data an explict argument passed in when registering. This allows drivers to use the platform data for their own purposes if they wish. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
b136fb44 |
|
19-Jan-2009 |
Jonathan Cameron <jic23@cam.ac.uk> |
Regulator: Push lock out of _notifier_call_chain + add voltage change event. Regulator: Push lock out of _notifier_call_chain and into caller functions (side effect of fixing deadlock in regulator_force_disable) + Add a voltage changed event. Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
853116a1 |
|
15-Jan-2009 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: add get_status() Based on previous LKML discussions: * Update docs for regulator sysfs class attributes to highlight the fact that all current attributes are intended to be control inputs, including notably "state" and "opmode" which previously implied otherwise. * Define a new regulator driver get_status() method, which is the first method reporting regulator outputs instead of inputs. It can report on/off and error status; or instead of simply "on", report the actual operating mode. For the moment, this is a sysfs-only interface, not accessible to regulator clients. Such clients can use the current notification interfaces to detect errors, if the regulator reports them. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
6001e13c |
|
30-Dec-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: catch some registration errors Prevent registration of duplicate "struct regulator" names. They'd be unavailable, and clearly indicate something wrong. [Edited to remove check for NULL consumer device until we have a solution for things like cpufreq -- broonie] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
cf7bbcdf |
|
30-Dec-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Fix some kerneldoc rendering issues There are some minor textual changes in here as well, mostly to enable() and disable() but the primary goal of these changes is to fix misrenderings of the kerneldoc documentation for the regulator API. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
c8e7e464 |
|
30-Dec-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Add missing kerneldoc This is only the documentation that the kerneldoc system warns about. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
69279fb9 |
|
30-Dec-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Clean up kerneldoc warnings Remove kerneldoc warnings that don't relate to missing documentation, mostly by renaming parameters in the documentation to match their actual names. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
8dc5390d |
|
30-Dec-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Remove extraneous kerneldoc annotations Some of the internal structures have no kerneldoc but the ** at the start of the comment marking them for documentation. Remove the annotation until some is added. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
74f544c1 |
|
25-Nov-2008 |
Mike Rapoport <rppt@kernel.org> |
regulator: move set_machine_constraints after regulator device initialization Calling set_machine_constraints before regulator device initialization causes crash when constraints have apply_uV set. Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
7ad68e2f |
|
11-Nov-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: sysfs attribute reduction (v2) Clean up the sysfs interface to regulators by only exposing the attributes that can be properly displayed. For example: when a particular regulator method is needed to display the value, only create that attribute when that method exists. This cleaned-up interface is much more comprehensible. Most regulators only support a subset of the possible methods, so often more than half the attributes would be meaningless. Many "not defined" values are no longer necessary. (But handling of out-of-range values still looks a bit iffy.) Documentation is updated to reflect that few of the attributes are *always* present, and to briefly explain why a regulator may not have a given attribute. This adds object code, about a dozen bytes more than was removed by the preceding patch, but saves a bunch of per-regulator data associated with the now-removed attributes. So there's a net reduction in memory footprint. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
4fca9545 |
|
11-Nov-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: code shrink (v2) Shrink regulator core by removing duplication in attribute printing and probe() cleanup paths. Saves about 340 bytes (object) on ARM. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e573520b |
|
16-Nov-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: improved mode error checks Minor bugfixes in handling of regulator modes: - have the routine verifying regulator modes check against the set of legal modes (!); - have regulator_set_optimum_mode() verify the return value of regulator_ops.get_optimum_mode(), like drms_uA_update(); - one call to regulator_ops.set_mode() treated zero as a failure code; make this consistent with other callers. Both regulator_set_mode() and regulator_set_optimum_mode() now require valid_ops_mask to include REGULATOR_CHANGE_MODE; that seems like a bugfix too. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
412aec61 |
|
16-Nov-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
regulator: enable/disable refcounting Make the <linux/regulator.h> framework treat enable/disable call pairs like the <linux/clk.h> and <linux/interrupt.h> frameworks do: they're refcounted, so that different parts of a driver don't need to put work into coordination that frameworks normally handle. It's a minor object code shrink. It also makes the regulator_is_disabled() kerneldoc say what it's actually returning: return value is not a refcount, and may report an error (e.g. I/O error from I2C). It also fixes some minor regulator_put() goofage: removing unlocked access to the enable state. (But still not making regulator put/get match the refcounting pattern they invoke.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
812460a9 |
|
01-Nov-2008 |
Kay Sievers <kay.sievers@vrfy.org> |
regulator: struct device - replace bus_id with dev_name(), dev_set_name() This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct device". To set and read the device name dev_name(dev) and dev_set_name(dev) must be used. If your code uses static kobjects, which it shouldn't do, "const char *init_name" can be used to statically provide the name the registered device should have. At registration time, the init_name field is cleared, to enforce the use of dev_name(dev) to access the device name at a later time. We need to get rid of all occurrences of bus_id in the entire tree to be able to enable the new interface. Please apply this patch, and possibly convert any remaining remaining occurrences of bus_id. We want to submit a patch to -next, which will remove bus_id from "struct device", to find the remaining pieces to convert, and finally switch over to the new api, which will remove the 20 bytes array and does no longer have a size limitation. Thanks, Kay From: Kay Sievers <kay.sievers@vrfy.org> Subject: regulator: struct device - replace bus_id with dev_name(), dev_set_name() Cc: Liam Girdwood <lrg@slimlogic.co.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
bc558a60 |
|
10-Oct-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Export regulator name via sysfs Provide a new file 'name' in the regulator sysfs class with a human readable name for the regulator for use in applications. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e5fda26c |
|
09-Sep-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Enable regulators marked as always_on If the machine constraints mark a regulator as always_on but this was not done by the bootloader then enable the regulator when applying constraints. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
e06f5b4f |
|
09-Sep-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: Additional diagnostics for machine constraints Try to find a human readable name for the regulator we're failing on and print a specific diagnostic when we fail to set the suspend state. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
46fabe1e |
|
09-Sep-2008 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
regulator: check for init_data on registration Since it is now mandatory to supply constraints via init_data on device registration check for that when registering, saving us from oopsing later on. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
a5766f11 |
|
10-Oct-2008 |
Liam Girdwood <lrg@slimlogic.co.uk> |
regulator: core - Rework machine API to remove string based functions. This improves the machine level API in order to configure regulator constraints and consumers as platform data and removes the old string based API that required several calls to set up each regulator. The intention is to create a struct regulator_init_data, populate it's fields with constraints, consumers devices, etc and then register the regulator device from board.c in the standard Linux way. e.g. regulator LDO2 (supplying codec and sim) platform data. /* regulator LDO2 consumer devices */ static struct regulator_consumer_supply ldo2_consumers[] = { { .dev = &platform_audio_device.dev, .supply = "codec_avdd", }, { .dev = &platform_sim_device.dev, .supply = "sim_vcc", } }; /* regulator LDO2 constraints */ static struct regulator_init_data ldo2_data = { .constraints = { .min_uV = 3300000, .max_uV = 3300000, .valid_modes_mask = REGULATOR_MODE_NORMAL, .apply_uV = 1, }, .num_consumer_supplies = ARRAY_SIZE(ldo2_consumers), .consumer_supplies = ldo2_consumers, }; /* machine regulator devices with thier consumers and constraints */ static struct platform_device wm8350_regulator_devices[] = { { .name = "wm8350-regulator", .id = WM8350_LDO_2, .dev = { .platform_data = &ldo2_data, }, }, }; Changes in detail:- o Removed all const char* regulator config functions in machine API. o Created new struct regulator_init_data to contain regulator machine configuration constraints and consmuers. o Changed set_supply(), set_machine_constraints(), set_consumer_device_supply() to remove their string identifier parameters. Also made them static and moved functions nearer top of core.c. o Removed no longer used inline func to_rdev() o Added regulator_get_init_drvdata() to retrieve init data. o Added struct device* as parameter to regulator_register(). o Changed my email address. Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
#
414c70cb |
|
30-Apr-2008 |
Liam Girdwood <lg@opensource.wolfsonmicro.com> |
regulator: regulator framework core This adds the regulator framework core. This framework is designed to provide a generic interface to voltage and current regulators within the Linux kernel. It's intended to provide voltage and current control to client or consumer drivers and also provide status information to user space applications through a sysfs interface. The intention is to allow systems to dynamically control regulator output in order to save power and prolong battery life. This applies to both voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable). This framework safely compiles out if not selected so that client drivers can still be used in systems with no software controllable regulators. Signed-off-by: Liam Girdwood <lg@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|