Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
045a44d4 |
| 14-Jul-2023 |
Rob Herring <robh@kernel.org> |
regulator: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of th
regulator: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174930.4063320-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22 |
|
#
02bcba0b |
| 26-Mar-2023 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
regulator: Handle deferred clk
devm_clk_get() can return -EPROBE_DEFER. So it is better to return the error code from devm_clk_get(), instead of a hard coded -ENOENT.
This gives more opportunities
regulator: Handle deferred clk
devm_clk_get() can return -EPROBE_DEFER. So it is better to return the error code from devm_clk_get(), instead of a hard coded -ENOENT.
This gives more opportunities to successfully probe the driver.
Fixes: 8959e5324485 ("regulator: fixed: add possibility to enable by clock") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/18459fae3d017a66313699c7c8456b28158b2dd0.1679819354.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.21, v6.1.20 |
|
#
259b93b2 |
| 16-Mar-2023 |
Douglas Anderson <dianders@chromium.org> |
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14
Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulato
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14
Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc).
While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually.
Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe.
The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver".
[1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/
Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17 |
|
#
7dda20c9 |
| 10-Mar-2023 |
Rob Herring <robh@kernel.org> |
regulator: Use of_property_present() for testing DT property presence
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_pro
regulator: Use of_property_present() for testing DT property presence
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144721.1544756-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32 |
|
#
6c315afe |
| 24-Mar-2022 |
Mark Brown <broonie@kernel.org> |
regulator: fixed: Remove print on allocation failure
OOMs are very verbose, we don't need to print an additional error message when we fail to allocate.
Signed-off-by: Mark Brown <broonie@kernel.or
regulator: fixed: Remove print on allocation failure
OOMs are very verbose, we don't need to print an additional error message when we fail to allocate.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220324201854.3107077-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53 |
|
#
d0f95e64 |
| 21-Jul-2021 |
Chris Morgan <macromorgan@hotmail.com> |
regulator: fixed: use dev_err_probe for register
Instead of returning error directly, use dev_err_probe. This avoids messages in the dmesg log for devices which will be probed again later.
Signed-o
regulator: fixed: use dev_err_probe for register
Instead of returning error directly, use dev_err_probe. This avoids messages in the dmesg log for devices which will be probed again later.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20210721165716.19915-1-macroalpha82@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46 |
|
#
7740ab84 |
| 16-Jun-2021 |
Rouven Czerwinski <r.czerwinski@pengutronix.de> |
regulator: fixed: use dev_err_probe for gpio
Instead of returning the the PTR_ERR directly, use dev_err_probe which will also correctly set the deferred probe reason in /sys/kernel/debug/deferred_de
regulator: fixed: use dev_err_probe for gpio
Instead of returning the the PTR_ERR directly, use dev_err_probe which will also correctly set the deferred probe reason in /sys/kernel/debug/deferred_devices, making it easier to debug missing devices on the system.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de> Link: https://lore.kernel.org/r/20210616125331.153414-1-r.czerwinski@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39 |
|
#
855bfff9 |
| 20-May-2021 |
Axel Lin <axel.lin@ingics.com> |
regulator: fixed: Ensure enable_counter is correct if reg_domain_disable fails
dev_pm_genpd_set_performance_state() may fail, so had better to check it's return value before decreasing priv->enable_
regulator: fixed: Ensure enable_counter is correct if reg_domain_disable fails
dev_pm_genpd_set_performance_state() may fail, so had better to check it's return value before decreasing priv->enable_counter.
Fixes: bf3a28cf4241 ("regulator: fixed: support using power domain for enable/disable") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210520111811.1806293-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17 |
|
#
bf3a28cf |
| 23-Oct-2020 |
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> |
regulator: fixed: support using power domain for enable/disable
Adds possibility to choose the compatible "fixed-regulator-domain" for regulators which use power domain for enabling/disabling corres
regulator: fixed: support using power domain for enable/disable
Adds possibility to choose the compatible "fixed-regulator-domain" for regulators which use power domain for enabling/disabling corresponding regulator.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201023131925.334864-3-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10 |
|
#
96ee75ff |
| 13-Sep-2020 |
Rikard Falkeborn <rikard.falkeborn@gmail.com> |
regulator: fixed: Constify static regulator_ops
The only usage of fixed_voltage_ops and fixed_voltage_clkenabled_ops is to assign their address the ops field in the regulator_desc struct, which is a
regulator: fixed: Constify static regulator_ops
The only usage of fixed_voltage_ops and fixed_voltage_clkenabled_ops is to assign their address the ops field in the regulator_desc struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. make them const to allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-3-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60 |
|
#
0f037255 |
| 20-Aug-2020 |
Jisheng Zhang <Jisheng.Zhang@synaptics.com> |
regulator: fixed: Fix W=1 build warnings when CONFIG_OF=n
Fix below warnings when CONFIG_OF=n:
drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but not used [-Wunused-const-
regulator: fixed: Fix W=1 build warnings when CONFIG_OF=n
Fix below warnings when CONFIG_OF=n:
drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but not used [-Wunused-const-variable=] 48 | static const struct fixed_dev_type fixed_clkenable_data = { | ^~~~~~~~~~~~~~~~~~~~ drivers/regulator/fixed.c:44:36: warning: ‘fixed_voltage_data’ defined but not used [-Wunused-const-variable=] 44 | static const struct fixed_dev_type fixed_voltage_data = { | ^~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200821111403.3e8b58a3@xhacker.debian Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.8.2, v5.4.59, v5.8.1, v5.4.58 |
|
#
09dad81e |
| 10-Aug-2020 |
Colin Ian King <colin.king@canonical.com> |
regulator: fix spelling mistake "Cant" -> "Can't"
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/
regulator: fix spelling mistake "Cant" -> "Can't"
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200810093931.50624-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2 |
|
#
d3f37233 |
| 09-Jun-2020 |
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> |
regulator: Fix trivial spelling
The word 'descriptor' is misspelled throughout the tree.
Fix it up accordingly: decriptors -> descriptors
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@
regulator: Fix trivial spelling
The word 'descriptor' is misspelled throughout the tree.
Fix it up accordingly: decriptors -> descriptors
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20200609124610.3445662-10-kieran.bingham+renesas@ideasonboard.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
f7907e57 |
| 28-Oct-2019 |
Peng Fan <peng.fan@nxp.com> |
regulator: fixed: add off-on-delay
Depends on board design, the gpio controlling regulator may connects with a big capacitance. When need off, it takes some time to let the regulator to be truly off
regulator: fixed: add off-on-delay
Depends on board design, the gpio controlling regulator may connects with a big capacitance. When need off, it takes some time to let the regulator to be truly off. If not add enough delay, the regulator might have always been on, so introduce off-on-delay to handle such case.
Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1572311875-22880-3-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2 |
|
#
1d6db22f |
| 21-Sep-2019 |
Axel Lin <axel.lin@ingics.com> |
regulator: fixed: Prevent NULL pointer dereference when !CONFIG_OF
Use of_device_get_match_data which has NULL test for match before dereference match->data. Add NULL test for drvtype so it still wo
regulator: fixed: Prevent NULL pointer dereference when !CONFIG_OF
Use of_device_get_match_data which has NULL test for match before dereference match->data. Add NULL test for drvtype so it still works for fixed_voltage_ops when !CONFIG_OF.
Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20190922022928.28355-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.3.1, v5.3, v5.2.14 |
|
#
8959e532 |
| 10-Sep-2019 |
Philippe Schenker <philippe.schenker@toradex.com> |
regulator: fixed: add possibility to enable by clock
This commit adds the possibility to choose the compatible "regulator-fixed-clock" in devicetree.
This is a special regulator-fixed that has to h
regulator: fixed: add possibility to enable by clock
This commit adds the possibility to choose the compatible "regulator-fixed-clock" in devicetree.
This is a special regulator-fixed that has to have a clock, from which the regulator gets switched on and off.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20190910062103.39641-2-philippe.schenker@toradex.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
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 th
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>
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19 |
|
#
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 au
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>
show more ...
|
Revision tags: v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8 |
|
#
5e6f3ae5 |
| 06-Dec-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: fixed: Let core handle GPIO descriptor
Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors.
Fixes: efdfeb079cc3 ("
regulator: fixed: Let core handle GPIO descriptor
Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors.
Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") 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>
show more ...
|
Revision tags: v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14 |
|
#
b0ce7b29 |
| 12-Oct-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator/gpio: Allow nonexclusive GPIO access
This allows nonexclusive (simultaneous) access to a single GPIO line for the fixed regulator enable line. This happens when several regulators use the
regulator/gpio: Allow nonexclusive GPIO access
This allows nonexclusive (simultaneous) access to a single GPIO line for the fixed regulator enable line. This happens when several regulators use the same GPIO for enabling and disabling a regulator, and all need a handle on their GPIO descriptor.
This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency. The current use inside the regulator core should however be fine as it takes special care to handle this.
For the state of the GPIO backend, this is still the lesser evil compared to going back to global GPIO numbers.
Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Jon Hunter <jonathanh@nvidia.com> Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> 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>
show more ...
|
Revision tags: v4.18.13, v4.18.12 |
|
#
28be5f15 |
| 01-Oct-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: fixed: Default enable high on DT regulators
commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") switched to use gpiod_get() to look up the regulator from the gpi
regulator: fixed: Default enable high on DT regulators
commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") switched to use gpiod_get() to look up the regulator from the gpiolib core whether that is device tree or boardfile.
This meant that we activate the code in a603a2b8d86e ("gpio: of: Add special quirk to parse regulator flags") which means the descriptors coming from the device tree already have the right inversion and open drain semantics set up from the gpiolib core.
As the fixed regulator was inspected again we got the inverted inversion and things broke.
Fix it by ignoring the config in the device tree for now: the later patches in the series will push all inversion handling over to the gpiolib core and set it up properly in the boardfiles for legacy devices, but I did not finish that for this kernel cycle.
Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Leonard Crestez <leonard.crestez@nxp.com> Reported-by: Fabio Estevam <festevam@gmail.com> Reported-by: John Stultz <john.stultz@linaro.org> Reported-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v4.18.11, v4.18.10, v4.18.9, v4.18.7 |
|
#
efdfeb07 |
| 06-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: fixed: Convert to use GPIO descriptor only
As we augmented the regulator core to accept a GPIO descriptor instead of a GPIO number, we can augment the fixed GPIO regulator to look up and
regulator: fixed: Convert to use GPIO descriptor only
As we augmented the regulator core to accept a GPIO descriptor instead of a GPIO number, we can augment the fixed GPIO regulator to look up and pass that descriptor directly from device tree or board GPIO descriptor look up tables.
Some boards just auto-enumerate their fixed regulator platform devices and I have assumed they get names like "fixed-regulator.0" but it's pretty hard to guess this. I need some testing from board maintainers to be sure. Other boards are straight forward, using just plain "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the device ID.
It seems the da9055 and da9211 has never got around to actually passing any enable gpio into its platform data (not the in-tree code anyway) so we can just decide to simply pass a descriptor instead.
The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named "*_dummy_supply_device" while it is a very real device backed by a GPIO line. There is nothing dummy about it at all, so I renamed it with the infix *_regulator_* as part of this patch set.
Intel MID portions tested by Andy.
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff Acked-by: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Reviewed-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1 |
|
#
e536700e |
| 07-Jun-2018 |
Mark Brown <broonie@kernel.org> |
regulator: gpio: Revert
regulator: fixed/gpio: Revert GPIO descriptor changes due to platform breakage
Commit 6059577cb28 "regulator: fixed: Convert to use GPIO descriptor only" broke at least the
regulator: gpio: Revert
regulator: fixed/gpio: Revert GPIO descriptor changes due to platform breakage
Commit 6059577cb28 "regulator: fixed: Convert to use GPIO descriptor only" broke at least the ams-delta platform since the lookup tables added to the board files use the function name "enable" while the driver uses NULL causing the regulator to not acquire and control the enable GPIOs. Revert that and a couple of other commits that are caught up with it to fix the issue:
2b6c00c157c5bf80 "ARM: pxa, regulator: fix building ezx e680" 6059577cb28d8b15 "regulator: fixed: Convert to use GPIO descriptor only" 37bed97f00734ce3 "regulator: gpio: Get enable GPIO using GPIO descriptor"
Reported-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v4.17 |
|
#
6059577c |
| 14-May-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator: fixed: Convert to use GPIO descriptor only
As we augmented the regulator core to accept a GPIO descriptor instead of a GPIO number, we can augment the fixed GPIO regulator to look up and
regulator: fixed: Convert to use GPIO descriptor only
As we augmented the regulator core to accept a GPIO descriptor instead of a GPIO number, we can augment the fixed GPIO regulator to look up and pass that descriptor directly from device tree or board GPIO descriptor look up tables.
Some boards just auto-enumerate their fixed regulator platform devices and I have assumed they get names like "fixed-regulator.0" but it's pretty hard to guess this. I need some testing from board maintainers to be sure. Other boards are straight forward, using just plain "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the device ID.
The OMAP didn't have proper label names on its GPIO chips so I have fixed this with a separate patch to the GPIO tree, see commit 088413bc0bd5f5fb66ca22a19d66a49d7154ba4c "gpio: omap: Give unique labels to each GPIO bank/chip"
It seems the da9055 and da9211 has never got around to actually passing any enable gpio into its platform data (not the in-tree code anyway) so we can just decide to simply pass a descriptor instead.
The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named "*_dummy_supply_device" while it is a very real device backed by a GPIO line. There is nothing dummy about it at all, so I renamed it with the infix *_regulator_* as part of this patch set.
For the patch hunk hitting arch/blackfin I would say I do not expect testing, review or ACKs anymore so if it works, it works.
The hunk hitting the x86 BCM43xx driver is especially tricky as the number comes out of SFI which is a mystery to me. I definately need someone to look at this. (Hi Andy.)
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff 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: 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 Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10 |
|
#
1372cef1 |
| 25-Jan-2017 |
Mark Rutland <mark.rutland@arm.com> |
regulator: fixed: Revert support for ACPI interface
This reverts commit 13bed58ce874 (regulator: fixed: add support for ACPI interface).
While there does appear to be a practical need to manage reg
regulator: fixed: Revert support for ACPI interface
This reverts commit 13bed58ce874 (regulator: fixed: add support for ACPI interface).
While there does appear to be a practical need to manage regulators on ACPI systems, using ad-hoc properties to describe regulators to the kernel presents a number of problems (especially should ACPI gain first class support for such things), and there are ongoing discussions as to how to manage this.
Until there is a rough consensus, revert commit 13bed58ce8748d43, which hasn't been in a released kernel yet as discussed in [1] and the surrounding thread.
[1] http://lkml.kernel.org/r/20170125184949.x2wkoo7kbaaajkjk@sirena.org.uk
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|