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 ff268b56ce ("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 c33d442328 ("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: c33d442328 ("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>
This patch adds suspend/resume support so that it is possible to
configure the LDOs and BUCKs as on or off during suspend phase as
well as to configure suspend specific voltages.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/4c2e79d4fa96befdc9a6c59c3ff27b0a34f9fb56.camel@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
With commit eaa7995c52 (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: eaa7995c52 (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>
The device node reference obtained with of_get_child_by_name() should be
dropped on error paths.
Fixes: 26aec009f6 ("regulator: add device tree support for s5m8767")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20210121155914.48034-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulators from PMC8180 and PMC8180C exposed by the RPMH in the
Qualcomm SC8180X seems to be the same as PM8150 and PM8150L. Add
compatibles for the two new PMICs and reuse the definition of the
existing PMICs.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210120224901.1611232-2-bjorn.andersson@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Call of_node_put() to drop references of regulators_np and reg_np before
returning error code.
Fixes: 9ae5cc75ce ("regulator: s5m8767: Pass descriptor instead of GPIO number")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20210121032756.49501-1-bianpan2016@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ST-Ericsson U300 platform is getting removed, so this driver is no
longer needed.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210120151307.1726876-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Okay, the title may be a little "aggressive"? However, the qcom-labibb
driver wasn't really .. doing much.
The current form of this driver is only taking care of enabling or
disabling the regulators, which is pretty useless if they were not
pre-set from the bootloader, which sets them only if continuous
splash is enabled.
Moreover, some bootloaders are setting a higher voltage and/or a higher
current limit compared to what's actually required by the attached
hardware (which is, in 99.9% of the cases, a display) and this produces
a higher power consumption, higher heat output and a risk of actually
burning the display if kept up for a very long time: for example, this
is true on at least some Sony Xperia MSM8998 (Yoshino platform) and
especially on some Sony Xperia SDM845 (Tama platform) smartphones.
In any case, the main reason why this change was necessary for us is
that, during the bringup of Sony Xperia MSM8998 phones, we had an issue
with the bootloader not turning on the display and not setting the lab
and ibb regulators before booting the kernel, making it impossible to
powerup the display.
With this said, this patchset enables setting voltage, current limiting,
overcurrent and short-circuit protection.. and others, on the LAB/IBB
regulators.
Each commit in this patch series provides as many informations as
possible about what's going on and testing methodology.
Changes in v4:
- Remove already applied commit
- Add commit to switch to regulator_{list,map}_voltage_linear
which in v3 got squashed in the commit that got removed in v4.
Changes in v3:
- Improved check for PBS disable and short-circuit condition:
during the testing of short-circuit, coincidentally another
register reading zero on the interesting bit was probed,
which didn't trigger a malfunction of the SC logic, but was
also wrong.
After the change, the short-circuit test was re-done in the
same way as described in the commit that is implementing it.
- From Bjorn Andersson review:
- Improved documentation about over-current and short-circuit
protection in the driver
- Improved maintainability of qcom_labibb_sc_recovery_worker()
- Flipped around check for PBS vreg disabled in for loop of
function labibb_sc_err_handler()
- From Mark Brown (forgotten in v2):
- Changed regulator_{list,map}_voltage_linear_range usages to
regulator_{list,map}_voltage_linear (and fixed regulator
descs to reflect the change).
Changes in v2:
- From Mark Brown review:
- Replaced some if branches with switch statements
- Moved irq get and request in probe function
- Changed short conditionals to full ones
- Removed useless check for ocp_irq_requested
- Fixed issues with YAML documentation
AngeloGioacchino Del Regno (7):
regulator: qcom-labibb: Switch voltage ops from linear_range to linear
regulator: qcom-labibb: Implement current limiting
regulator: qcom-labibb: Implement pull-down, softstart, active
discharge
dt-bindings: regulator: qcom-labibb: Document soft start properties
regulator: qcom-labibb: Implement short-circuit and over-current IRQs
dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts
arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP
.../regulator/qcom-labibb-regulator.yaml | 30 +-
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 +-
drivers/regulator/qcom-labibb-regulator.c | 720 +++++++++++++++++-
3 files changed, 735 insertions(+), 23 deletions(-)
--
2.30.0
Short-Circuit Protection (SCP) and Over-Current Protection (OCP) are
very important for regulators like LAB and IBB, which are designed to
provide from very small to relatively big amounts of current to the
device (normally, a display).
Now that this regulator supports both voltage setting and current
limiting in this driver, to me it looked like being somehow essential
to provide support for SCP and OCP, for two reasons:
1. SCP is a drastic measure to prevent damaging "more" hardware in
the worst situations, if any was damaged, preventing potentially
drastic issues;
2. OCP is a great way to protect the hardware that we're powering
through these regulators as if anything bad happens, the HW will
draw more current than expected: in this case, the OCP interrupt
will fire and the regulators will be immediately shut down,
preventing hardware damage in many cases.
Both interrupts were successfully tested in a "sort-of" controlled
manner, with the following methodology:
Short-Circuit Protection (SCP):
1. Set LAB/IBB to 4.6/-1.4V, current limit 200mA/50mA;
2. Connect a 10 KOhm resistor to LAB/IBB by poking the right traces
on a FxTec Pro1 smartphone for a very brief time (in short words,
"just a rapid touch with flying wires");
3. The Short-Circuit protection trips: IRQ raises, regulators get
cut. Recovery OK, test repeated without rebooting, OK.
Over-Current Protection (OCP):
1. Set LAB/IBB to the expected voltage to power up the display of
a Sony Xperia XZ Premium smartphone (Sharp LS055D1SX04), set
current limit to LAB 200mA, IBB 50mA (the values that this
display unit needs are 200/800mA);
2. Boot the kernel: OCP fires. Recovery never happens because
the selected current limit is too low, but that's expected.
Test OK.
3. Set LAB/IBB to the expected current limits for XZ Premium
(LAB 200mA, IBB 800mA), but lower than expected voltage,
specifically LAB 5.4V, IBB -5.6V (instead of 5.6, -5.8V);
4. Boot the kernel: OCP fires. Recovery never happens because
the selected voltage (still in the working range limits)
is producing a current draw of more than 200mA on LAB.
Test OK.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210119174421.226541-6-angelogioacchino.delregno@somainline.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Soft start is required to avoid inrush current during LAB ramp-up and
IBB ramp-down, protecting connected hardware to which we supply voltage.
Since soft start is configurable on both LAB and IBB regulators, it
was necessary to add two DT properties, respectively "qcom,soft-start-us"
to control LAB ramp-up and "qcom,discharge-resistor-kohms" to control
the discharge resistor for IBB ramp-down, which obviously brought the
need of implementing a of_parse callback for both regulators.
Finally, also implement pull-down mode in order to avoid unpredictable
behavior when the regulators are disabled (random voltage spikes etc).
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210119174421.226541-4-angelogioacchino.delregno@somainline.org
Signed-off-by: Mark Brown <broonie@kernel.org>
LAB and IBB regulators can be current-limited by setting the
appropriate registers, but this operation is granted only after
sending an unlock code for secure access.
Besides the secure access, it would be possible to use the
regmap helper for get_current_limit, as there is no security
blocking reads, but I chose not to as to avoid having a very
big array containing current limits, especially for IBB.
That said, these regulators support current limiting for:
- LAB (pos): 200-1600mA, with 200mA per step (8 steps),
- IBB (neg): 0-1550mA, with 50mA per step (32 steps).
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210119174421.226541-3-angelogioacchino.delregno@somainline.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The LAB and IBB regulator have just one range and it is useless
to use linear_range ops, as these are used to express multiple
linear ranges.
Switch list_voltage and map_voltage callbacks to *_linear instead.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210119174421.226541-2-angelogioacchino.delregno@somainline.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Okay, the title may be a little "aggressive"? However, the qcom-labibb
driver wasn't really .. doing much.
The current form of this driver is only taking care of enabling or
disabling the regulators, which is pretty useless if they were not
pre-set from the bootloader, which sets them only if continuous
splash is enabled.
Moreover, some bootloaders are setting a higher voltage and/or a higher
current limit compared to what's actually required by the attached
hardware (which is, in 99.9% of the cases, a display) and this produces
a higher power consumption, higher heat output and a risk of actually
burning the display if kept up for a very long time: for example, this
is true on at least some Sony Xperia MSM8998 (Yoshino platform) and
especially on some Sony Xperia SDM845 (Tama platform) smartphones.
In any case, the main reason why this change was necessary for us is
that, during the bringup of Sony Xperia MSM8998 phones, we had an issue
with the bootloader not turning on the display and not setting the lab
and ibb regulators before booting the kernel, making it impossible to
powerup the display.
With this said, this patchset enables setting voltage, current limiting,
overcurrent and short-circuit protection.. and others, on the LAB/IBB
regulators.
Each commit in this patch series provides as many informations as
possible about what's going on and testing methodology.
Changes in v2:
- From Mark Brown review:
- Replaced some if branches with switch statements
- Moved irq get and request in probe function
- Changed short conditionals to full ones
- Removed useless check for ocp_irq_requested
- Fixed issues with YAML documentation
AngeloGioacchino Del Regno (7):
regulator: qcom-labibb: Implement voltage selector ops
regulator: qcom-labibb: Implement current limiting
regulator: qcom-labibb: Implement pull-down, softstart, active
discharge
dt-bindings: regulator: qcom-labibb: Document soft start properties
regulator: qcom-labibb: Implement short-circuit and over-current IRQs
dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts
arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP
.../regulator/qcom-labibb-regulator.yaml | 30 +-
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 +-
drivers/regulator/qcom-labibb-regulator.c | 661 +++++++++++++++++-
3 files changed, 686 insertions(+), 13 deletions(-)
--
2.29.2
Implement {get,set}_voltage_sel, list_voltage, map_voltage with
the useful regulator regmap helpers in order to be able to manage
the voltage of LAB (positive) and IBB (negative) regulators.
In particular, the supported ranges are the following:
- LAB (pos): 4600mV to 6100mV with 100mV stepping,
- IBB (neg): -7700mV to -1400mV with 100mV stepping.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210113194214.522238-2-angelogioacchino.delregno@somainline.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the ternary condition which is a bad coding style
in the kernel
I also remove the defering configuration of the nxp,phase-shift.
The configuration is now done at parsing time. It save some memory
and it's better for comprehension.
I also use the OTP default configuration when the parameter is wrong
or not specified.
I think that it's better to use the default configuration from the chip
than an arbitrary value.
Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com>
Link: https://lore.kernel.org/r/20210114174714.122561-7-adrien.grassein@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This property seems useless because we can use the
regulator-max-microamp generic property to do the same
and using generic code.
As this property was already released in a kernel version,
we can't remove it, just mark it as deprecated.
Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com>
Link: https://lore.kernel.org/r/20210114174714.122561-5-adrien.grassein@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for BD9574MWF which is similar chip with BD9571MWV.
Note that we don't support voltage rails VD{09,18,25,33} by this
driver on BD9574. The VD09 voltage could be read from PMIC but that
is not supported by this commit.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The platform data header was only used to pass platform
data from board files. We now populate the regulators
exclusively from device tree, so the header contents can
be moved into the regulator drivers.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201205004057.1712753-2-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The struct ab8500_regulator_platform_data was a leftover
since the days before we probed all regulators from the
device tree. The ab8500-ext regulator was the only used,
defining platform data and register intialization that
was never used for anything, a copy of a boardfile no
longer in use.
Delete the ab8500_regulator_platform_data and make the
ab8500-ext regulator reference the regulator init data
in the local file directly. We are 100% device tree
these days.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201205004057.1712753-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Hi,
This patch makes the LPM pin as optional as this may be controlled
in the last phase of suspend procedure to decrease the power consumption
while suspended. Along w/ this update the MAINTAINERS entry for this
driver.
Thank you,
Claudiu Beznea
Claudiu Beznea (3):
dt-bindings: regulator: mcp16502: document lpm as optional
regulator: mcp16502: lpm pin can be optional on some platforms
MAINTAINERS: add myself as maintainer for mcp16502
Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt | 3 ++-
MAINTAINERS | 4 ++--
drivers/regulator/mcp16502.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The ROHM PMIC regulator drivers only need the regmap pointer from
the parent device. Regmap can be obtained via dev_get_regmap()
so do not require parent to populate driver data for that.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210107122355.GA35080@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
On some platform (e.g. SAMA7G5) LPM pin should be optional as it can
be controlled explicitly (via shutdown controller registers) in the
platform specific power saving code to decrease the power consumption
while suspended as this SoC pin may be connected to other devices that
could take power saving actions based on its value.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1610028927-9842-3-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This series is based on v5.10-rc1.
The patchsets add support for MediaTek hardware module named DVFSRC
(dynamic voltage and frequency scaling resource collector). The DVFSRC is
a HW module which is used to collect all the requests from both software
and hardware and turn into the decision of minimum operating voltage and
minimum DRAM frequency to fulfill those requests.
So, This series is to implement the dvfsrc driver to collect all the
requests of operating voltage or DRAM bandwidth from other device drivers
likes GPU/Camera through 3 frameworks basically:
1. interconnect framework: to aggregate the bandwidth
requirements from different clients
[1] https://patchwork.kernel.org/cover/10766329/
There has a hw module "DRAM scheduler", which used to control the throughput.
The DVFSRC will collect forecast data of dram bandwidth from
SW consumers(camera/gpu...), and according the forecast to change the DRAM
frequency
2. Regualtor framework: to handle the operating voltage requirement from user or
cosumer which not belong any power domain
Changes in V6:
* Remove the performace state support, because the request from consumer can be
replaced by using interconnect and regulator framework.
* Update the DT patches and convert them to DT schema. (Georgi)
* Modify the comment format and coding style. (Mark)
Changes in V5:
* Support more platform mt6873/mt8192
* Drop the compatible and interconnect provider node and make the parent node an
interconnect provider. (Rob/Georgi)
* Make modification of interconnect driver from coding suggestion. (Georgi)
* Move interconnect diagram into the commit text of patch. (Georgi)
* Register the interconnect provider as a platform sub-device. (Georgi)
Changes in V4:
* Add acked TAG on dt-bindings patches. (Rob)
* Declaration of emi_icc_aggregate since the prototype of aggregate function
has changed meanwhile. (Georgi)
* Used emi_icc_remove instead of icc_provider_del on probe. (Georgi)
* Add dvfsrc regulator driver into series.
* Bug fixed of mt8183_get_current_level.
* Add mutex protection for pstate operation on dvfsrc_set_performance.
Changes in V3:
* Remove RFC from the subject prefix of the series
* Combine dt-binding patch and move interconnect dt-binding document into
dvfsrc. (Rob)
* Remove unused header, add unit descirption to the bandwidth, rename compatible
name on interconnect driver. (Georgi)
* Fixed some coding style: check flow, naming, used readx_poll_timeout
on dvfsrc driver. (Ryan)
* Rename interconnect driver mt8183.c to mtk-emi.c
* Rename interconnect header mtk,mt8183.h to mtk,emi.h
* mtk-scpsys.c: Add opp table check first to avoid OF runtime parse failed
Changes in RFC V2:
* Remove the DT property dram_type. (Rob)
* Used generic dts property 'opp-level' to get the performace state. (Stephen)
* Remove unecessary dependency config on Kconfig. (Stephen)
* Remove unused header file, fixed some coding style issue, typo,
error handling on dvfsrc driver. (Nicolas/Stephen)
* Remove irq handler on dvfsrc driver. (Stephen)
* Remove init table on dvfsrc driver, combine hw init on trustzone.
* Add interconnect support of mt8183 to aggregate the emi bandwidth.
(Georgi)
V5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=348065
V4: https://lore.kernel.org/patchwork/cover/1209284/
V3: https://patchwork.kernel.org/cover/11118867/
RFC V2: https://lore.kernel.org/patchwork/patch/1068113/
RFC V1: https://lore.kernel.org/patchwork/cover/1028535/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The ROHM PMIC regulator drivers only need the regmap pointer from
the parent device. Regmap can be obtained via dev_get_regmap()
so do not require parent to populate driver data for that.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210105130221.GA3438042@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
Driver for regulators exposed by the DVFSRC (dynamic voltage and
frequency scaling resource collector) found in devices based on
mt8183 and newer platforms.
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Link: https://lore.kernel.org/r/1608790134-27425-12-git-send-email-henryc.chen@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.
base-commit: 5c8fe583cc
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 a5766f11cf ("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>
A built-in regulator driver cannot link against a modular cmd_db driver:
qcom-rpmh-regulator.c:(.text+0x174): undefined reference to `cmd_db_read_addr'
There is already a dependency for RPMh, so add another one of this
type for cmd_db.
Fixes: 34c5aa2666 ("regulator: Kconfig: Fix REGULATOR_QCOM_RPMH dependencies to avoid build error")
Fixes: 46fc033eba ("regulator: add QCOM RPMh regulator driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20201230145712.3133110-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 06369bcc15 ("regulator: qcom-rpmh: Add support for SM8150")
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201231122348.637917-4-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the datasheet pm8009's HFS515 regulators have 16mV
resolution rather than declared 1.6 mV. Correct the resolution.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 06369bcc15 ("regulator: qcom-rpmh: Add support for SM8150")
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201231122348.637917-3-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the DC-DC converters and LDO regulators found in
the ATC2603C and ATC2609A chip variants of the Actions Semi ATC260x
family of PMICs.
Co-developed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Link: https://lore.kernel.org/r/1117b1a01b3948446cb3cc407e52de3a5d4212b0.1609258905.git.cristian.ciocaltea@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Restrict REGULATOR_QCOM_RPMH to QCOM_COMMAND_DB it the latter is enabled.
Fixes this build error:
microblaze-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_probe':
(.text+0x354): undefined reference to `cmd_db_read_addr'
Fixes: 778279f4f5 ("soc: qcom: cmd-db: allow loading as a module")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Lina Iyer <ilina@codeaurora.org>
Link: https://lore.kernel.org/r/20201225185004.20747-1-rdunlap@infradead.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the typical startup times from the data sheet so boards get a
reasonable default. Not setting any enable time can lead to board hangs
when e.g. clocks are enabled too soon afterwards.
This fixes gpu power domain resume on the Librem 5.
[Moved #defines into driver, seems to be general agreement and avoids any
cross tree issues -- broonie]
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/41fb2ed19f584f138336344e2297ae7301f72b75.1608316658.git.agx@sigxcpu.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The pf8x00 driver supports three devices, the DT compatible strings
and I2C IDs should enumerate these specifically rather than using a
wildcard so that we don't collide with anything incompatible in the
same ID range in the future and so that we can handle any software
visible differences between the variants we find.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20201215132024.13356-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201210212748.5849-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add proper modalias structures to let this driver load automatically if
compiled as module, because max14577 MFD driver creates MFD cells with
such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201210112139.5370-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes a couple of bugs in the DA9121 driver.
One in an uninialised string I forgot to remove when changing to of_parse_cb()
The other is an index for an optional DT property which overflows
Adam Ward (2):
regulator: da9121: Remove uninitialised string variable
regulator: da9121: Fix index used for DT property
drivers/regulator/da9121-regulator.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
1.9.1
There is a missing "return ret;" on this error path so we call
"da9121_check_device_type(i2c, chip);" which will end up dereferencing
"chip->regmap" and lead to an Oops.
Fixes: c860476b9e ("regulator: da9121: Add device variant regmaps")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/X85soGKnWAjPUA7a@mwanda
Signed-off-by: Mark Brown <broonie@kernel.org>
When I use the axp20x chip to power my SDIO device on the 5.4 kernel,
the output voltage of DLDO2 is wrong. After comparing the register
manual and source code of the chip, I found that the mask bit of the
driver register of the port was wrong. I fixed this error by modifying
the mask register of the source code. This error seems to be a copy
error of the macro when writing the code. Now the voltage output of
the DLDO2 port of axp20x is correct. My development environment is
Allwinner A40I of arm architecture, and the kernel version is 5.4.
Signed-off-by: DingHua Ma <dinghua.ma.sz@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Cc: <stable@vger.kernel.org>
Fixes: db4a555f7c ("regulator: axp20x: use defines for masks")
Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support from RPMH regulators found in PM8350 and PM8350c PMICs
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20201203071244.2652297-2-vkoul@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When CONFIG_GPIOLIB is disabled, the declarations from linux/gpio/consumer.h
are not visible:
drivers/regulator/da9121-regulator.c:371:14: error: implicit declaration of function 'fwnode_gpiod_get_index' [-Werror,-Wimplicit-function-declaration]
ena_gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), "enable", 0,
^
drivers/regulator/da9121-regulator.c:372:7: error: use of undeclared identifier 'GPIOD_OUT_HIGH'
GPIOD_OUT_HIGH |
^
drivers/regulator/da9121-regulator.c:373:7: error: use of undeclared identifier 'GPIOD_FLAGS_BIT_NONEXCLUSIVE'
GPIOD_FLAGS_BIT_NONEXCLUSIVE,
Include this explicitly to help compile testing.
Fixes: 46c413d5bb ("regulator: da9121: Add support for device variants via devicetree")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201204165229.3754763-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following sparse warnings:
drivers/regulator/da9121-regulator.c:55:21: warning: symbol 'da9121_10A_2phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:63:21: warning: symbol 'da9121_6A_2phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:71:21: warning: symbol 'da9121_5A_1phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:79:21: warning: symbol 'da9121_3A_1phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:151:32: warning: symbol 'status_event_handling' was not declared. Should it be static?
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Acked-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/1606994795-36182-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds interrupt handler for variants, and notifications for events; over
temperature/voltage/current. Because the IRQs are triggered by persisting
status, they must be masked and the status polled until clear, before the
IRQ can be enabled again.
Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/fe21796bbcbadff84a472a4cc581ae8fafc7f8f5.1606755367.git.Adam.Ward.opensource@diasemi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add NXP PF8100/PF8121A/PF8200 regulator driver.
PF8100/PF8121A/PF8200 is PMIC designed for highperformance
consumer applications. It features seven high efficiency buck,
four linear and one vsnvs regulators.
Tested in Engicam i.Core MX8M Mini SOM platform boards.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Link: https://lore.kernel.org/r/20201130112329.104614-2-jagan@amarulasolutions.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: bdcd117757 ("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>
The kernel test robot reported the following build error:
All errors (new ones prefixed by >>):
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_vrm_get_voltage_sel':
qcom-rpmh-regulator.c:(.text+0x270): undefined reference to `rpmh_write'
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_send_request':
qcom-rpmh-regulator.c:(.text+0x2f2): undefined reference to `rpmh_write'
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_vrm_get_voltage_sel':
>> qcom-rpmh-regulator.c:(.text+0x274): undefined reference to `rpmh_write_async'
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_send_request':
qcom-rpmh-regulator.c:(.text+0x2fc): undefined reference to `rpmh_write_async'
Which is due to REGULATOR_QCOM_RPMH depending on
QCOM_RPMH || COMPILE_TEST. The problem is that QOM_RPMH can now
be a module, which in that case requires REGULATOR_QCOM_RPMH=m
to build.
However, if COMPILE_TEST is enabled, REGULATOR_QCOM_RPMH can be
set to =y while QCOM_RPMH=m which will cause build failures.
The fix here is to add (QCOM_RPMH=n && COMPILE_TEST) to the
dependency.
Feedback would be appreciated!
Cc: Todd Kjos <tkjos@google.com>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20201123222359.103822-1-john.stultz@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a simple regulator based on SCMI Voltage Domain Protocol.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
----
v6 --> v7
- add proper blank lines between semantic blocks
- fix return value on error path of scmi_reg_is_enabled()
- use generic Failure message on err path of info_get()
- fix comment containing apostrophe
v3 --> v4
- using of_match_full_name core regulator flag
- avoid coccinelle falde complaints about pointer-sized allocations
v2 --> v3
- remove multiple linear mappings support
- removed duplicated voltage name printout
- added a few comments
- simplified return path in scmi_reg_set_voltage_sel()
v1 --> v2
- removed duplicate regulator naming
- removed redundant .get/set_voltage ops: only _sel variants implemented
- removed condexpr on fail path to increase readability
v0 --> v1
- fixed init_data constraint parsing
- fixes for v5.8 (linear_range.h)
- fixed commit message content and subject line format
- factored out SCMI core specific changes to distinct patch
- reworked Kconfig and Makefile to keep proper alphabetic order
- fixed SPDX comment style
- removed unneeded inline functions
- reworked conditionals for legibility
- fixed some return paths to properly report SCMI original errors codes
- added some more descriptive error messages when fw returns invalid ranges
- removed unneeded explicit devm_regulator_unregister from .remove()
Link: https://lore.kernel.org/r/20201123202336.46701-4-cristian.marussi@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
this series introduces the support for the new SCMI Voltage Domain Protocol
defined by the upcoming SCMIv3.0 specification, whose BETA release is
available at [1].
Afterwards, a new generic SCMI Regulator driver is developed on top of the
new SCMI VD Protocol.
In V4 Patch 3/5 introduced a needed fix in Regulator framework to cope with
generic named nodes.
The series is currently based on for-next/scmi [2] on top of:
commit b141fca08207 ("firmware: arm_scmi: Fix missing destroy_workqueue()")
Any feedback welcome,
Thanks,
Cristian
---
v5 --> v6
- reordered dt bindings patch
- removed single field struct
- reviewed args to scmi_init_voltage_levels()
- allocating scmi_voltage_info_array contiguously
v4 --> v5
- rebased
- VD Protocol
- removed inline
- moved segmented intervals defines
- fixed some macros complaints by checkpatch
v3 --> v4
- DT bindings
- using generic node names
- listing explicitly subset of supported regulators bindings
- SCMI Regulator
- using of_match_full_name core regulator flag
- avoid coccinelle false flag complaints
- VD Protocol
- avoid coccinelle false flag complaints
- avoiding fixed size typing
v2 --> v3
- DT bindings
- avoid awkard examples based on _cpu/_gpu regulators
- SCMI Regulator
- remove multiple linear mappings support
- removed duplicated voltage name printout
- added a few comments
- simplified return path in scmi_reg_set_voltage_sel()
- VD Protocol
- restrict segmented voltage domain descriptors to one triplet
- removed unneeded inline
- free allocated resources for invalid voltage domain
- added __must_check to info_get voltage operations
- added a few comments
- removed fixed size typing from struct voltage_info
v1 --> v2
- rebased on for-next/scmi v5.10
- DT bindings
- removed any reference to negative voltages
- SCMI Regulator
- removed duplicate regulator naming
- removed redundant .get/set_voltage ops: only _sel variants implemented
- removed condexpr on fail path to increase readability
- VD Protocol
- fix voltage levels query loop to reload full cmd description
between iterations as reported by Etienne Carriere
- ensure transport rx buffer is properly sized calli scmi_reset_rx_to_maxsz
between transfers
[1]:https://developer.arm.com/documentation/den0056/c/
[2]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi
Cristian Marussi (5):
firmware: arm_scmi: Add Voltage Domain Support
firmware: arm_scmi: add SCMI Voltage Domain devname
regulator: core: add of_match_full_name boolean flag
dt-bindings: arm: add support for SCMI Regulators
regulator: add SCMI driver
.../devicetree/bindings/arm/arm,scmi.txt | 43 ++
drivers/firmware/arm_scmi/Makefile | 2 +-
drivers/firmware/arm_scmi/common.h | 1 +
drivers/firmware/arm_scmi/driver.c | 3 +
drivers/firmware/arm_scmi/voltage.c | 380 ++++++++++++++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/of_regulator.c | 8 +-
drivers/regulator/scmi-regulator.c | 409 ++++++++++++++++++
include/linux/regulator/driver.h | 3 +
include/linux/scmi_protocol.h | 64 +++
11 files changed, 920 insertions(+), 3 deletions(-)
create mode 100644 drivers/firmware/arm_scmi/voltage.c
create mode 100644 drivers/regulator/scmi-regulator.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
During regulators registration, if .of_match and .regulators_node are
defined as non-null strings in struct regulator_desc the core searches the
DT subtree rooted at .regulators_node trying to match, at first, .of_match
against the 'regulator-compatible' property and, then, falling back to use
the name of the node itself to determine a good match.
Property 'regulator-compatible', though, is now deprecated and falling back
to match against the node name, works fine only as long as the involved
nodes are named in an unique way across the searched subtree; if that's not
the case, like when using <common-name>@<unit> style naming for properties
indexed via 'reg' property (as advised by the standard), the above matching
mechanism based on the simple common name will lead to multiple matches and
the only viable alternative would be to properly define the now deprecated
'regulator-compatible' as the node full name, i.e. <common-name>@<unit>.
In order to address this case without using such deprecated binding, define
a new boolean flag .of_match_full_name in struct regulator_desc to force
the core to match against the node full-name instead of the plain name.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20201119191051.46363-4-cristian.marussi@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
At the start of driver initialization, we do not know what bias
setting the bootloader has configured the system for and we only know
for certain the very first time we do a transition.
However, since the initial value of the comparison index is -EINVAL,
this negative value results in an array out of bound access on the
very first transition.
Since we don't know what the setting is, we just set the bias
configuration as there is nothing to compare against. This prevents
the array out of bound access.
NOTE: Even though we could use a more relaxed check of "< 0" the only
valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+.
Fixes: 40b1936efe ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver")
Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
This series adds support for ramp delay on mcp16502. It also adds
some cleanup on mcp16502.
Apart from that patches 1/6 fixes the selector validation in case
the regulator::desc::linear_min_sel is not zero.
Thank you,
Claudiu Beznea
Changes in v3:
- fix compilation error in patch 5/6
Reported-by: kernel test robot <lkp@intel.com>
Changes in v2:
- rebase on top of regulator/for-next
- checked 1/6 and 3/6 applies on top of regulator/for-5.10
Claudiu Beznea (6):
regulator: core: validate selector against linear_min_sel
regulator: core: do not continue if selector match
regulator: mcp16502: add linear_min_sel
regulator: mcp16502: adapt for get/set on other registers
regulator: mcp16502: add support for ramp delay
regulator: mcp16502: remove void documentation of struct mcp16502
drivers/regulator/core.c | 12 +++-
drivers/regulator/helpers.c | 3 +-
drivers/regulator/mcp16502.c | 135 ++++++++++++++++++++++++++++++++++++-------
3 files changed, 127 insertions(+), 23 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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>
MCP16502 have multiple registers for each regulator (as described
in enum mcp16502_reg). Adapt the code to be able to get/set all these
registers. This is necessary for the following commits.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-5-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: aea6cb9970 ("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>
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: aea6cb9970 ("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>
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: aea6cb9970 ("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>
Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200
variants.
When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or
pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops
instead of the newly introduced and correct pfuze3000_sw_regulator_ops.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Fixes: 6f1cf5257a ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201110174113.2066534-1-sean@geanix.com
Signed-off-by: Mark Brown <broonie@kernel.org>
RFC for adding a support for typical voltage scaling connection
In few occasions there has been a need to scale the voltage output
from bucks on BD71837. Usually this is done when buck8 is used to
power specific GPU which can utilize voltages down to 0.7V. As lowest
the buck8 on BD71837 can go is 0.8V, and external connection is used to
scale the voltages.
The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the
feedback pin using suitable voltage/resistors.
|---------------|
| buck 8 |-------+----->Vout
| | |
|---------------| |
| |
| |
+-------+--R2----+
|
R1
|
V FB-pull-up
This will scale the voltage as follows:
- Vout_o = Vo - (Vpu - Vo)*R2/R1
- Linear_step = step_orig*(R1+R2)/R1
where:
Vout_o is adjusted voltage output at vsel reg value 0
Vo is original voltage output at vsel reg value 0
Vpu is the pull-up voltage V FB-pull-up in the picture
R1 and R2 are resistor values.
>From HW point of view this does not need to be limited to buck 8. This
connection can be used to adjust output from any of the bucks on
BD71837/47/50.
As this seems to be a 'de-facto' way to scale the voltages on BD71837 it
might be a good idea to support computing the new voltage ranges for
bucks based on the V-pull-up and resistor R1/R2 values given from
device-tree. This allows describing the external HW connection using DT
to correctly scale the voltages.
This RFC uses "rohm,feedback-pull-up-r1-ohms" and
"rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but
these names (without the picture) might not be too descriptive. I am
grateful for all suggestions as better and more descriptive names.
This patch series is an RFC because this connection feels somewhat
"hacky". OTOH - when hack becomes widely used, it is less of an hack and
more of a standard - and occasionally supporting HW hacks using SW may
benefit us all, right? :)
The other thing some projects do is allowing the change of BD71837 buck8
voltages when buck8 is enabled. This however will introduce voltage
spikes as buck8 was not originally designed for this. The specific HW
platform must be evaluated to be able to tolerate these spikes. Thus
this patch series does not support buck8 voltage changes when buck8 is
enabled. I wonder if this should be allowed per some config option(?) I
don't want to help people frying their boards... Opinions? Is there
suggested way of allowing this type of features at own risk? Config or
even Some #ifdef which is not listed in Kconfig? Device-tree property?
If you have (good) suggestions I could add the optional (non default)
DVS support for non DVS bucks on BD71837.
Matti Vaittinen (3):
dt-bindings: regulator: BD71837 support commonly used feedback
connection
dt-bindings: regulator: BD71847 support commonly used feedback
connection
regulator: bd718x7: Support external connection to scale voltages
.../regulator/rohm,bd71837-regulator.yaml | 48 +++++
.../regulator/rohm,bd71847-regulator.yaml | 49 ++++++
drivers/regulator/bd718x7-regulator.c | 164 +++++++++++++++++-
3 files changed, 254 insertions(+), 7 deletions(-)
base-commit: 3cea11cd5e
--
2.21.3
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Setups where regulator (especially the buck8) output voltage is scaled
by adding external connection where some other regulator output is
connected to feedback-pin (over suitable resistors) is getting popular
amongst users of BD71837. This allows for example scaling down the
buck8 voltages to suit lover GPU voltages for projects where buck8 is
(ab)used to supply power for GPU. As a note - some setups do allow DVS
for buck8. This do produce voltage spikes and the HW must be evaluated
to be able to survive them. Thus this commit still keep the DVS disabled
for non DVS bucks by default. Let's not help you burn your proto board.
Allow describing this external connection from DT and scale the
voltages accordingly. This is what the connection should look like:
|------------|
| buck 8 |-------+----->Vout
| | |
|------------| |
| FB pin |
| |
+-------+--R2---+
|
R1
|
V FB-pull-up
Here the buck output is sifted according to formula:
Vout_o = Vo - (Vpu - Vo)*R2/R1
Linear_step = step_orig*(R1+R2)/R1
where:
Vout_o is adjusted voltage output at vsel reg value 0
Vo is original voltage output at vsel reg value 0
Vpu is the pull-up voltage V FB-pull-up in the picture
R1 and R2 are resistor values.
Bring support for specifying the Vpu, R1 and R2 from device tree and
scale voltages if they are given.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/89b2be87074f307a8823f15f34e1f662023cbf36.1604994184.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Add support for the Dialog Semiconductor DA9121, a single-channel
dual-phase buck converter controlled via I2C.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20201103100021.19603-3-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: aea6cb9970 ("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>
On SM8250 MDSS_GDSC (and the rest of display clock controller) is
supplied power by MMCX power domain. Handle this link in GDSC code by
binding the power domain in dts file.
This patchset depends on [1]
Changes since v1:
- Define fixed-regulator-domain regulator using power domain
performance state for enabling/disabling.
- Rework to use new fixed regulator type (fixed-regulator-domain)
instead of controlling power domain directly from gdsc code.
Changes since RFC:
- Fix naming of gdsc_supply_on/gdsc_supply_off functions
- Fix detaching of solo gdsc's power domain in error handling code
- Drop the dts patch, as respective display nodes are still not
submitted to the mailing list.
[1]
https://lore.kernel.org/linux-arm-msm/20200927190653.13876-1-jonathan@marek.ca/
Don't populate const array lp872x_num_regulators on the stack but
instead make it static. Makes the object code smaller by 29 bytes.
Before:
text data bss dec hex filename
18441 4624 64 23129 5a59 drivers/regulator/lp872x.o
After:
text data bss dec hex filename
18316 4720 64 23100 5a3c drivers/regulator/lp872x.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201016222235.686981-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
The PM8953 is commonly used on board with MSM8953 SoCs or its variants:
APQ8053, SDM(SDA)450 and SDM(SDA)632.
It provides 7 SMPS and 23 LDO regulators.
Signed-off-by: Vladimir Lypak <junak.pub@gmail.com>
Link: https://lore.kernel.org/r/20201004083413.324351-1-junak.pub@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
AngeloGioacchino Del Regno <kholk11@gmail.com>:
From: AngeloGioacchino Del Regno <kholk11@gmail.com>
This patch series enables support for the regulators as found in
the PM660 and PM660L PMICs.
While at it, and to make them work, along with other regulators
for other qcom PMICs, enlarge the maximum property name length in
the regulator core, so that we're able to correctly parse the
supply parents, which have got very long names (details in patch 1/5).
This patch series has been tested against the following devices:
- Sony Xperia XA2 Ultra (SDM630 Nile Discovery)
- Sony Xperia 10 (SDM630 Ganges Kirin)
- Sony Xperia 10 Plus (SDM636 Ganges Mermaid)
AngeloGioacchino Del Regno (7):
regulator: core: Enlarge max OF property name length to 64 chars
regulator: qcom_spmi: Add support for new regulator types
regulator: qcom_spmi: Add PM660/PM660L regulators
regulator: dt-bindings: Document the PM660/660L SPMI PMIC entries
regulator: qcom_smd: Add PM660/PM660L regulator support
mfd: qcom-spmi-pmic: Add support for PM660/PM660L
regulator: dt-bindings: Document the PM660/PM660L PMICs entries
.../regulator/qcom,smd-rpm-regulator.yaml | 7 ++
.../regulator/qcom,spmi-regulator.txt | 31 +++++
drivers/mfd/qcom-spmi-pmic.c | 4 +
drivers/regulator/core.c | 4 +-
drivers/regulator/qcom_smd-regulator.c | 113 ++++++++++++++++++
drivers/regulator/qcom_spmi-regulator.c | 107 +++++++++++++++++
include/linux/soc/qcom/smd-rpm.h | 4 +
7 files changed, 268 insertions(+), 2 deletions(-)
--
2.28.0
The only usage of qcom_labibb_ops is to assign it to the ops field in
the regulator_desc struct, which is a const pointer. The only usage of
pmi8998_lab_desc and pmi8998_ibb_desc is to assign their address to the
desc field in the labibb_regulator_data struct which can be made const,
since it is only copied into the desc field in the
labbibb_regulator_data struct. This struct is modified, but that's a
copy of the static one. 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/20200930162602.18583-1-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM660 and PM660L are a very very common PMIC combo, found on
boards using the SDM630, SDM636, SDM660 (and SDA variants) SoC.
PM660 provides 6 SMPS and 19 LDOs (of which one is unaccesible),
while PM660L provides 5 SMPS (of which S3 and S4 are combined),
10 LDOs and a Buck-or-Boost (BoB) regulator.
The PM660L IC also provides other regulators that are very
specialized (for example, for the display) and will be managed
in the other appropriate drivers (for example, labibb).
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-6-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM660 PMIC is very often paired with the PM660L option on
SDM630/663/660 (and SDA variants) boards.
The PM660 has 11 "660" LDOs (2 NMOS, 9 PMOS) and 7 HT LDOs (4 NMOS,
3 PMOS) and a quirk: the L4 regulator is unaccessible or does not
exist on the PMIC.
The PM660L has 8 "660" LDOs (1 NMOS, 7 PMOS) and 2 HT NMOS LDOs.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-4-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit adds the support for some regulator types that are
missing in this driver, such as the ht nmos-ldo, ht-lv nmos-ldo
and new gen n/pmos-ldo, all belonging to the FTSMPS426 register
layout.
This is done in preparation for adding support for the PM660 and
PM660L PMICs.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-3-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
1. Add vendor suffix to all proprietary properties.
2. Fix typo.
3. Change lsw to normal property, not pattern property.
4. Due to item 1, modify source code for property parsing.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1601460480-4259-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Three simple patches to aid in debugging regulators.
Michał Mirosław (3):
regulator: print state at boot
regulator: print symbolic errors in kernel messages
regulator: resolve supply after creating regulator
drivers/regulator/core.c | 124 ++++++++++++++++++++++-----------------
1 file changed, 69 insertions(+), 55 deletions(-)
--
2.20.1
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: 45389c4752 ("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>
A single fix for incorrect specification of some of the register fields
on axp20x devices which would break voltage setting on affected systems.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9uTFQTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0OEZB/9tRSg6gHVdp2OwAbWPzJQcHYYP4stQ
H3mPcsDJRmpVnHhUQe3qlUvG4QZ7bDhnHFYS1G7LFgEBNVhCwKtpnseaQMJaCaa+
t9LLWNtzltuo75995bBtPYcSQI6U0yUYbu7U7n+4vibh/pjqY3eNg4lLrWtVL/OC
FwkCEql5+ZTTg3OcRHzKlYe1UlOB0kSHNCjySiVytPrC0UH32gFCs/LSZxDR8lbo
a9x8Vi8brbcmpASoCY0d+c0hM6PWB/chNwVHGnoWYJ+xoJMVLzC8TN/mkUgG++9i
wnwXfbUd0EbLKuLrZto0qdx14n2nLp2YpeLJhTbsJaQ5C+FQGvv7D2v5
=Uvnh
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"A single fix for incorrect specification of some of the register
fields on axp20x devices which would break voltage setting on affected
systems"
* tag 'regulator-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: axp20x: fix LDO2/4 description
Currently we wrongly set the mask of value of LDO2/4 both to the mask of
LDO2, and the LDO4 voltage configuration is left untouched. This leads
to conflict when LDO2/4 are both in use.
Fix this issue by setting different vsel_mask to both regulators.
Fixes: db4a555f7c ("regulator: axp20x: use defines for masks")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.io
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver was using subsys_initcall() because in old times deferred
probe was not supported everywhere and specific ordering was needed.
Since probe deferral works fine and specific ordering is discouraged
(hides dependencies between drivers and couples their boot order), the
driver can be converted to regular module_platform_driver.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200921203616.19623-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile
tested to increase build coverage. This allows to build them on
configurations without I2C (as I2C is required by dependency - parent
MFD driver).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200920214107.6299-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Initial support for ROHM BD9576MUF and BD9573MUF PMICs.
These PMICs are primarily intended to be used to power the R-Car family
processors. BD9576MUF includes some additional safety features the
BD9573MUF does not have. This initial version of drivers does not
utilize these features and for now the SW behaviour is identical.
Please note that this version of drivers is only tested on BD9576MUF
but according to the data-sheets the relevant parts of registers should
be same so drivers should also work on BD9573MUF.
This patch series includes MFD, watchdog and regulator drivers with
basic functionality such as:
- Enabling and pinging the watchdog
- configuring watchog timeout / window from device-tree
- reading regulator states/voltages
- enabling/disabling VOUT1 (VD50) when control mode B is used.
This patch series does not bring interrupt support. BD9576MUF and BD9573MUF
are designed to keep the IRQ line low for whole duration of error
condition. IRQ can't be 'acked'. So proper IRQ support would require
some IRQ limiter implementation (delayed unmask?) in order to not hog
the CPU.
---
Matti Vaittinen (6):
dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs
dt_bindings: regulator: Add ROHM BD9576MUF and BD9573MUF PMICs
mfd: Support ROHM BD9576MUF and BD9573MUF
wdt: Support wdt on ROHM BD9576MUF and BD9573MUF
regulator: Support ROHM BD9576MUF and BD9573MUF
MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers
.../bindings/mfd/rohm,bd9576-pmic.yaml | 129 +++++++
.../regulator/rohm,bd9576-regulator.yaml | 33 ++
MAINTAINERS | 4 +
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/rohm-bd9576.c | 130 +++++++
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/bd9576-regulator.c | 337 ++++++++++++++++++
drivers/watchdog/Kconfig | 13 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bd9576_wdt.c | 295 +++++++++++++++
include/linux/mfd/rohm-bd957x.h | 61 ++++
include/linux/mfd/rohm-generic.h | 2 +
14 files changed, 1028 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml
create mode 100644 drivers/mfd/rohm-bd9576.c
create mode 100644 drivers/regulator/bd9576-regulator.c
create mode 100644 drivers/watchdog/bd9576_wdt.c
create mode 100644 include/linux/mfd/rohm-bd957x.h
base-commit: f4d51dffc6
--
2.21.0
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
The only usage of ti_abb_reg_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-6-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usages of these is to assign their address to 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.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-5-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of stw481x_vmmc_ops is to assign its address to the ops
field in the regulator_desc struct which is a const pointer.
The only usage of vmmc_regulator is to pass its address to
of_get_regulator_init_data() and devm_regulator_register(), both which
take const pointers.
Make both of 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-4-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
The only usage of dummy_initdata is to assign its address to the
init_data field of the regulator_config struct and the only usage
dummy_ops is to assign its address to the ops field in the
regulator_desc struct, both which are const pointers. 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-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The biggest set of fixes here is those from Michał Mirosław fixing some
locking issues with coupled regulators that are triggered in cases where
a coupled regulator is used by a device involved in fs_reclaim like eMMC
storage. These are relatively serious for the affected systems, though
the circumstances where they trigger are very rare.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9baDITHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0NAOCACGwc1Rxsr9cMDY5vQS7AHzfPVRdoQJ
Z9KIOQT9ER0hFHRNh1/t1n/p4DcK+3ke0MH/R/VndijvePJgHyL01Bsjq92iDiIy
b80nDJwRwLWWdvKAPG5JklVK8pL/6LxaC9eL8zK93Hm4fGkNJzBi7jF2++jep/tB
2jRM4Vrq8B0dkh/jPQMscl4Z66purIiyKLJjy1QFjXXq0/jkjZizURy+aofS3uJD
0vebim9OI7z0H4g6cflJrHUAuDraNmGCfGAyUMH7AESJlUGNRk7BzNYT51tLVYqG
ithNZDh/AbWhGzntuUUKNlM4D8p26FNJmU51crh33kBH3va737dvc/BT
=3fwP
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"The biggest set of fixes here is those from Michał Mirosław fixing
some locking issues with coupled regulators that are triggered in
cases where a coupled regulator is used by a device involved in
fs_reclaim like eMMC storage.
These are relatively serious for the affected systems, though the
circumstances where they trigger are very rare"
* tag 'regulator-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: pwm: Fix machine constraints application
regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive()
regulator: remove superfluous lock in regulator_resolve_coupling()
regulator: cleanup regulator_ena_gpio_free()
regulator: plug of_node leak in regulator_register()'s error path
regulator: push allocation in set_consumer_device_supply() out of lock
regulator: push allocations in create_regulator() outside of lock
regulator: push allocation in regulator_ena_gpio_request() out of lock
regulator: push allocation in regulator_init_coupling() outside of lock
regulator: fix spelling mistake "Cant" -> "Can't"
regulator: cros-ec-regulator: Add NULL test for devm_kmemdup call
Fix sparse warnings:
drivers/regulator/bd718x7-regulator.c:576:28: warning: symbol 'bd71847_swcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:585:28: warning: symbol 'bd71847_hwcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:902:28: warning: symbol 'bd71837_swcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:913:28: warning: symbol 'bd71837_hwcontrol_ops' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-By: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20200910034240.37268-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This removes regulator_lock/unlock() calls around
regulator_notifier_call_chain() as they are redundant - drivers
already have to guarantee regulator_dev's existence during the call.
This should make reasoing about the lock easier, as this was the only
use outside regulator core code.
The only client that needed recursive locking from the notifier chain
was drivers/usb/host/ohci-da8xx.c, which responds to over-current
notification by calling regulator_disable().
Michał Mirosław (3):
regulator: don't require mutex for regulator_notifier_call_chain()
regulator: remove locking around regulator_notifier_call_chain()
regulator: unexport regulator_lock/unlock()
drivers/regulator/core.c | 11 +++--------
drivers/regulator/da9055-regulator.c | 2 --
drivers/regulator/da9062-regulator.c | 2 --
drivers/regulator/da9063-regulator.c | 2 --
drivers/regulator/da9210-regulator.c | 4 ----
drivers/regulator/da9211-regulator.c | 4 ----
drivers/regulator/lp8755.c | 6 ------
drivers/regulator/ltc3589.c | 10 ++--------
drivers/regulator/ltc3676.c | 10 ++--------
drivers/regulator/pv88060-regulator.c | 10 ++--------
drivers/regulator/pv88080-regulator.c | 10 ++--------
drivers/regulator/pv88090-regulator.c | 10 ++--------
drivers/regulator/slg51000-regulator.c | 4 ----
drivers/regulator/stpmic1_regulator.c | 4 ----
drivers/regulator/wm831x-dcdc.c | 4 ----
drivers/regulator/wm831x-isink.c | 2 --
drivers/regulator/wm831x-ldo.c | 2 --
drivers/regulator/wm8350-regulator.c | 2 --
include/linux/regulator/driver.h | 3 ---
19 files changed, 13 insertions(+), 89 deletions(-)
--
2.20.1
In the case of an unrecognised mini-card the Lochnagar will not
initialise the VDDCORE voltage register leading to a value outside of the
current range. Add an additional range to cover these values, initially
this wasn't done since they are duplicates of the existing minimum
value.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200904122506.28017-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_notifier_call_chain() doesn't need rdev lock and rdev's
existence is assumed in the code anyway. Remove the locks from drivers.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/42393f66dcc4d80dcd9797be45216b4035aa96cb.1597032945.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Since 3801b86aa4 ("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>
The BD718(37/47/50) regulator enable states can be controlled
either by SW or by PMIC internal state machine. The bd718x7
driver has not supported leaving the regulators under HW state
machine control (except for cases where this is required to
avoid boot-up problems due to critical regulators being turned
OFF at reset when SNVS used as reset state).
On some systems this is undesirable as there now are setups where
mixture of SW and HW state machine controlled regulators is needed.
Specifically, some SoCs signal SUSPEND state change to PMIC via
STBY_REQ line. Now there are setups that expect certain regulators
then to be disabled (by PMIC state machine) while other regulators
should stay enabled (regardless of HW state => SW control required).
Add support for a new device-tree property
"rohm,no-regulator-enable-control" which can be used to leave
regulator(s) under HW state machine control.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/6ebba33dd08f2dcc9f1137bbff4d2dc905278a5a.1599029335.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the zero duty cycle doesn't correspond to any voltage in the voltage
table, the PWM regulator returns an -EINVAL from get_voltage_sel() which
results in the core erroring out with a "failed to get the current
voltage" and ending up not applying the machine constraints.
Instead, return -ENOTRECOVERABLE which makes the core set the voltage
since it's at an unknown value.
For example, with this device tree:
fooregulator {
compatible = "pwm-regulator";
pwms = <&foopwm 0 100000>;
regulator-min-microvolt = <2250000>;
regulator-max-microvolt = <2250000>;
regulator-name = "fooregulator";
regulator-always-on;
regulator-boot-on;
voltage-table = <2250000 30>;
};
Before this patch:
fooregulator: failed to get the current voltage(-22)
After this patch:
fooregulator: Setting 2250000-2250000uV
fooregulator: 2250 mV
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of these is to assign their address to 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.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-9-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps65912_ops_dcdc and tps65912_ops_ldo is to assign
their address to 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.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-8-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of these are to assign their address to 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.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-7-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usages of these are to assign their address to 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.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-6-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of reg_ops and switch_ops is to assign their addresses to
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.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-5-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps62360_dcdc_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-4-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps6105x_regulator_ops is to assign its address to the
ops field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-3-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps51632_dcdc_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The recent commit 7d8196641e ("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: f8702f9e4a ("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>
As Rob suggested, use the "mps,switch-frequency-hz" instead of the
"mps,switch-frequency" for switch frequency. Fortunately, the switch
frequency support isn't released, so we can modify it now without
any concern.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200824102402.4047fa5f@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The following build warning is seen after commit 8bdaa43808 ("regulator:
dbx500: no need to check return value of debugfs_create functions"):
drivers/regulator/dbx500-prcmu.c:144:1: warning: label 'exit_no_debugfs' defined but not used [-Wunused-label]
Remove the unused label and its associated error message.
Fixes: 8bdaa43808 ("regulator: dbx500: no need to check return value of debugfs_create functions")
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200821144823.13404-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/tps65023-regulator.c:319:34: warning: ‘tps65023_of_match’ defined but not used [-Wunused-const-variable=]
319 | static const struct of_device_id tps65023_of_match[] = {
| ^~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821112009.58ee8511@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/qcom-rpmh-regulator.c:970:34: warning: ‘rpmh_regulator_match_table’ defined but not used [-Wunused-const-variable=]
970 | static const struct of_device_id rpmh_regulator_match_table[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111913.1096f7cc@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/sy8106a-regulator.c:126:34: warning: ‘sy8106a_i2c_of_match’ defined but not used [-Wunused-const-variable=]
126 | static const struct of_device_id sy8106a_i2c_of_match[] = {
| ^~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111820.5c6ddb04@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/stm32-pwr.c:169:34: warning: ‘stm32_pwr_of_match’ defined but not used [-Wunused-const-variable=]
169 | static const struct of_device_id stm32_pwr_of_match[] = {
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111726.38e0e746@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/pwm-regulator.c:393:34: warning: ‘pwm_of_match’ defined but not used [-Wunused-const-variable=]
393 | static const struct of_device_id pwm_of_match[] = {
| ^~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111658.59a7218b@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/max77826-regulator.c:277:34: warning: ‘max77826_of_match’ defined but not used [-Wunused-const-variable=]
277 | static const struct of_device_id max77826_of_match[] = {
| ^~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111631.4e799c86@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/max1586.c:204:34: warning: ‘max1586_of_match’ defined but not used [-Wunused-const-variable=]
204 | static const struct of_device_id max1586_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111601.26243417@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3676.c:371:34: warning: ‘ltc3676_of_match’ defined but not used [-Wunused-const-variable=]
371 | static const struct of_device_id ltc3676_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111517.59d7b8c8@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3589.c:460:34: warning: ‘ltc3589_of_match’ defined but not used [-Wunused-const-variable=]
460 | static const struct of_device_id ltc3589_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111449.7cf580f2@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Fix below warning when CONFIG_OF=n:
drivers/regulator/fan53555.c:439:34: warning: ‘fan53555_dt_ids’ defined but not used [-Wunused-const-variable=]
439 | static const struct of_device_id fan53555_dt_ids[] = {
| ^~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111324.430fe1da@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/da9210-regulator.c:128:34: warning: ‘da9210_dt_ids’ defined but not used [-Wunused-const-variable=]
128 | static const struct of_device_id da9210_dt_ids[] = {
| ^~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200821111235.14473a88@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/88pg86x.c:87:34: warning: ‘pg86x_dt_ids’ defined but not used [-Wunused-const-variable=]
87 | static const struct of_device_id pg86x_dt_ids [] = {
| ^~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111210.0a0bed94@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20200818133701.462958-1-gregkh@linuxfoundation.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This allows the regulator to be found by devm_regulator_get().
Fixes: 4fe66d5a62 ("regulator: Add support for QCOM PMIC VBUS booster")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20200818162508.5246-1-jonathan@marek.ca
Signed-off-by: Mark Brown <broonie@kernel.org>
Jisheng Zhang <Jisheng.Zhang@synaptics.com>:
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
This is to improve the mp886x regulator driver support.
patch1 implments .set_ramp_delay
patch2 and patch3 support the switch freq setting
patch4 converts dt binding to json-schema
Since v2:
- put any schema conversions at the end of the series as Mark
suggested.
Jisheng Zhang (4):
regulator: mp886x: implement set_ramp_delay
dt-bindings: regulator: mp886x: support mps,switch-frequency
regulator: mp886x: support setting switch freq
dt-bindings: regulator: Convert mp886x to json-schema
.../devicetree/bindings/regulator/mp886x.txt | 27 -----
.../bindings/regulator/mps,mp886x.yaml | 58 ++++++++++
drivers/regulator/mp886x.c | 109 +++++++++++++++++-
3 files changed, 164 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/mp886x.txt
create mode 100644 Documentation/devicetree/bindings/regulator/mps,mp886x.yaml
--
2.28.0.rc1
For systems that have eg. eMMC storage using voltage regulator, memory
reclaim path might call back into regulator subsystem. This means we
have to make sure no allocations happen with a regulator or regulator
list locked.
After this series I see no more lockdep complaints on my test system,
but please review and test further.
First four patches move allocations out of locked regions, next three
came as a drive-by cleanups.
---
v2: fix bug in patch #4 spotted by kernel test robot
reworded commit #7 description
Michał Mirosław (7):
regulator: push allocation in regulator_init_coupling() outside of
lock
regulator: push allocation in regulator_ena_gpio_request() out of lock
regulator: push allocations in create_regulator() outside of lock
regulator: push allocation in set_consumer_device_supply() out of lock
regulator: plug of_node leak in regulator_register()'s error path
regulator: cleanup regulator_ena_gpio_free()
regulator: remove superfluous lock in regulator_resolve_coupling()
drivers/regulator/core.c | 164 +++++++++++++++++++++------------------
1 file changed, 87 insertions(+), 77 deletions(-)
--
2.20.1
By checking data->pin_ctrl_enable / data->pin_ctrl_hpm flags first, then
use switch-case to improve readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200801054820.134859-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This regulator/backlight driver handles the ATTINY88 present on the
RPi 7" touchscreen panel and exposes the power/backlight interfaces.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Mark Brown <broonie@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
To: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/r/20200809105938.6388-2-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Fixing W=1 build warning when no support for device tree is there.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200810095753.59ce9f75@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regmap_cache to reduce wakeups events of interrupt if regulator is
accessed frequently. This results in saving more power.
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200812133101.2513317-1-hsinyi@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds support for the RT4801 DSV. It has two regulators (DSVP/DSVN) with
an I2C interface. DSVP/DSVN can provide the display panel module for the
positive/negative voltage range from (+/-)4V to (+/-)6V.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1597461262-25878-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: f9503385b1 ("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>
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>
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: 9177514ce3 ("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>
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: f8702f9e4a ("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>
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: 541d052d72 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9e4a ("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>
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: d8ca7d184b ("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>
Both MP8867 and MP8869 support different switch frequency.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200729131023.77cc1dd2@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement the .set_ramp_delay for MP8867 and MP8869. MP8867 and MP8869
could share the implementation, the only difference is the slew_rates
array.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200729130913.3ac38b32@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
The desc->name field is allocated with devm_kstrdup, but is also kfreed
on the error path, causing it to be double freed. Remove the kfree on
the error path.
Fixes: 8d9f8d57e0 ("regulator: Add driver for cros-ec-regulator")
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200728091909.2009771-1-pihsun@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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: a3cde9534e ("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>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200719200623.61524-1-grandmaster@al2klimov.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Consider the following example:
- regulator-X is provided by device-X.
- regulator-X is a supplier to device-A, device-B and device-C.
- device-A is off/inactive from boot.
- device-B and device-C are left on/active by the bootloader
- regulator-X is left on boot by the bootloader at 2000 mV to supply
device-B and device-C.
Example boot sequence 1:
1. device-X is probed successfully.
2. device-A is probed by driver-A
a. driver-A gets regulator-X
b. driver-A votes on regulator-X
c. driver-A initializes device-A
d. driver-A votes off regulator-X
e. regulator-X is turned off.
3. System crashes or device-B and device-C become unreliable because
regulator-X was turned off without following the proper quiescing
steps for device-B and device-C.
Example boot sequence 2:
1. device-X is probed successfully.
2. device-B is probed by driver-B
a. driver-B gets regulator-X
b. driver-B votes on regulator-X
c. driver-B lowers device-B performance point.
d. driver-B lowers voltage vote to 1000 mV.
e. regulator-X voltage is lowered to 1000 mV.
3. System crashes or device-C becomes unreliable because regulator-X
voltage was lowered to 1000 mV when device-C still needed it at 2000 mV
This patch series makes sure these examples are handled correctly and
system crash or device instability is avoided and the system remains
usable.
More details provided in the commit texts.
v2->v3:
Patch 2/4 - No functional change. Simple refactor.
Patch 3/4
- Was Patch 2/2 in v2.
- Rewrote commit text to hopefully address all previous points.
- Renamed variable/functions. Hope it's clearer.
- Added more comments.
- Added logging
- Fixed timeout functionality.
- Handle exclusive consumers properly
- Handle coupled regulators properly
Patch 4/4 - Prevents voltage from going too low during boot.
v1->v2:
Patch 1/2
- New patch
Patch 2/2
- This was the only patch in v1
- Made the late_initcall_sync timeout a commandline param
- If timeout is set, we also give up waiting for all consumers after
the timeout expires.
- Made every regulator driver add sync_state() support
Saravana Kannan (4):
driver core: Add dev_set_drv_sync_state()
regulator: core: Add destroy_regulator()
regulator: core: Add basic enable/disable support for sync_state()
callbacks
regulator: core: Add voltage support for sync_state() callbacks
drivers/regulator/core.c | 200 ++++++++++++++++++++++++++++---
include/linux/device.h | 12 ++
include/linux/regulator/driver.h | 2 +
3 files changed, 198 insertions(+), 16 deletions(-)
--
2.28.0.rc0.105.gf9edc3c819-goog
When requesting the enable GPIO, the driver should do so with the
correct output level matching some expected state. This is especially
important if the regulator is a critical one, such as a supply for
the boot CPU. This is currently done by checking for the enable-at-boot
property, but this is not documented in the device tree binding, nor
does it match the common regulator properties.
Honor the common regulator-boot-on property by checking the boot_on
constraint setting within the DT probe path. This is the same as what
is done in the fixed regulator driver.
Also add a comment stating that the enable-at-boot property should not
be used.
Fixes: 006694d099 ("regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200720132809.26908-1-wens@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
[sumits: reworked the driver design as per upstream review]
Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20200622124110.20971-5-sumit.semwal@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
It is never modified, so make it const to allow the compiler to put it
in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Pi-Hsun Shih <pihsun@chromium.org>
Link: https://lore.kernel.org/r/20200711114409.9911-1-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Line up descriptions, start description with a lower-case character and
omit old definitions such as quoting the old argument "consumer".
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200708124832.3441649-4-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Kerneldoc validation gets confused if syntax isn't "@.*: ".
Adding the missing colons squashes the following W=1 warnings:
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Link: https://lore.kernel.org/r/20200708124832.3441649-3-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Provide descriptions for some missing function args and
rename others to match the names used.
Fixes the following W=1 warning(s):
drivers/regulator/devres.c:187: warning: Function parameter or member 'dev' not described in 'devm_regulator_register'
drivers/regulator/devres.c:226: warning: Function parameter or member 'dev' not described in 'devm_regulator_unregister'
drivers/regulator/devres.c:226: warning: Function parameter or member 'rdev' not described in 'devm_regulator_unregister'
drivers/regulator/devres.c:226: warning: Excess function parameter 'regulator' description in 'devm_regulator_unregister'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200708124832.3441649-2-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for COMPILE_TEST while fixing a warning when
no support for device tree is there.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/1c437154873ace65ff738a0ebca511308f1cecc1.camel@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for ON Semiconductor FAN53880 regulator.
The FAN53880 is an I2C porgrammable power management IC (PMIC)
that contains a BUCK (step-down converter), four LDOs (low dropouts)
and one BOOST (step-up converter). It is designed for mobile power
applications.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/20200702210846.31659-2-chf.fritz@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patchset adds support for being able to change regulator modes for
the mt6397 regulator. This is needed to allow the voltage scaling
support in the MT8173 SoC to be used on the elm (Acer Chromebook R13)
and hana (several Lenovo Chromebooks) devices.
Without a of_map_mode implementation, the regulator-allowed-modes
devicetree field is skipped, and attempting to change the regulator mode
results in an error:
[ 1.439165] vpca15: mode operation not allowed
Changes in v2:
- Introduce constants in dt-bindings
- Improve conditional readability
Anand K Mistry (4):
regulator: mt6397: Move buck modes into header file
dt-bindings: regulator: mt6397: Document valid modes
regulator: mt6397: Implement of_map_mode
arm64: dts: mediatek: Update allowed mt6397 regulator modes for elm
boards
.../bindings/regulator/mt6397-regulator.txt | 3 +++
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +++-
drivers/regulator/mt6397-regulator.c | 17 ++++++++++++++---
.../regulator/mediatek,mt6397-regulator.h | 15 +++++++++++++++
4 files changed, 35 insertions(+), 4 deletions(-)
create mode 100644 include/dt-bindings/regulator/mediatek,mt6397-regulator.h
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This patchset adds support for being able to change regulator modes for
the da9211 regulator. This is needed to allow the voltage scaling
support in the MT8173 SoC to be used in the elm (Acer Chromebook R13)
and hana (several Lenovo Chromebooks) devices.
Anand K Mistry (4):
regulator: da9211: Move buck modes into header file
dt-bindings: regulator: da9211: Document allowed modes
regulator: da9211: Implement of_map_mode
arm64: dts: mediatek: Update allowed regulator modes for elm boards
.../devicetree/bindings/regulator/da9211.txt | 4 +++
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 ++-
drivers/regulator/da9211-regulator.c | 30 +++++++++++++++----
.../regulator/dlg,da9211-regulator.h | 16 ++++++++++
4 files changed, 47 insertions(+), 7 deletions(-)
create mode 100644 include/dt-bindings/regulator/dlg,da9211-regulator.h
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The SY8827N from Silergy Corp is a single output DC/DC converter. The
voltage can be controlled via I2C.
Jisheng Zhang (2):
dt-bindings: regulator: add document bindings for sy8827n
regulator: add support for SY8827N regulator
.../bindings/regulator/silergy,sy8827n.yaml | 45 +++++
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/sy8827n.c | 185 ++++++++++++++++++
4 files changed, 238 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml
create mode 100644 drivers/regulator/sy8827n.c
--
2.27.0
Use the new .probe_new for mp886x. It does not use the const
struct i2c_device_id * argument, so convert it to utilise the
simplified i2c driver registration.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200702100200.1a4c65d1@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The null pointer check on regmap that checks for a dev_get_regmap failure
is currently returning -ENOENT if the regmap succeeded. Fix this by adding
in the missing ! operator.
Fixes: 4fe66d5a62 ("regulator: Add support for QCOM PMIC VBUS booster")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Dereference after null check")
Link: https://lore.kernel.org/r/20200702115659.38208-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SY8827N from Silergy Corp is a single output DC/DC converter. The
voltage can be controlled via I2C.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200702171438.20edc523@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Changes in v4:
- Modified qcom,pmic-typec binding to include the SS mux and the DRD remote
endpoint nodes underneath port@1, which is assigned to the SSUSB path
according to usb-connector
- Added usb-connector reference to the typec dt-binding
- Added tags to the usb type c and vbus nodes
- Removed "qcom" tags from type c and vbus nodes
- Modified Kconfig module name, and removed module alias from the typec driver
Changes in v3:
- Fix driver reference to match driver name in Kconfig for
qcom_usb_vbus-regulator.c
- Utilize regulator bitmap helpers for enable, disable and is enabled calls in
qcom_usb_vbus-regulator.c
- Use of_get_regulator_init_data() to initialize regulator init data, and to
set constraints in qcom_usb_vbus-regulator.c
- Remove the need for a local device structure in the vbus regulator driver
Changes in v2:
- Use devm_kzalloc() in qcom_pmic_typec_probe()
- Add checks to make sure return value of typec_find_port_power_role() is
valid
- Added a VBUS output regulator driver, which will be used by the PMIC USB
type c driver to enable/disable the source
- Added logic to control vbus source from the PMIC type c driver when
UFP/DFP is detected
- Added dt-binding for this new regulator driver
- Fixed Kconfig typec notation to match others
- Leave type C block disabled until enabled by a platform DTS
Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC. Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this. This
series adds the dt-binding, PMIC type C driver, and DTS nodes.
The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications. It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.
Wesley Cheng (6):
usb: typec: Add QCOM PMIC typec detection driver
dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
regulator: Add support for QCOM PMIC VBUS booster
dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster
.../regulator/qcom,usb-vbus-regulator.yaml | 41 +++
.../bindings/usb/qcom,pmic-typec.yaml | 113 +++++++
arch/arm64/boot/dts/qcom/pm8150b.dtsi | 13 +
arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom_usb_vbus-regulator.c | 97 ++++++
drivers/usb/typec/Kconfig | 12 +
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/qcom-pmic-typec.c | 275 ++++++++++++++++++
10 files changed, 567 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
create mode 100644 drivers/usb/typec/qcom-pmic-typec.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator of MP5496
controls the APSS and SDCC voltage scaling respectively. Add support
for the same.
changes since V1:
- Moved YAML conversion to the last as per Mark's comments
Kathiravan T (6):
dt-bindings: soc: qcom: Add IPQ6018 compatible
soc: qcom: smd-rpm: Add IPQ6018 compatible
dt-bindings: regulator: add MP5496 regulator compatible
regulator: qcom_smd: Add MP5496 regulators
dt-bindings: soc: qcom: convert the SMD-RPM document to YAML schema
dt-bindings: regulator: convert QCOM SMD-RPM regulator document to
YAML schema
.../bindings/regulator/qcom,smd-rpm-regulator.txt | 320 ---------------------
.../bindings/regulator/qcom,smd-rpm-regulator.yaml | 106 +++++++
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 62 ----
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 92 ++++++
drivers/regulator/qcom_smd-regulator.c | 34 +++
drivers/soc/qcom/smd-rpm.c | 1 +
6 files changed, 233 insertions(+), 382 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
This driver enables outputs by setting bit EN_BUCKn in the BUCKn_CTRL1
register. However, if bit EN_PIN_CTRLn in the same register is set, the
output is actually enabled only if EN_BUCKn is set AND an enable pin is
active. Since the driver does not touch EN_PIN_CTRLn, the choice is left to
the hardware, which in turn gets this bit from OTP memory, and in absence
of OTP data it uses a default value that is documented in the datasheet for
LP8752x, but not for LP8756x.
Thus the driver doesn't really "know" whether it is actually enabling the
output or not.
In order to make sure activation is always driver-controlled, just clear
the EN_PIN_CTRLn bit. Now all activation solely depend on the EN_BUCKn bit.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20200622204329.11147-2-luca@lucaceresoli.net
Signed-off-by: Mark Brown <broonie@kernel.org>
IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator controls the
APSS and SDCC voltage scaling respectively. Add support for the same.
Signed-off-by: Kathiravan T <kathirav@codeaurora.org>
Link: https://lore.kernel.org/r/1592889472-6843-5-git-send-email-kathirav@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
These are never modified, so make them const to allow the compiler to
put them in read-only memory.
Before:
text data bss dec hex filename
20362 2592 152 23106 5a42 drivers/regulator/qcom_spmi-regulator.o
After:
text data bss dec hex filename
21814 1140 152 23106 5a42 drivers/regulator/qcom_spmi-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200629194632.8147-3-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These are never modified, so make them const to allow the compiler to
put them in read-only memory.
Before:
text data bss dec hex filename
17485 500 8 17993 4649 drivers/regulator/qcom_rpm-regulator.o
After:
text data bss dec hex filename
17881 104 8 17993 4649 drivers/regulator/qcom_rpm-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200629194632.8147-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals. This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20200626185516.18018-5-wcheng@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This was an upstreaming error. Remove it as it's not to be used.
Fixes the following W=1 kernel build warning:
drivers/regulator/qcom_smd-regulator.c:477:36: warning: ‘pmi8994_boost’ defined but not used [-Wunused-const-variable=]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-10-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
W=1 kernel builds report a lack of descriptions for various
function arguments. In reality they are documented, but the
formatting was not as expected '@.*:'. Instead, some weird
arg identifiers were used.
This change fixes the following warnings:
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'dev' not described in 'wm8400_register_regulator'
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'reg' not described in 'wm8400_register_regulator'
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'initdata' not described in 'wm8400_register_regulator'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: patches@opensource.cirrus.com
Link: https://lore.kernel.org/r/20200626065738.93412-9-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'rid' is declared as unsigned int, so there is little point checking for <0.
Removing these checks fixes the following W=1 warnings:
drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_enable’:
drivers/regulator/tps65218-regulator.c:131:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
131 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
| ^
drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_disable’:
drivers/regulator/tps65218-regulator.c:144:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
144 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
| ^
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-8-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Until now the aforementioned return value has been ignored.
Previous and current calls to tps65217_reg_read() return
instantly when the value is not 0, so let's do that.
Fixes the following W=1 warning:
drivers/regulator/tps65217-regulator.c: In function ‘tps65217_regulator_probe’:
drivers/regulator/tps65217-regulator.c:227:9: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
227 | int i, ret;
| ^~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Russ Dill <Russ.Dill@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-7-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'rid' is declared as unsigned int, so there is little point checking for <0.
Removing these checks fixes the following W=1 warnings:
drivers/regulator/tps65217-regulator.c: In function ‘tps65217_pmic_set_suspend_enable’:
drivers/regulator/tps65217-regulator.c:127:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
127 | if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
| ^
drivers/regulator/tps65217-regulator.c: In function ‘tps65217_pmic_set_suspend_disable’:
drivers/regulator/tps65217-regulator.c:140:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
140 | if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
| ^
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Russ Dill <Russ.Dill@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-6-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In kerneldoc format, data structures have to start with 'struct'
else the kerneldoc tooling/parsers/validators get confused.
Fixes the following W=1 kernel build warning:
drivers/regulator/stpmic1_regulator.c:25: warning: cannot understand function prototype: 'struct stpmic1_regulator_cfg '
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Pascal Paillet <p.paillet@st.com>
Link: https://lore.kernel.org/r/20200626065738.93412-5-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This particular comment doesn't have anything to do with documenting
functions or data structures. Instead it is used as a section header.
Fixes W=1 warning:
drivers/regulator/pwm-regulator.c:55: warning: Function parameter or member 'rdev' not described in 'pwm_regulator_init_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200626065738.93412-4-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
W=1 kernel builds report a lack of descriptions for various
enum properties and function arguments. In reality they are
documented, but the formatting was not as expected '@.*:'.
Instead, some weird arg identifiers were used or none at all.
This change fixes the following warnings:
drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not described in enum 'rpmh_regulator_type'
drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'XOB' not described in enum 'rpmh_regulator_type'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'vreg' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'dev' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'node' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'pmic_id' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'pmic_rpmh_data' not described in 'rpmh_regulator_init_vreg'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-3-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
max8998_get_current_limit() is only used via the .get_current_limit,
so it doesn't need to be publicly supported, or to have its own
external prototype. Instead, we'll make it static.
Fixes the following W=1 warning:
drivers/regulator/max8998.c:418:5: warning: no previous prototype for ‘max8998_get_current_limit’ [-Wmissing-prototypes]
418 | int max8998_get_current_limit(struct regulator_dev *rdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200626065738.93412-2-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Nothing about this comment identifies it as a kerneldoc header.
It's missing all of it's function argument descriptions and the
correct function header.
Fixes the following W=1 warning(s):
drivers/regulator/max14577-regulator.c:166: warning: Function parameter or member 'max14577' not described in 'max14577_get_regma
drivers/regulator/max14577-regulator.c:166: warning: Function parameter or member 'reg_id' not described in 'max14577_get_regmap'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-11-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Nothing about this comment identifies it as a kerneldoc header.
They're missing all of their struct's property descriptions and
the correct 'struct *' header.
Fixes the following W=1 warning(s):
drivers/regulator/cpcap-regulator.c:99: warning: cannot understand function prototype: 'struct cpcap_regulator '
drivers/regulator/cpcap-regulator.c:337: warning: cannot understand function prototype: 'const struct cpcap_regulator omap4_regulators[] = '
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-9-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
It's okay to not check the return value that you're not conserned
about, however it is not okay to assign a variable and not check or
use the result.
Fixes W=1 warnings(s):
drivers/regulator/cpcap-regulator.c:172:13: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable]
172 | int error, ignore;
| ^~~~~~
drivers/regulator/cpcap-regulator.c: In function ‘cpcap_regulator_disable’:
drivers/regulator/cpcap-regulator.c:196:13: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable]
196 | int error, ignore;
| ^~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-8-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Kerneldoc expects function arguments to be in the format '@.*:'. If
this format is not followed the kerneldoc tooling/parsers/validators
get confused.
Fixes the following W=1 warning(s):
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'wm8350' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'lednum' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'dcdc' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'isink' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'pdata' not described in 'wm8350_register_led'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-7-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Used primarily for the AB8540 which lost support in early 2018.
It is now deemed safe to remove this legacy data structure.
Also fixes W=1 issue:
drivers/regulator/ab8500.c:88: warning: Function parameter or member 'expand_register' not described in 'ab8500_regulator_info'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-6-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There isn't any code present within the current kernel to
override this 'weak' function. Besides returning '0', which
is never checked anyway, the whole function appears to be
superfluous.
Consequently fixes W=1 warning:
drivers/regulator/dbx500-prcmu.c:113:27: warning: no previous prototype for ‘dbx500_regulator_testcase’ [-Wmissing-prototypes]
113 | int __attribute__((weak)) dbx500_regulator_testcase(
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-5-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This module shares the same name as its parent PMIC driver, which
confuses tools like kmod. Rename the regulator driver to avoid
such problems.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20200624171010.845271-1-seth.forshee@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
