devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20191004231017.130290-6-dmitry.torokhov@gmail.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-5-dmitry.torokhov@gmail.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-4-dmitry.torokhov@gmail.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_gpiod_get_from_of_node() is being retired in favor of
[devm_]fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Note that now that we have a good non-devm API for getting GPIO from
arbitrary firmware node, there is no reason to use devm API here as
regulator core takes care of managing lifetime of "enable" GPIO and we
were immediately detaching requested GPIO from devm anyway.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-3-dmitry.torokhov@gmail.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-2-dmitry.torokhov@gmail.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Only the desc field is really used, so use struct regulator_desc instead.
Then struct pbias_regulator_data can be removed.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191007114320.20977-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It's more straightforward to use for statement here.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Link: https://lore.kernel.org/r/20191007115009.25672-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Inside function max8907_regulator_probe(), variable val could
be uninitialized if regmap_read() fails. However, val is used
later in the if statement to decide the content written to
"pmic", which is potentially unsafe.
Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/pcap-regulator.c:89:27: warning:
SW3_table defined but not used [-Wunused-const-variable=]
It is never used, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190928085540.45332-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20190926055128.23434-2-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This Power IC is used in combination with various PMIC combos,
generally found on boards with MSM8992, MSM8994, MSM8996,
MSM8956, MSM8976 and others, usually at address 0x5 on the SPMI
bus, and its usual usage is to provide power to the GPU and/or
to the CPU clusters (APC0/APC1).
Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20190921095043.62593-6-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8950 provides 6 SMPS regulators, of which 5 HFSMPS
and one FTSMPS2.5 (s5), and 23 LDOs.
Add these to the RPM regulator driver.
Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20190921095043.62593-4-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8950 has 5 HFSMPS, 1 FTSMPS2.5 (s5, controlling APC voltage)
and 23 LDO regulators.
Add the configuration for this chip.
Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20190921095043.62593-3-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQUwxxKyE5l/npt8ARiEGxRG/Sl2wUCXYAIeQAKCRBiEGxRG/Sl
2/SzAQDEnoNxzV/R5kWFd+2kmFeY3cll0d99KMrWJ8om+kje6QD/cXxZHzFm+T1L
UPF66k76oOODV7cyndjXnTnRXbeCRAM=
=Szby
-----END PGP SIGNATURE-----
Merge tag 'leds-for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
Pull LED updates from Jacek Anaszewski:
"In this cycle we've finally managed to contribute the patch set
sorting out LED naming issues. Besides that there are many changes
scattered among various LED class drivers and triggers.
LED naming related improvements:
- add new 'function' and 'color' fwnode properties and deprecate
'label' property which has been frequently abused for conveying
vendor specific names that have been available in sysfs anyway
- introduce a set of standard LED_FUNCTION* definitions
- introduce a set of standard LED_COLOR_ID* definitions
- add a new {devm_}led_classdev_register_ext() API with the
capability of automatic LED name composition basing on the
properties available in the passed fwnode; the function is
backwards compatible in a sense that it uses 'label' data, if
present in the fwnode, for creating LED name
- add tools/leds/get_led_device_info.sh script for retrieving LED
vendor, product and bus names, if applicable; it also performs
basic validation of an LED name
- update following drivers and their DT bindings to use the new LED
registration API:
- leds-an30259a, leds-gpio, leds-as3645a, leds-aat1290, leds-cr0014114,
leds-lm3601x, leds-lm3692x, leds-lp8860, leds-lt3593, leds-sc27xx-blt
Other LED class improvements:
- replace {devm_}led_classdev_register() macros with inlines
- allow to call led_classdev_unregister() unconditionally
- switch to use fwnode instead of be stuck with OF one
LED triggers improvements:
- led-triggers:
- fix dereferencing of null pointer
- fix a memory leak bug
- ledtrig-gpio:
- GPIO 0 is valid
Drop superseeded apu2/3 support from leds-apu since for apu2+ a newer,
more complete driver exists, based on a generic driver for the AMD
SOCs gpio-controller, supporting LEDs as well other devices:
- drop profile field from priv data
- drop iosize field from priv data
- drop enum_apu_led_platform_types
- drop superseeded apu2/3 led support
- add pr_fmt prefix for better log output
- fix error message on probing failure
Other misc fixes and improvements to existing LED class drivers:
- leds-ns2, leds-max77650:
- add of_node_put() before return
- leds-pwm, leds-is31fl32xx:
- use struct_size() helper
- leds-lm3697, leds-lm36274, leds-lm3532:
- switch to use fwnode_property_count_uXX()
- leds-lm3532:
- fix brightness control for i2c mode
- change the define for the fs current register
- fixes for the driver for stability
- add full scale current configuration
- dt: Add property for full scale current.
- avoid potentially unpaired regulator calls
- move static keyword to the front of declarations
- fix optional led-max-microamp prop error handling
- leds-max77650:
- add of_node_put() before return
- add MODULE_ALIAS()
- Switch to fwnode property API
- leds-as3645a:
- fix misuse of strlcpy
- leds-netxbig:
- add of_node_put() in netxbig_leds_get_of_pdata()
- remove legacy board-file support
- leds-is31fl319x:
- simplify getting the adapter of a client
- leds-ti-lmu-common:
- fix coccinelle issue
- move static keyword to the front of declaration
- leds-syscon:
- use resource managed variant of device register
- leds-ktd2692:
- fix a typo in the name of a constant
- leds-lp5562:
- allow firmware files up to the maximum length
- leds-an30259a:
- fix typo
- leds-pca953x:
- include the right header"
* tag 'leds-for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: (72 commits)
leds: lm3532: Fix optional led-max-microamp prop error handling
led: triggers: Fix dereferencing of null pointer
leds: ti-lmu-common: Move static keyword to the front of declaration
leds: lm3532: Move static keyword to the front of declarations
leds: trigger: gpio: GPIO 0 is valid
leds: pwm: Use struct_size() helper
leds: is31fl32xx: Use struct_size() helper
leds: ti-lmu-common: Fix coccinelle issue in TI LMU
leds: lm3532: Avoid potentially unpaired regulator calls
leds: syscon: Use resource managed variant of device register
leds: Replace {devm_}led_classdev_register() macros with inlines
leds: Allow to call led_classdev_unregister() unconditionally
leds: lm3532: Add full scale current configuration
dt: lm3532: Add property for full scale current.
leds: lm3532: Fixes for the driver for stability
leds: lm3532: Change the define for the fs current register
leds: lm3532: Fix brightness control for i2c mode
leds: Switch to use fwnode instead of be stuck with OF one
leds: max77650: Switch to fwnode property API
led: triggers: Fix a memory leak bug
...
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>
This fixes 11da04af0d, as devm_gpiod_get_from_of_node() does
not do translation "con-id" -> "con-id-gpios" that our bindings expects,
and therefore it was wrong to change connection ID to be simply "enable"
when moving to using devm_gpiod_get_from_of_node().
Fixes: 11da04af0d ("regulator: da9211: Pass descriptors instead of GPIO numbers")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190910170246.GA56792@dtor-ws
Signed-off-by: Mark Brown <broonie@kernel.org>
This fixes 96392c3d8c, as devm_gpiod_get_from_of_node() does
not do translation "con-id" -> "con-id-gpios" that our bindings expects,
and therefore it was wrong to change connection ID to be simply
"maxim,ena" when moving to using devm_gpiod_get_from_of_node().
Fixes: 96392c3d8c ("regulator: max77686: Pass descriptor instead of GPIO number")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190910170050.GA55530@dtor-ws
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
The value under 's2mps11->ext_control_gpiod[i]' is assigned to local
variable and used in probe in one place before. Use it consistently
later so code will be easier to read.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20190909155723.24734-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use rdev->regmap/&rdev->dev instead of lp87565->regmap/lp87565->dev.
In additional, the lp87565->dev actually is the parent mfd device,
so the dev_err message is misleading here with lp87565->dev.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20190908035720.17748-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The CS GPIO line is clearly optional GPIO (and marked as such in the
binding document) and we should handle it accordingly. The current code
treats all errors as meaning that there is no GPIO defined, which is
wrong, as it does not handle deferrals raised by the underlying code
properly, nor does it recognize non-existing GPIO from any other
initialization error.
As far as I can see the only reason the driver, unlike all others,
is using OF-specific devm_gpiod_get_from_of_node() so that it can
assign a custom label to the selected GPIO line. Given that noone else
needs that, it should not be doing that either.
Let's switch to using more appropriate devm_gpiod_get_optional().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190904214200.GA66118@dtor-ws
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't populate the array en_mask on the stack but instead make it
static const. Makes the object code smaller by 87 bytes.
Before:
text data bss dec hex filename
12967 3408 0 16375 3ff7 drivers/regulator/lp8788-ldo.o
After:
text data bss dec hex filename
12816 3472 0 16288 3fa0 drivers/regulator/lp8788-ldo.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190906130632.6709-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In case of a missing (optional) gpio don't fall through up to
"ti,active-discharge-time-us" due to
devm_fwnode_get_index_gpiod_from_child() returning NULL (since
gpiod_get_from_of_node() returned NULL) but rather indicate success as
intended.
This makes the driver probe correctly when e.g. only the enable gpio is
given.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Link: https://lore.kernel.org/r/363bd50cc7c60daa57d614a341d1fd649f05194c.1567625660.git.agx@sigxcpu.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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
There are many regulator consumers who - before using the regulator
bulk functions - set the supply names in regulator_bulk_data using
a for loop.
Let's provide a simple helper in the consumer API that allows users
to do the same with a single function call.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20190830071740.4267-2-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
The mt6358 driver was merged in error, it depends on an existing MFD
rather than a newly added one and needs updates to that driver. Disable
the build until those are merged.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6358 is a regulator found on boards based on MediaTek MT8183 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Link: https://lore.kernel.org/r/1566531931-9772-8-git-send-email-hsin-hsiung.wang@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The differences between SY8824C and SY20278 are different regs
for mode/enable.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163830.2c94f29b@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The differences between SY8824C and SY20276 are different vsel_min,
vsel_step, vsel_count and regs for mode/enable.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163721.1947f7a0@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
SY8824C is an I2C attached single output regulator made by Silergy Corp,
which is used on several Synaptics berlin platforms to control the
power supply of the ARM cores.
Add a driver for it.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163418.1a32fc48@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Variable ret is initialized to a value that is never read before
a return statement and hence can be removed. Remove it.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190813133114.14931-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
_opp_supported_by_regulators() wrongly ignored errors from
regulator_is_supported_voltage(), so it considered errors as
success. Since
commit 4982094451 ("regulator: core: simplify return value on suported_voltage")
regulator_is_supported_voltage() returns a real boolean, so
errors make _opp_supported_by_regulators() return false.
That reveals a problem with the declaration of the VDD1/2
regulators on twl4030.
The VDD1/VDD2 regulators on twl4030 are neither defined with
voltage lists nor with the continuous flag set, so
regulator_is_supported_voltage() returns false and an error
before above mentioned commit (which was considered success)
The result is that after the above mentioned commit cpufreq
does not work properly e.g. dm3730.
[ 2.490997] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV: 1012500, not supported by regulator
[ 2.501617] cpu cpu0: _opp_add: OPP not supported by regulators (300000000)
[ 2.509246] core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator
[ 2.519775] cpu cpu0: _opp_add: OPP not supported by regulators (600000000)
[ 2.527313] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV: 1325000, not supported by regulator
[ 2.537750] cpu cpu0: _opp_add: OPP not supported by regulators (800000000)
The patch fixes declaration of VDD1/2 regulators by
adding proper voltage lists.
Fixes: 4982094451 ("regulator: core: simplify return value on suported_voltage")
Cc: stable@vger.kernel.org
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Link: https://lore.kernel.org/r/20190814214319.24087-1-andreas@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
During reset the VMMC regulator doesn't reach 0V and only drops to
1.8V, furthermore the pulse width is under 200us whereas the SD
specification expect 1ms.
The WR_S bit allows the TWL6030 to no reset at all the VMMC during warm
reset and keep the current voltage. Thanks to this workaround the SD
card doesn't reach a undefined reset stage.
Actually this behavior is available for all the LDO regulator, so the
driver will also allow to use it with any of these regulator.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20190725094542.16547-4-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It helps to keep sorted order for compatibles, so sort them
Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20190809073616.1235-2-vkoul@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Building without CONFIG_POWER_SUPPLY will fail:
drivers/regulator/act8865-regulator.o: In function `act8865_pmic_probe':
act8865-regulator.c:(.text+0x357): undefined reference to `devm_power_supply_register'
drivers/regulator/act8865-regulator.o: In function `act8600_charger_get_property':
act8865-regulator.c:(.text+0x3f1): undefined reference to `power_supply_get_drvdata'
Add POWER_SUPPLY dependency to Kconfig.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 2d09a79bf6 ("regulator: act8865: Add support for act8600 charger")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190807133822.67124-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
