There's no need to check for presence of "qcom,saw-reg" before parsing
it. If the property doesn't exist, parsing it will return NULL.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240828130056.3481050-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Chen-Yu Tsai <wenst@chromium.org>:
Here are some cleanups for some bits that I saw while reworking my I2C
device tree component prober to use of_regulator_bulk_get_all().
These are not directly related to that series, so I send them
separately here.
Allocate the memory with scoped/cleanup.h to reduce error handling (less
error paths) and make the code a bit simpler.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20240822161231.106744-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently in of_regulator_bulk_get_all(), if any regulator request
fails, the error path releases all regulators already requested,
but leaves the |struct regulator_bulk_data| memory to the caller
to free, and also leaves the regulator consumer pointers dangling.
The latter behavior is not documented, and may not be what the
caller is expecting.
Instead, explicitly clean up everything on error, and make it clear
that the result pointer is only update if the whole request succeeds.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If regulator_get() in of_regulator_bulk_get_all() returns an error, that
error gets overridden and -EINVAL is always passed out. This masks probe
deferral requests and likely won't work properly in all cases.
Fix this by letting of_regulator_bulk_get_all() return the original
error code.
Fixes: 27b9ecc7a9 ("regulator: Add of_regulator_bulk_get_all")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The original error message simply said "get() with no identifier"
without any context as to what was requested or what device the
request was related to. The only thing the user or developer could
do was grep for the message in the full source tree.
Amend the error message to be more specific, and also use dev_*
to associate the error message with a device.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Obtain the device node reference with scoped/cleanup.h and use scoped
for_each_child_of_node_scoped() to reduce error handling and make the
code a bit simpler. Add also brackets {} over outer for loop for code
readability.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20240814-cleanup-h-of-node-put-regulator-v1-2-87151088b883@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'struct linear_range' are not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security.
This is also more consistent with the other struct linear_range declaration
above.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
20767 4544 0 25311 62df drivers/regulator/bd9576-regulator.o
After:
=====
text data bss dec hex filename
21023 4288 0 25311 62df drivers/regulator/bd9576-regulator.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/a4e37991ea7b47145ab033128c8dd49f73a983e6.1722949232.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Use of_property_read_bool() to read boolean properties rather than
of_get_property(). This is part of a larger effort to remove callers
of of_get_property() and similar functions. of_get_property() leaks
the DT property data pointer which is a problem for dynamically
allocated nodes which may be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240731191312.1710417-24-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix sparse warning:
drivers/regulator/max77857-regulator.c:430:28: warning: symbol 'max77857_id' was not declared. Should it be static?
max77857_id is not used outside the source file. Make it static.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Link: https://patch.msgid.link/20240801114536.472796-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace a comma between expression statements by a semicolon.
Fixes: c0216c0e68 ("regulator: rt5120: Add PMIC regulator support")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://patch.msgid.link/20240716084659.1252690-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace a comma between expression statements by a semicolon.
Fixes: d48acfd037 ("regulator: wm831x-isink: Convert to use regulator_set/get_current_limit_regmap")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20240716085115.1252817-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
These two commits clean up the excessively loose dependencies for the
RZG2L USB VBCTRL regulator driver, ensuring it shouldn't prompt for
people who can't use it.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmaj7NsACgkQJNaLcl1U
h9Dnvgf/aCB42ngYjb9GD6Hq/Ngg0VwsSJSZLT7RPcvixlzLAzgxKDrkfyQSBvtg
vDkqnHZIFI2yVwsqzBrqxtQb9XL6p9e/rQHvkxG7QreMkC3JzakqCAQAq4n9/Tpq
dFGiAyaG8CJt8Nsf1JGthGJsb1qGjfp9X6IFFNwR90QZvZJB749rnoi7OaMXUumd
mYPKvOWUoo2LSMWFXLTHssLJHHct7m7EDTXy+q99paYcaUt1gnajnpeg6q+lqy9h
4hkF4QfGWJJC0DbCITm6G3L/q3bHPdDWfpo2LcX5iA+lFwvSj6LyTQFdMIwQ4oJg
pwySWXA9kO4+7EY1vLqf6KD5czpZ6g==
=mWEi
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.11-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"These two commits clean up the excessively loose dependencies for the
RZG2L USB VBCTRL regulator driver, ensuring it shouldn't prompt for
people who can't use it"
* tag 'regulator-fix-v6.11-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Further restrict RZG2L USB VBCTRL regulator dependencies
regulator: renesas-usb-vbus-regulator: Update the default
Since the regulator can't be used without the USB controller also
tighten the dependency to match, as well as the default.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20240726-regulator-restrict-rzg2l-v1-1-640e508896e2@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
- Add support for ROHM BD96801 Power Management IC
- Add support for Cirrus Logic CS40L50 Haptic Driver with Waveform Memory
- Add support for Marvell 88PM886 Power Management IC
- New Device Support
- Add support for Keyboard Backlight to ChromeOS Embedded Controller
- Add support for LEDs to ChromeOS Embedded Controller
- Add support for Charge Control to ChromeOS Embedded Controller
- Add support for the HW Monitoring Service to ChromeOS Embedded Controller
- Add support for AUXADCs to MediaTek MT635{7,8,9} Power Management ICs
- New Functionality
- Allow Syscon consumers to supply their own Regmaps on registration
- Fix-ups
- Constify/staticise applicable data structures
- Remove superfluous/duplicated/unused sections
- Device Tree binding adaptions/conversions/creation
- Trivial; spelling, whitespace, coding-style adaptions
- Utilise centrally provided helpers and macros to aid simplicity/duplication
- Drop i2c_device_id::driver_data where the value is unused
- Replace ACPI/DT firmware helpers with agnostic variants
- Move over to GPIOD (descriptor-based) APIs
- Annotate a bunch of __counted_by() cases
- Straighten out some includes
- Bug Fixes
- Ensure potentially asserted recent lines are deasserted during initialisation
- Avoid "<module>.ko is added to multiple modules" warnings
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Fix Wvoid-pointer-to-enum-cast warnings
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmaWf6sACgkQUa+KL4f8
d2HhAw//UMujhKk/IfzGck3RoaKH3H22oVpd98BpzJCZBKSpl9pGsumHCicBMVAK
gp8SuwKNCAX+Fa/TubHz0xH6FWxLFXezh5DvO1t1DrPNokG+u4QPTfgMJ1IfBMHO
w7aL74rtJEyWBeod4+qNVoq6KNDaWjiWQlxGQ+9IoSNmxSTL6pkYMqo935RnqhRr
nm2TfSOIshk4tiO9tVA1ecCgjVwsG51803hypmd1AH6qBb7JsY6k1HWukLGaqUiV
+57oQzCTPIRYJhYdca06xi4ZmPg2kmoYKlxqW5ExyM7Mxs9aZZzwwZ7929LKXC6o
ebAPDc3auoww7B5mHbbVuBj0gDZKtfXpBRKSHLNtmhi0xmjnwZxQIumkpVGQALkI
0TQffgYVU4O7IXsAZG9w5igyMzEo9SZJMyrfFaQ0iB3rx5bXuh4b6btfewAkyI1H
+o3Yjymf4CR1trY9qnWCGWM/COQLIiGRhsk/RqGjy0xtpQo1Skx+AIkc6QD2zl6Y
ohC0JzEWTQe7c1DOM3SLpNoCb/GbFpVi0RrXRVfRltPHpVb/r54Zlbo+PrCaC8FB
EkU+86XbxGMh7hLtz5yhmnNCWKHQ6jbaFESwtZLo4d42CKvZaobL4xVCL56OntsH
ikmTNG+X0mUAZiCwGgK5OhEVCAtCcjRtz1U93wgDBaz7Y39z+yM=
=DSjk
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Drivers:
- ROHM BD96801 Power Management IC
- Cirrus Logic CS40L50 Haptic Driver with Waveform Memory
- Marvell 88PM886 Power Management IC
New Device Support:
- Keyboard Backlight to ChromeOS Embedded Controller
- LEDs to ChromeOS Embedded Controller
- Charge Control to ChromeOS Embedded Controller
- HW Monitoring Service to ChromeOS Embedded Controller
- AUXADCs to MediaTek MT635{7,8,9} Power Management ICs
New Functionality:
- Allow Syscon consumers to supply their own Regmaps on registration
Fix-ups:
- Constify/staticise applicable data structures
- Remove superfluous/duplicated/unused sections
- Device Tree binding adaptions/conversions/creation
- Trivial; spelling, whitespace, coding-style adaptions
- Utilise centrally provided helpers and macros to aid
simplicity/duplication
- Drop i2c_device_id::driver_data where the value is unused
- Replace ACPI/DT firmware helpers with agnostic variants
- Move over to GPIOD (descriptor-based) APIs
- Annotate a bunch of __counted_by() cases
- Straighten out some includes
Bug Fixes:
- Ensure potentially asserted recent lines are deasserted during
initialisation
- Avoid "<module>.ko is added to multiple modules" warnings
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Fix Wvoid-pointer-to-enum-cast warnings"
* tag 'mfd-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (87 commits)
mfd: timberdale: Attach device properties to TSC2007 board info
mfd: tmio: Move header to platform_data
mfd: tmio: Sanitize comments
mfd: tmio: Update include files
mmc: tmio/sdhi: Fix includes
mfd: tmio: Remove obsolete io accessors
mfd: tmio: Remove obsolete platform_data
watchdog: bd96801_wdt: Add missing include for FIELD_*()
dt-bindings: mfd: syscon: Add APM poweroff mailbox
dt-bindings: mfd: syscon: Split and enforce documenting MFD children
dt-bindings: mfd: rk817: Merge support for RK809
dt-bindings: mfd: rk817: Fixup clocks and reference dai-common
dt-bindings: mfd: syscon: Add TI's opp table compatible
mfd: omap-usb-tll: Use struct_size to allocate tll
dt-bindings: mfd: Explain lack of child dependency in simple-mfd
dt-bindings: mfd: Dual licensing for st,stpmic1 bindings
mfd: omap-usb-tll: Annotate struct usbtll_omap with __counted_by
mfd: tps6594-core: Remove unneeded semicolon in tps6594_check_crc_mode()
mfd: lm3533: Move to new GPIO descriptor-based APIs
mfd: tps65912: Use devm helper functions to simplify probe
...
The IRQ line might not be connected on some boards. Allow the driver
to be probed without it.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://patch.msgid.link/20240708084107.38986-5-frieder@fris.de
Signed-off-by: Mark Brown <broonie@kernel.org>
`da9121_1ch_regmap_config` and `da9121_2ch_regmap_config` are not
modified and can be declared as const to move their data to a
read-only section.
The pointer that references those structs has been converted to const
accordingly.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://patch.msgid.link/20240704-regulator-const-regmap-v1-1-bce0ddef63ea@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Support the LDO and buck regulators of the Marvell 88PM886 PMIC.
Signed-off-by: Karel Balej <balejk@matfyz.cz>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240531175109.15599-4-balejk@matfyz.cz
Signed-off-by: Lee Jones <lee@kernel.org>
The ROHM BD96801 "Scalable PMIC" is an automotive grade PMIC which can
scale to different applications by allowing chaining of PMICs. The PMIC
also supports various protection features which can be configured either
to fire IRQs - or to shut down power outputs when failure is detected.
The driver implements basic voltage control and sending error
notifications.
NOTE:
The driver does not support doing configuration which require the PMIC
to be in STBY state. The omitted feature set includes setting safety
limit values, changing LDO voltages and controlling enable state for
some regulators.
Also, the ERRB IRQ is not handled.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/50cf02b046df218a21a0f9c4820531d821fc20d4.1719473802.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT bit of
the VBUS Control Register(VBENCTL) register in the USBPHY Control. But
this IP is in the Reset block.
Reset driver exposes this register as regmap and instantiate the USB VBUS
regulator device. Consumers(phy device) can use regulator APIs to control
VBUS as controlling is done in the atomic context using a new API which
is added for the purpose.
As per the RZ/G2L HW manual, VBUSEN can be controlled by the VBOUT
bit of the VBUS Control Register. This register is mapped in the reset
framework. The reset driver expose this register as regmap and instantiates
this driver. The consumer will use the regulator API to control the VBOUT
bit as the control need to be done in the atomic context.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20240616105402.45211-5-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a helper function that allow regulator consumers to allow low-level
HW access, in order to enable/disable regulator in atomic context.
The use-case for RZ/G2L SoC is to enable VBUS selection register based
on vbus detection that happens in interrupt context.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20240616105402.45211-4-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The previous driver never worked, and never got even compiled because
it was missing the DVFSRC driver entirely, including needed neaders.
This is a full (or nearly full) refactoring of the MediaTek DVFSRC
controlled Regulators driver, retaining support for the MT6873, MT8183
and MT8192 SoC, and adding MT8195.
As part of the refactoring, this driver is now probed using its own
devicetree compatible, as this is a child of the main DVFSRC driver
and gets probed as a subnode of that.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20240610085735.147134-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver never worked, and never got even compiled, because it was
missing the DVFSRC driver entirely, including headers it relies on!
In preparation of a full refactoring of this driver, remove it.
The Makefile and Kconfig entries are retained, as those are reused
as-is for the refactored code.
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20240610085735.147134-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Trying to use userspace-consumer when the required supplies have not yet
been probed will throw an error message on deferral:
reg-userspace-consumer output-led-power: Failed to get supplies: -517
So, lets simply use dev_err_probe() instead of dev_err() to not print
errors in case when driver probe is being deferred.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Link: https://patch.msgid.link/20240623140947.1252376-1-robimarko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Qualcomm PM8008 is an I2C-controlled PMIC containing seven LDO
regulators.
The driver is based on a driver submitted by Satya Priya, but it has
been cleaned up and reworked to match the new devicetree binding which
no longer describes each regulator as a separate device.
This avoids describing internal details like register offsets in the
devicetree and allows for extending the implementation with features
like over-current protection without having to update the binding.
Specifically note that the regulator interrupts are shared between all
regulators.
Note that the secondary regmap is looked up by name and that if the
driver ever needs to be generalised to support regulators provided by
the primary regmap (I2C address) such information could be added to the
device-id table.
This also fixes the original implementation, which looked up regulators
by 'regulator-name' property rather than devicetree node name and which
prevented the regulators from being named to match board schematics.
Link: https://lore.kernel.org/r/1655200111-18357-8-git-send-email-quic_c_skakit@quicinc.com
Cc: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240608155526.12996-12-johan+linaro@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The X-Powers AXP717 PMIC has separate input supply pins for each group
of LDOs, so they are not all using the same DCDC1 input, as described
currently.
Replace the "supply" member of each LDO description with the respective
group supply name, so that the supply dependencies can be correctly
described in the devicetree.
Also fix two off-by-ones in the regulator macros, after some double
checking the numbers against the datasheet. This uncovered a bug in the
datasheet: add a comment to document this.
Fixes: d2ac3df75c ("regulator: axp20x: add support for the AXP717")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: John Watts <contact@jookia.org>
Link: https://lore.kernel.org/r/20240418000736.24338-3-andre.przywara@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Ramp values are inverted. This caused wrong values written to register
when ramp values were defined in device tree.
Invert values in table to fix this.
Signed-off-by: Kalle Niemi <kaleposti@gmail.com>
Fixes: 1aad39001e ("regulator: Support ROHM BD71815 regulators")
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/ZmmJXtuVJU6RgQAH@latitude5580
Signed-off-by: Mark Brown <broonie@kernel.org>
On x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/da9121-regulator.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/max20411-regulator.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/rt4831-regulator.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/tps6286x-regulator.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240610-md-drivers-regulator-v2-1-cf39106d7e54@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The number of irqs is computed to allocate the right amount of memory for
the irq data. An array of struct tps6594_regulator_irq_data is allocated
one time for all the irqs. Each irq uses one cell of the array.
If the computed number of irqs is not correct, not allocated memory could
be used.
Fix the values used in the calculation for TPS6594 and TPS65224.
Fixes: 00c826525f (regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators)
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Tested-by: Nishanth Menon <nm@ti.com>
Link: https://msgid.link/r/20240603170100.2394402-1-thomas.richard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Alina Yu <alina_yu@richtek.com>:
There are two types of LDO VOUT: fixed voltage mode and adjustable voltage mode.
As the fixed voltage for the LDO is outside the range of the adjustable voltage mode,
the constraints for this scenario are not suitable to represent both modes.
Therefore, A property is added to specify the fixed LDO VOUT.
In this version, a software bug has been fixed.
rtq2208_ldo_match is no longer a local variable.
It prevents invalid memory access when devm_of_regulator_put_matches is called.
A fixed LDO VOUT property has been added to specify the fixed_uV of the regulator_desc.
Additionally, a check has been included in this version
to ensure that the fixed_uV matches the constraints.
Signed-off-by: Alina Yu <alina_yu@richtek.com>
Link: https://msgid.link/r/39357ff9e6e5f3dec5a6f7f833a3591c0defc63a.1716870419.git.alina_yu@richtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In this patch, LDO's adjustable and fixed Vout settings are compatible.
The LDO Vout ability depends on "richtek,fixed-microvolt".
If adjustable, the Vout can be set to either 1800mV or 3300mV.
Signed-off-by: Alina Yu <alina_yu@richtek.com>
Link: https://msgid.link/r/5ad4c7728c7fa7f6286db36b99d31c9d0f5d16c7.1716870419.git.alina_yu@richtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Patrick Delaunay <patrick.delaunay@foss.st.com>:
This patchset adds the new PWR regulators compatible for STM32MP13:
"st,stm32mp13-pwr-reg".
As this node is just introduced by [1] and it is is not used by any
board in Linux, it is the good time to introduced this compatible
and update the STM32MP13 SoC dtsi without ABI break.
A new compatible is needed as the content of the PWR_CR3 register,
used by this driver change with new bits on STM32MP13 for SD IO domain:
- bit 23: VDDSD2VALID
- bit 22: VDDSD1VALID
- bit 16: VDDSD2RDY
- bit 15: VDDSD2EN
- bit 14: VDDSD1RDY
- bit 13: VDDSD1EN
I will push a update on STM32MP13 SoC dtsi if this new compatible
is accepted to preserve the bisectability.
[1] commit f798f7079233 ("ARM: dts: stm32: add PWR regulators support on stm32mp131")
https://lore.kernel.org/linux-arm-kernel/b89d0531-067f-4356-91b0-ed7434cee3d7@foss.st.com/
'max77503_dev' is unused since the original
commit a0c543bdf4 ("regulator: max77503: Add ADI MAX77503 support").
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://msgid.link/r/20240528174659.53022-1-linux@treblig.org
Signed-off-by: Mark Brown <broonie@kernel.org>
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also remove commas after the sentinel entries.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/20240513080525.2353168-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
A bunch of fixes that came in during the merge window, Matti found
several issues with some of the more complexly configured Rohm
regulators and the helpers they use and there were some errors in the
specification of tps6594 when regulators are grouped together.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZPLEoACgkQJNaLcl1U
h9DNfQf7B5ppKeMfWEzJKGywWmmzG96AldSvl7rcMyFxdzXjFu/kptGO0tLkJwTs
DnlZF6TBooB/RezoHhVgq6nLtJcowQPlbhM3Y4gujzvumZiJ2k2Chsyy+H0YRvkZ
kC9Bb2VGk7v5PimZiSugwgc1ZF+AE3LsZyzwWo4d0LZxOE1EyeQQ3SzygoKXtqzF
QJxsT6+ynaeYBxVwW+pHztWca8b3o+kqNLauxcWb0J0sPJPu/dl2PIQrKIZBsOWC
E34Y8MrrktqPApGE7kVL7dkmofceZI7Qv71aq2UJvRJOhvWP47f2L7nYwYi3kuIH
EjioQuqa1Bf7Wms59Q68WLjn4e0ILA==
=NeiV
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A bunch of fixes that came in during the merge window.
Matti found several issues with some of the more complexly configured
Rohm regulators and the helpers they use and there were some errors in
the specification of tps6594 when regulators are grouped together"
* tag 'regulator-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: tps6594-regulator: Correct multi-phase configuration
regulator: tps6287x: Force writing VSEL bit
regulator: pickable ranges: don't always cache vsel
regulator: rohm-regulator: warn if unsupported voltage is set
regulator: bd71828: Don't overwrite runtime voltages
- Add support for X-Powers AXP717 PMIC to AXP22X
- Add support for Rockchip RK816 PMIC to RK8XX
- Add support for TI TPS65224 PMIC to TPS6594
- New Functionality
- Add Power Off functionality to Rohm BD71828
- Allow I2C SMBus access in Renesas RSMU
- Fix-ups
- Device Tree binding adaptions/conversions/creation
- Shift Intel support over to MSI interrupts
- Generify adding platform data away from being ACPI specific
- Use device core supplied attribute to register sysfs entries
- Replace hand-rolled functionality with generic APIs
- Utilise centrally provided helpers and macros
- Clean-up error handling
- Remove superfluous/duplicated/unused sections
- Trivial; spelling, whitespace, coding-style adaptions
- More Maple Tree conversions
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmZNwaMACgkQUa+KL4f8
d2Gh8BAAlD0/SUXVKuMppST6pyqGp90BucELY/enaFFI7eHTrevxSM5Ywtbjig0l
+pz7WYm0bmCGXhr1yGrrhryKc2hGWacT2MhM8mHpkomHpN3qEnRQRKnjISTHDLG5
9t1UyqDaBsoI7HPO0iiHPiinoQnM/WIHEjaelQNgl4g2sj9iFMmGhXcYX6IXQwHs
Yu3l58Yju7nBxjjmgb4tFs8CPf+/CCP0jpwzWd99kZHPcRhupULmQgSLhmbSf4H8
/KQg7wFSufabxuJOKKR2gUIdGeMlaNhyoPtSdDyn0Pji7lubNyvfaK+JSyae9Esp
HYD1RD87aQLFyJAfRnDUPI9xQauPpz29V/wGujlqTiz0GYEVGy4Yo2yWH/CoHhUV
+yb3I/7I6u+rvQHH2bnsAUQ3doh6fuFNvjNJgNbBtqraJ2Pt3nJNGxfSolwPf3mt
GEb60ahbzLMGtxbVoVOLbDvZgN3FeIKMcdamS1JvKTPTf62H9AOyhUIlzibm1AVl
i3u2cEfygTeyqUdCIhNLEavmj4uHbFeGXgvveuvbizJTtdEoQ2QIuslwLTrpivkq
URaDpZfclu9sv+FNY1wiQMnlC4uueyJpkfItEHX876uB7r1ReWMQD8Lf3hI5xJeh
JM0si93OorG9DR3h5iBnJu1kHqtQ56E46BFP8oh70p9N+Hpaw5c=
=QAjw
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Device Support:
- Add support for X-Powers AXP717 PMIC to AXP22X
- Add support for Rockchip RK816 PMIC to RK8XX
- Add support for TI TPS65224 PMIC to TPS6594
New Functionality:
- Add Power Off functionality to Rohm BD71828
- Allow I2C SMBus access in Renesas RSMU
Fix-ups:
- Device Tree binding adaptions/conversions/creation
- Shift Intel support over to MSI interrupts
- Generify adding platform data away from being ACPI specific
- Use device core supplied attribute to register sysfs entries
- Replace hand-rolled functionality with generic APIs
- Utilise centrally provided helpers and macros
- Clean-up error handling
- Remove superfluous/duplicated/unused sections
- Trivial; spelling, whitespace, coding-style adaptions
- More Maple Tree conversions"
* tag 'mfd-next-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (44 commits)
dt-bindings: mfd: Use full path to other schemas
mfd: rsmu: support I2C SMBus access
dt-bindings: mfd: Convert lp873x.txt to json-schema
dt-bindings: mfd: aspeed: Drop 'oneOf' for pinctrl node
dt-bindings: mfd: allwinner,sun6i-a31-prcm: Use hyphens in node names
mfd: ssbi: Remove unused field 'slave' from 'struct ssbi'
mfd: kempld: Remove custom DMI matching code
mfd: cs42l43: Update patching revision check
dt-bindings: mfd: qcom: pm8xxx: Add pm8901 compatible
mfd: timberdale: Remove redundant assignment to variable err
dt-bindings: mfd: qcom,spmi-pmic: Add pbs to SPMI device types
dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
dt-bindings: mfd: qcom,tcsr: Add compatible for SDX75
mfd: axp20x: Convert to use Maple Tree register cache
mfd: bd71828: Remove commented code lines
mfd: intel-m10-bmc: Change staging size to a variable
dt-bindings: mfd: Add ROHM BD71879
mfd: Tidy Kconfig dependency's parentheses
mfd: ocelot-spi: Use spi_sync_transfer()
dt-bindings: mfd: syscon: Add missing simple syscon compatibles
...
According to the TPS6594 PMIC Manual (linked) 8.3.2.1.4 Multi-Phase BUCK
Regulator Configurations section, the PMIC ignores all the other bucks'
except the primary buck's regulator registers. This is BUCK1 for
configurations BUCK12, BUCK123 and BUCK1234 while it is BUCK3 for
BUCK34. Correct the registers mapped for these configurations
accordingly.
Fixes: f17ccc5deb ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators")
Link: https://www.ti.com/lit/gpn/tps6594-q1
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Link: https://msgid.link/r/20240521094758.2190331-1-n-francis@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The data-sheet for TPS6287x-Q1
https://www.ti.com/lit/ds/symlink/tps62873-q1.pdf
states at chapter 9.3.6.1 Output Voltage Range:
"Note that every change to the VRANGE[1:0] bits must be followed by a
write to the VSET register, even if the value of the VSET[7:0] bits does
not change."
The current implementation of the driver uses the
regulator_set_voltage_sel_pickable_regmap() helper which further uses
regmap_update_bits() to write the VSET-register. The
regmap_update_bits() will not access the hardware if the new register
value is same as old. It is worth noting that this is true also when the
register is marked volatile, which I can't say is wrong because
'read-mnodify-write'-cycle with a volatile register is in any case
something user should carefully consider.
The 'range_applied_by_vsel'-flag in regulator desc was added to force
the vsel register upodates by using regmap_write_bits(). This variant
will always unconditionally write the bits to the hardware.
It is worth noting that the vsel is now forced to be written to the
hardware, whether the range was changed or not. This may cause a
performance drop if users are wrtiting same voltage value repeteadly.
It would be possible to read the range register to determine if it was
changed, but this would be a performance issue for users who don't use
reg cache for vsel.
Always write the VSET register to the hardware regardless the cache.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: 7b0518fbf2 ("regulator: Add support for TI TPS6287x regulators")
Link: https://msgid.link/r/ZktD50C5twF1EuKu@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range
is changed, the new voltage setting is not taking effect until the vsel
register is written.
Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this
behaviour and to force the vsel value to be written to hardware if range
was changed, even if the old selector was same as the new one.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
A few of the ROHM PMICs allow setting low-power state specific voltages
for regulators. These voltages are then taken in use (by the hardware)
when the PMIC state is changed.
The voltages for these states can be given via device-tree. If
unsupported voltage has been given, the users have only seen print:
"driver callback failed to parse DT for regulator <name>". This does
help to pinpoint the problem to some extent, but there may be several
properties in device-tree so it should help if we can be a bit more
specific.
Print the voltage value and the run-state property if voltage can not be
supported.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://msgid.link/r/0937411855967cbefd9ff2d6045a52ca26712c4a.1715848512.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of the regulators on the BD71828 have common voltage setting for
RUN/SUSPEND/IDLE/LPSR states. The enable control can be set for each
state though.
The driver allows setting the voltage values for these states via
device-tree. As a side effect, setting the voltages for
SUSPEND/IDLE/LPSR will also change the RUN level voltage which is not
desired and can break the system.
The comment in code reflects this behaviour, but it is likely to not
make people any happier. The right thing to do is to allow setting the
enable/disable state at SUSPEND/IDLE/LPSR via device-tree, but to
disallow setting state specific voltages for those regulators.
BUCK1 is a bit different. It only shares the SUSPEND and LPSR state
voltages. The former behaviour of allowing to silently overwrite the
SUSPEND state voltage by LPSR state voltage is also changed here so that
the SUSPEND voltage is prioritized over LPSR voltage.
Prevent setting PMIC state specific voltages for regulators which do not
support it.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: 522498f8cb ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators")
Link: https://msgid.link/r/e1883ae1e3ae5668f1030455d4750923561f3d68.1715848512.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There's one API update here, a new API factoring out a common pattern
for reference voltage supplies. These are supplies uses as a reference
by analogue circuits where the consumer requests and enables the supply,
reads the voltage to calibrate the user and then never touches it again.
This is factored out into a single operation which just returns the
voltage and uses devm_ to manage the request and enable portion.
Otherwise this has been a very quiet release, we've got some new device
support, some small fixes, housekeeping and cleanup work but nothing
substantial.
There's also some non-regulator changes in here, a number of users for
the new reference voltage API were merged along with it and some MFD
changes were pulled in as dependencies for new driver work.
Highlights:
- Add a new API for single operation handling of reference voltages.
- Support for Allwinner AXP717 and D1, and NXP PCA9561A.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZB3mMACgkQJNaLcl1U
h9DRmAf9Etp/ydeKGrbYD4K34Ptk4ZwchkTfvPEiNmJEDBlbcazRoeCF9asUVsDR
ByggQCahCWhEa+exT+IBQYswpwFRd1oZChSgGUmIS/7pvQDdaPL+53Fnw8SfzmdS
QygBEMNN8TGIu2Y+OqEEqINJ407NLbv2SbIlFX1CywZ5hDvCtvFdqhX/xCxTedBN
wXlyj2BLe/xmbTGxr3Ssb+l8a0oe1BZvLO6ddrg8DtS92l1zJ0sEk+fegHSQGPRI
wI4QehjEgphBsoGhybMGz3ny0nvSs3JkpgRiG/ly3cT97Cx6KSGctMtqjmy7Ynh5
TM3Qq5DS37pBKIm79zmQFbL1z2A9Bw==
=wV3x
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"There's one API update here, a new API factoring out a common pattern
for reference voltage supplies. These are supplies used as a reference
by analogue circuits where the consumer requests and enables the
supply, reads the voltage to calibrate the user and then never touches
it again. This is factored out into a single operation which just
returns the voltage and uses devm_ to manage the request and enable
portion.
Otherwise this has been a very quiet release, we've got some new
device support, some small fixes, housekeeping and cleanup work but
nothing substantial.
There's also some non-regulator changes in here, a number of users for
the new reference voltage API were merged along with it and some MFD
changes were pulled in as dependencies for new driver work.
Highlights:
- Add a new API for single operation handling of reference voltages
- Support for Allwinner AXP717 and D1, and NXP PCA9561A"
* tag 'regulator-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (33 commits)
regulator: sun20i: Add Allwinner D1 LDOs driver
regulator: dt-bindings: Add Allwinner D1 system LDOs
regulator: Mention regulator id in error message about dummy supplies
staging: iio: impedance-analyzer: ad5933: Use devm_regulator_get_enable_read_voltage()
iio: frequency: admv1013: Use devm_regulator_get_enable_read_voltage()
iio: addac: ad74115: Use devm_regulator_get_enable_read_voltage()
hwmon: (adc128d818) simplify final return in probe
regulator: devres: fix devm_regulator_get_enable_read_voltage() return
hwmon: (da9052) Use devm_regulator_get_enable_read_voltage()
hwmon: (adc128d818) Use devm_regulator_get_enable_read_voltage()
regulator: devres: add API for reference voltage supplies
regulator: rtq2208: Fix LDO discharge register and add vsel setting
regulator: dt-bindings: fixed-regulator: Add a preferred node name
regulator: axp20x: add support for the AXP717
mfd: axp20x: Add support for AXP717 PMIC
dt-bindings: mfd: x-powers,axp152: Document AXP717
regulator: axp20x: fix typo-ed identifier
dt-bindings: regulator: qcom,usb-vbus-regulator: Add PM7250B compatible
regulator: pca9450: add pca9451a support
regulator: dt-bindings: pca9450: add pca9451a support
...
D1 contains two pairs of LDOs, "analog" LDOs and "system" LDOs. They are
similar and can share a driver, but only the system LDOs have a DT
binding defined so far.
The system LDOs have a single linear range. The voltage step is not an
integer, so a custom .list_voltage is needed to get the rounding right.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20240509153107.438220-3-wens@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_get() may sometimes be called more than once for the same
consumer device, something which before commit dbe954d8f1 ("regulator:
core: Avoid debugfs: Directory ... already present! error") resulted in
errors being logged.
A couple of recent commits broke the handling of such cases so that
attributes are now erroneously created in the debugfs root directory the
second time a regulator is requested and the log is filled with errors
like:
debugfs: File 'uA_load' in directory '/' already present!
debugfs: File 'min_uV' in directory '/' already present!
debugfs: File 'max_uV' in directory '/' already present!
debugfs: File 'constraint_flags' in directory '/' already present!
on any further calls.
Fixes: 2715bb11cf ("regulator: core: Fix more error checking for debugfs_create_dir()")
Fixes: 08880713ce ("regulator: core: Streamline debugfs operations")
Cc: stable@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240509133304.8883-1-johan+linaro@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from David Lechner <dlechner@baylibre.com>:
In the IIO subsystem, we noticed a pattern in many drivers where we need
to get, enable and get the voltage of a supply that provides a reference
voltage. In these cases, we only need the voltage and not a handle to
the regulator. Another common pattern is for chips to have an internal
reference voltage that is used when an external reference is not
available. There are also a few drivers outside of IIO that do the same.
So we would like to propose a new regulator consumer API to handle these
specific cases to avoid repeating the same boilerplate code in multiple
drivers.
As an example of how these functions are used, I have included a few
patches to consumer drivers. But to avoid a giant patch bomb, I have
omitted the iio/adc and iio/dac patches I have prepared from this
series. I will send those separately but these will add 36 more users
of devm_regulator_get_enable_read_voltage() in addition to the 6 here.
In total, this will eliminate nearly 1000 lines of similar code and will
simplify writing and reviewing new drivers in the future.
Add support for TPS65224 regulators (bucks and LDOs) to TPS6594 driver as
they have significant functional overlap. TPS65224 PMIC has 4 buck
regulators and 3 LDOs. BUCK12 can operate in dual phase.
The output voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
Signed-off-by: Bhargav Raviprakash <bhargav.r@ltts.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/0109018f2fdcc305-3b817569-21b6-42a7-942c-8edbff3848f2-000000@ap-south-1.amazonses.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for rk816 to the existing rk808 regulator driver.
The infrastructure of the driver can be re-used as is. A peculiarity for
this version is, that BUCK1/BUCK2 have a (common) bit which needs to
toggled after a voltage change to confirm the change. Regulator regmap
takes care of that by defining a apply_bit and apply_reg for those
regulators.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240416161237.2500037-6-knaerzche@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
rk808_set_suspend_voltage_range currently does not account the existence of
apply_bit/apply_reg.
This adds support for those in same way it is done in
regulator_set_voltage_sel_regmap and is required for the upcoming RK816
support
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240416161237.2500037-5-knaerzche@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
A common use case for regulators is to supply a reference voltage to an
analog input or output device. This adds a new devres API to get,
enable, and get the voltage in a single call. This allows eliminating
boilerplate code in drivers that use reference supplies in this way.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20240429-regulator-get-enable-get-votlage-v2-1-b1f11ab766c1@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
based on the alias from of_device_id table.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://msgid.link/r/20240410172615.255424-2-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
based on the alias from of_device_id table.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://msgid.link/r/20240410172615.255424-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6360 regulator binding, the example in the MT6360 mfd binding, and
the devicetree users of those bindings are rightfully declaring MT6360
regulator subnodes with non-capital names, and luckily without using the
deprecated regulator-compatible property.
With this driver declaring capitalized BUCKx/LDOx as of_match string for
the node names, obviously no regulator gets probed: fix that by changing
the MT6360_REGULATOR_DESC macro to add a "match" parameter which gets
assigned to the of_match.
Fixes: d321571d5e ("regulator: mt6360: Add support for MT6360 regulator")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://msgid.link/r/20240409144438.410060-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator IRQ helper requires caller to provide pointer to IRQ name
which is kept in memory by caller. All other data passed to the helper
in the regulator_irq_desc structure is copied. This can cause some
confusion and unnecessary complexity.
Make the regulator_irq_helper() to copy also the provided IRQ name
information so caller can discard the name after the call to
regulator_irq_helper() completes.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://msgid.link/r/ZhJMuUYwaZbBXFGP@drtxq0yyyyyyyyyyyyydy-3.rev.dnainternet.fi
Signed-off-by: Mark Brown <broonie@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmYFXDYACgkQUa+KL4f8
d2GtvQ//cDm8f0dxPBtX3OhUat0jG9xhci/+a+12L3LbjrK8VnnTDp3HN/il3STo
PdZc6f9kxI7HENumJx/5f2R+SWZSKz4EsOScMpu4S2ig09ygsdykkl0uwAR/VyIq
xT7UaYR6DQHD2C1OaLadkGBcLLbIWIZ/XGZo6aOkdJ5/N+teguVVusJj9/wUrJeN
Gmm+depjszlj6bgQUHSjKchx6K/BlDic3PzG4pg3KAUPYczEVGQ3QSPvT+be8Agl
+QN3KqS1fzvHp4RYducKREYP446iT8Zj5kKrQsSc2YZ65v6zvwcQ0JMW7gKkqmqB
oYqT4ABaKBLlH8iEtLGrbZGp5mgEoB3K293eI1avpJmW+SkOpPV+k5jWReS3AymD
tp57paOymof0PT26Cccy8kD1UqOzWvyrSfFUZyMtA5D9geeCxfSDw70ngRGy6NGm
PaMl7l8MAcffFauMLSGxxBjlvbfsEXx23Au5dQ58U68Hq59YTm2o3FXZ8yiOVm74
+F0UIKthP4kwQdt7y3THS/qpbJURzI5p/7j/ci2QqHE+SeMGPVZF12EzNZcw69St
E916nMPuHeTH5I1ssBQsi7Z+eaaPh+UIpb7sYR4hDT6l3gbrqBbgKkcyVEqonpbd
I/r7q37cXoyn1sbIuSEu4S3Ugvjs7LwbDFrZODjYOR6yoEfRcOo=
=s1gJ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmYFaA8ACgkQJNaLcl1U
h9COdQf8DjNS69Q1Q8ajj+eN0RHvF3Flp4SqeOxXJjCs9z6bijdBx+qvck+vb+Qo
5VESLKu2arzar9WmHRdCKbXS4grBxFrkp9Araja8SVd8Z64hJRJNy5/q4OHZbJ+g
RcGA38Xdl3I6qcQpAyXHKct28aZmP3CXz4TeN3kqklLHBPulahZffVfk+OtBn8zy
6Y5SPFSMJFGSsEweV3tdmZAl39QJLVzTeWKWMSmcpIHok0wc21m/u6sbA6C3vHQJ
+2JUekSu9itxcaT1Z5VoUddYlRf/gUIINLxelPvEyWZ0JWdvSc/QrqYgHZQgDu5C
FrDPRiZLOZ8Pe/SjFsRGaWRkKM9M2g==
=HCHE
-----END PGP SIGNATURE-----
regulator: Merge axp20x changes
There will be at least one incremental change on top of some MFD
overlapping device additions for this driver so merge now.
Merge tag 'ib-mfd-regulator-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into regulator-6.10
The X-Powers AXP717 is a typical PMIC from X-Powers, featuring four
DC/DC converters and 15 LDOs, on the regulator side.
Describe the chip's voltage settings and switch registers, how the
voltages are encoded, and connect this to the MFD device via its
regulator ID.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Mark Brown <broonie@kernel.org>
Tested-by: Ryan Walklin <ryan@testtoast.com>
Link: https://lore.kernel.org/r/20240310010211.28653-5-andre.przywara@arm.com
Signed-off-by: Lee Jones <lee@kernel.org>
The registers to set the X-Powers AXP313 regulators are of course
"CONTROL" registers, not "CONRTOL" ones.
Fix the typo in the header file and in its users. No functional change.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Ryan Walklin <ryan@testtoast.com>
Link: https://lore.kernel.org/r/20240310010211.28653-2-andre.przywara@arm.com
Signed-off-by: Lee Jones <lee@kernel.org>
Merge series from Bo Liu <liubo03@inspur.com>:
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Bo Liu (13):
regulator: da9121: convert to use maple tree register cache
regulator: da9211: convert to use maple tree register cache
regulator: isl9305: convert to use maple tree register cache
regulator: max8973: convert to use maple tree register cache
regulator: mt6311: convert to use maple tree register cache
regulator: pca9450: convert to use maple tree register cache
regulator: pf8x00: convert to use maple tree register cache
regulator: pfuze100: convert to use maple tree register cache
regulator: rtmv20: convert to use maple tree register cache
regulator: rtq6752: convert to use maple tree register cache
regulator: tps51632: convert to use maple tree register cache
regulator: tps62360: convert to use maple tree register cache
regulator: rpi-panel-attiny: convert to use maple tree register cache
drivers/regulator/da9121-regulator.c | 4 ++--
drivers/regulator/da9211-regulator.c | 2 +-
drivers/regulator/isl9305.c | 2 +-
drivers/regulator/max8973-regulator.c | 2 +-
drivers/regulator/mt6311-regulator.c | 2 +-
drivers/regulator/pca9450-regulator.c | 2 +-
drivers/regulator/pf8x00-regulator.c | 2 +-
drivers/regulator/pfuze100-regulator.c | 2 +-
drivers/regulator/rpi-panel-attiny-regulator.c | 2 +-
drivers/regulator/rtmv20-regulator.c | 2 +-
drivers/regulator/rtq6752-regulator.c | 2 +-
drivers/regulator/tps51632-regulator.c | 2 +-
drivers/regulator/tps62360-regulator.c | 2 +-
13 files changed, 14 insertions(+), 14 deletions(-)
--
2.18.2
Add of_match table for "ti,tps65132" compatible string.
This fixes automatic driver loading when using device-tree,
and if built as a module like major linux distributions do.
Signed-off-by: André Apitzsch <git@apitzsch.eu>
Link: https://msgid.link/r/20240325-of_tps65132-v1-1-86a5f7ef4ede@apitzsch.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-14-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-13-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-12-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-11-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-10-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-9-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-8-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-7-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-6-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-5-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-4-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-3-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://msgid.link/r/20240320085740.4604-2-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
One fix that came in during the merge window, fixing a problem with
bootstrapping the state of exclusive regulators which have a parent
regulator.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmX9kqoACgkQJNaLcl1U
h9BzzAf+M6O+WUIbcNj84x+dz13IOdNolkb5kGjVJLY+yh5HGEnmRRLZVj4TF+pO
4L+EJa7pKY9a6YpODy/pDpyzdQgYbdsLj88/G4ug0p2FMaQqpl1GEpYyEfaNtVW8
6BlQlw4L/429k2FVble/0zDyzJjpvQsGwk8qAmHcA3mUJSY+BMqlpeU9t6zMXR7l
yYH+mVgqAx2sY8z20CWvZDRgqOVBrrE1IZ8RKuW5Xm0/cWGY0ihj6uy4Z3zFuq9I
pjAZ++FSBmNRj1XDNm8UqRdjVtCTIuaCNJZ0ayqEGxDb3yNAVpjpVKURELBA17CR
fCw3+3Yyj1d+5hb8mrXeKrC2Ro5WVQ==
=vvdo
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.9-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"One fix that came in during the merge window, fixing a problem with
bootstrapping the state of exclusive regulators which have a parent
regulator"
* tag 'regulator-fix-v6.9-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Propagate the regulator state in case of exclusive get
heap optimizations".
- Kuan-Wei Chiu has also sped up the library sorting code in the series
"lib/sort: Optimize the number of swaps and comparisons".
- Alexey Gladkov has added the ability for code running within an IPC
namespace to alter its IPC and MQ limits. The series is "Allow to
change ipc/mq sysctls inside ipc namespace".
- Geert Uytterhoeven has contributed some dhrystone maintenance work in
the series "lib: dhry: miscellaneous cleanups".
- Ryusuke Konishi continues nilfs2 maintenance work in the series
"nilfs2: eliminate kmap and kmap_atomic calls"
"nilfs2: fix kernel bug at submit_bh_wbc()"
- Nathan Chancellor has updated our build tools requirements in the
series "Bump the minimum supported version of LLVM to 13.0.1".
- Muhammad Usama Anjum continues with the selftests maintenance work in
the series "selftests/mm: Improve run_vmtests.sh".
- Oleg Nesterov has done some maintenance work against the signal code
in the series "get_signal: minor cleanups and fix".
Plus the usual shower of singleton patches in various parts of the tree.
Please see the individual changelogs for details.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCZfMnvgAKCRDdBJ7gKXxA
jjKMAP4/Upq07D4wjkMVPb+QrkipbbLpdcgJ++q3z6rba4zhPQD+M3SFriIJk/Xh
tKVmvihFxfAhdDthseXcIf1nBjMALwY=
=8rVc
-----END PGP SIGNATURE-----
Merge tag 'mm-nonmm-stable-2024-03-14-09-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull non-MM updates from Andrew Morton:
- Kuan-Wei Chiu has developed the well-named series "lib min_heap: Min
heap optimizations".
- Kuan-Wei Chiu has also sped up the library sorting code in the series
"lib/sort: Optimize the number of swaps and comparisons".
- Alexey Gladkov has added the ability for code running within an IPC
namespace to alter its IPC and MQ limits. The series is "Allow to
change ipc/mq sysctls inside ipc namespace".
- Geert Uytterhoeven has contributed some dhrystone maintenance work in
the series "lib: dhry: miscellaneous cleanups".
- Ryusuke Konishi continues nilfs2 maintenance work in the series
"nilfs2: eliminate kmap and kmap_atomic calls"
"nilfs2: fix kernel bug at submit_bh_wbc()"
- Nathan Chancellor has updated our build tools requirements in the
series "Bump the minimum supported version of LLVM to 13.0.1".
- Muhammad Usama Anjum continues with the selftests maintenance work in
the series "selftests/mm: Improve run_vmtests.sh".
- Oleg Nesterov has done some maintenance work against the signal code
in the series "get_signal: minor cleanups and fix".
Plus the usual shower of singleton patches in various parts of the tree.
Please see the individual changelogs for details.
* tag 'mm-nonmm-stable-2024-03-14-09-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (77 commits)
nilfs2: prevent kernel bug at submit_bh_wbc()
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
ocfs2: enable ocfs2_listxattr for special files
ocfs2: remove SLAB_MEM_SPREAD flag usage
assoc_array: fix the return value in assoc_array_insert_mid_shortcut()
buildid: use kmap_local_page()
watchdog/core: remove sysctl handlers from public header
nilfs2: use div64_ul() instead of do_div()
mul_u64_u64_div_u64: increase precision by conditionally swapping a and b
kexec: copy only happens before uchunk goes to zero
get_signal: don't initialize ksig->info if SIGNAL_GROUP_EXIT/group_exec_task
get_signal: hide_si_addr_tag_bits: fix the usage of uninitialized ksig
get_signal: don't abuse ksig->info.si_signo and ksig->sig
const_structs.checkpatch: add device_type
Normalise "name (ad@dr)" MODULE_AUTHORs to "name <ad@dr>"
dyndbg: replace kstrdup() + strchr() with kstrdup_and_replace()
list: leverage list_is_head() for list_entry_is_head()
nilfs2: MAINTAINERS: drop unreachable project mirror site
smp: make __smp_processor_id() 0-argument macro
fat: fix uninitialized field in nostale filehandles
...
This has been a very quiet release, mostly cleanups, API updates and
simple device additions. I messed up slightly and there are a couple of
duplicated commits resulting from me leaving things in my inbox which
didn't seem worth removing by the time I noticed them.
- Conversion of several drivers to GPIO descriptors.
- Build out the features of of the MP8859 driver.
- Support for Qualcomm PM4125 and PM6150.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXvFPUACgkQJNaLcl1U
h9C11wf+LkEBZ/oaidhjWlDdnd6oVHCVG7du5YXRSDcobm9dqigfnhRPvcF3WqlQ
DfPBq5/VN/yCAxD3tsUS+bhPfCEMfSnEHN4uaYy7NjLulW3zh++Dxib3FPD7HURY
aw5u8gm4AuB+x4nJOtrA6tiBisfHyCM7uSIfnUcs0LVlksCibdOe0OfHVsO2BNW+
gbLxZc8gr5VdORfHqb6oeUtcoiA/2gALNvdagMooguzolDtVEs1yLQkbD4CCOGHg
EPqE7YxdJrTOtbd7hiR5z2G8plPqmsbCG//Jb9jJuEAtefm57pyJ5SfMBGKs0hS9
p/o5Vk4ygghArRnl0KsItgphFCZt0A==
=GuVG
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This has been a very quiet release, mostly cleanups, API updates and
simple device additions. I messed up slightly and there are a couple
of duplicated commits resulting from me leaving things in my inbox
which didn't seem worth removing by the time I noticed them.
- Conversion of several drivers to GPIO descriptors
- Build out the features of of the MP8859 driver
- Support for Qualcomm PM4125 and PM6150"
* tag 'regulator-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (31 commits)
regulator: lp8788-buck: fix copy and paste bug in lp8788_dvs_gpio_request()
regulator: core: make regulator_class constant
regulator: da9121: Remove unused of_gpio.h
regulator: userspace-consumer: add module device table
regulator: dt-bindings: gpio-regulator: Fix "gpios-states" and "states" array bounds
regulator: mp8859: Implement set_current_limit()
regulator: mp8859: Report slew rate
regulator: mp8859: Support status and error readback
regulator: mp8859: Support active discharge control
regulator: mp8859: Support mode operations
regulator: mp8859: Support enable control
regulator: mp8859: Validate and log device identifier information
regulator: mp8859: Specify register accessibility and enable caching
regulator: max8998: Convert to GPIO descriptors
regulator: max8997: Convert to GPIO descriptors
regulator: lp8788-buck: Fully convert to GPIO descriptors
regulator: da9055: Fully convert to GPIO descriptors
regulator: max8973: Finalize switch to GPIO descriptors
regulator: dt-bindings: qcom,usb-vbus-regulator: add support for PM4125
regulator: dt-bindings: qcom,usb-vbus-regulator: add support for PM4125
...
Previously, performing an exclusive get on an already-enabled regulator
resulted in inconsistent state initialization between child and parent
regulators. While the child's counts were updated, its parent's counters
remained unaffected.
Consequently, attempting to disable an already-enabled exclusive regulator
triggered unbalanced disables warnings from its parent regulator.
This commit addresses the issue by propagating the enable state to the
parent regulator using a regulator_enable call. This ensures consistent
state management across the regulator hierarchy, preventing warnings!
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://msgid.link/r/20240312091638.1266167-1-kory.maincent@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 43a7206b09 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the regulator_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://msgid.link/r/20240305-class_cleanup-regulator-v1-1-4950345d6d8f@marliere.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The linear ranges aren't really matching what they should be. Indeed,
the range is inclusive of the min value, so it makes sense the previous
range does NOT include the max step value representing the min value of
the range in question.
Since 3.4V is represented by the decimal value 232, the previous range
max step value should be 231 and not 232.
No expected change in behavior since 3.4V was mapped with step 232 from
the first range but is now mapped with step 232 from the second range.
While at it, remove the incorrect comment from the second range.
Fixes: f991a220a4 ("regulator: rk808: add rk806 support")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-2-3904ab70d250@theobroma-systems.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The linear ranges aren't really matching what they should be. Indeed,
the range is inclusive of the min value, so it makes sense the previous
range does NOT include the max step value representing the min value of
the range in question.
Since 1.5V is represented by the decimal value 160, the previous range
max step value should be 159 and not 160. Similarly, 3.4V is represented
by the decimal value 236, so the previous range max value should be 235
and not 237.
The only change in behavior this makes is that this actually modeled
the ranges to map step with decimal value 237 with 3.65V instead of
3.4V (the max supported by the HW).
Fixes: f991a220a4 ("regulator: rk808: add rk806 support")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-1-3904ab70d250@theobroma-systems.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Mark Brown <broonie@kernel.org>:
I had cause to look at the MP8859 driver together with the datasheet and
noticed a few small issues and missing features. This series deals with
many of these issues, the device also has support for interrupts which
are not implemented here.
Merge series from Linus Walleij <linus.walleij@linaro.org>:
Despite the work to convert the regulator core to GPIO
descriptors, there are some outliers that use legacy GPIO
numbers in various ways. Convert them all over.
The userspace consumer can be built as a module but it cannot be
automatically probed as there is no device table to match it up with
device tree nodes.
Add the missing macro so that the module can load automatically.
Fixes: 5c51d4afcf ("regulator: userspace-consumer: Handle regulator-output DT nodes")
Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
Link: https://msgid.link/r/20240226160554.1453283-1-jkeeping@inmusicbrands.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The mp8859 implements support for current limiting, provide support for
configuring this via the driver. The datasheet recommends that if the
device has hit the current limit then any changes should be implemented
via a ramp so we do so in the driver.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-8-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MP8859 implements voltage changes at the rate of 1mV/us, tell the core
about this so that it can provide appropriate delays on voltage changes.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-7-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MP8859 can report if it is in regulation and detect over temperature
conditions, report this information via the relevant regulator API
calls.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-6-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MP8859 can actively discharge the output when disabled, add support for
controlling this feature.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-5-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MP8859 provides mode control, implement the relevant regulator API
operations.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-4-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MP8859 provides a software enable control, support it in the
regulator driver.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-3-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Ensure that we are talking to a device which reports the expected ID
register information and log the OTP and revision information for
diagnostic purposes.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-2-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Avoid needless accesses to the hardware by caching register values that
we know, marking status registers as volatile as appropriate.
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/r/20240225-regulator-mp8859-v1-1-68ee2c839ded@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This rewrites the max8998 regulator driver to fetch the dvs
regulators as descriptors. This will likely mostly come from
the device tree since there are no in-tree users of the platform
data, but supplying GPIO descriptor tables from board files is
also possible if needed.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://msgid.link/r/20240220-descriptors-regulators-v1-5-097f608694be@linaro.org
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This rewrites the max8997 regulator driver to fetch the dvs
regulators as descriptors. This will likely mostly come from
the device tree since there are no in-tree users of the platform
data, but supplying GPIO descriptor tables from board files is
also possible if needed.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://msgid.link/r/20240220-descriptors-regulators-v1-4-097f608694be@linaro.org
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This converts the LP8788 BUCK regulator driver to use GPIO
descriptors.
BUCK1 can use one DVS GPIO and BUCK2 can use two DVS GPIOS,
and no more so just hardcode two GPIO descriptors into
the per-DVS state containers.
Obtain the descriptors from each regulators subdevice.
As there are no in-tree users, board files need to populate
descriptor tables for the buck regulator devices when
they want to use this driver. BUCK1 need a GPIO descriptor
at index 0 and BUCK2 needs two GPIO descriptors at
indices 0 and 1.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://msgid.link/r/20240220-descriptors-regulators-v1-3-097f608694be@linaro.org
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The DA9055 regulator was touched before, requireing enable GPIOs
to be passed from pdata.
As we have a device for each regulator, obtain the three gpios
ren ("regulator enable"), rsel ("regulator select") and the
ena ("enable") GPIO associated with the regulator enable
directly from the device and cut down on the amount of
GPIO numbers passed as platform data.
The ren and rsel are just requested as inputs: these are
actually handled by hardware. The ena gpios are driven
actively by the regulator core.
There are no in-tree users, but the regulators are instantiated
from the (undocumed) device tree nodes with "dlg,da9055-regulator"
as compatible, and by simply adding regulator-enable-gpios,
regulator-select-gpios and enable-gpios to this DT node, all
will work as before.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://msgid.link/r/20240220-descriptors-regulators-v1-2-097f608694be@linaro.org
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dvs gpio was still using a legacy number passed from the
platform data. There are no in-tree users of the platform data
so just switch it to a gpio descriptor and obtain it in probe(),
the device tree users will work just as fine with this.
Drop the entirely unused enable_gpio from the platform data
as well. The device tree bindings mentions this but the driver
does not look for it and makes no use of it: it should probably
be implemented properly in a separate patch.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://msgid.link/r/20240220-descriptors-regulators-v1-1-097f608694be@linaro.org
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
LLVM moved their issue tracker from their own Bugzilla instance to GitHub
issues. While all of the links are still valid, they may not necessarily
show the most up to date information around the issues, as all updates
will occur on GitHub, not Bugzilla.
Another complication is that the Bugzilla issue number is not always the
same as the GitHub issue number. Thankfully, LLVM maintains this mapping
through two shortlinks:
https://llvm.org/bz<num> -> https://bugs.llvm.org/show_bug.cgi?id=<num>
https://llvm.org/pr<num> -> https://github.com/llvm/llvm-project/issues/<mapped_num>
Switch all "https://bugs.llvm.org/show_bug.cgi?id=<num>" links to the
"https://llvm.org/pr<num>" shortlink so that the links show the most up to
date information. Each migrated issue links back to the Bugzilla entry,
so there should be no loss of fidelity of information here.
Link: https://lkml.kernel.org/r/20240109-update-llvm-links-v1-3-eb09b59db071@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Fangrui Song <maskray@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Mykola Lysenko <mykolal@fb.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The variable possible_uV being assigned a value that is never read, the
control flow via the following goto statement takes a path where the
variable is not accessed. The assignment is redundant and can be removed.
Cleans up clang scan build warning:
drivers/regulator/core.c:3935:3: warning: Value stored to 'possible_uV'
is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://msgid.link/r/20240216134918.2108262-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The variable possible_uV being assigned a value that is never read, the
control flow via the following goto statement takes a path where the
variable is not accessed. The assignment is redundant and can be removed.
Cleans up clang scan build warning:
drivers/regulator/core.c:3935:3: warning: Value stored to 'possible_uV'
is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://msgid.link/r/20240216134918.2108262-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
One error path already used the dev_err_probe() helper. Make use of it
in the other error paths, too, for consistent output. This results in a
more compact source code and symbolic output of the error code.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/20240216071829.1513748-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
One error path already used the dev_err_probe() helper. Make use of it
in the other error paths, too, for consistent output. This results in a
more compact source code and symbolic output of the error code.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/20240216071829.1513748-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmXSbvkeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGi3kH/iM5AcKeQfee07to
TJP3WORLBt5UrUMgAQbJdNAruCj6brHA6YnZ6AjdhdNZ41RO06h69kTpb+y/CYJz
+ogGK5qhWsC8ETM6rJCioo8uI4GU70p84fGiMfLw8o6vUvmtyI5qH3531Y30Edxt
qqMVtQrVe9J5JcHQjJ/mQo8nAuvZdQQGM90zLGqFP+JheP3CzsCokraIITqoebDC
PCVAsnSbXT/uMjwSr03kdnMnnY++fxz/TyHb/QRMPq/4xU8nz0Z2hlOOYrVkOINu
lkIYtCDGTk0QR3hdDiO9yt+k1OsWi+oBkrhjAQmAk9x3riiXq1NKvZZLDArt7PH5
gSyo9sE=
=h5Ei
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXTiOkACgkQJNaLcl1U
h9BL6wf6Au7vW2WbAyUQ7Mz2kR10vnhab8kBLrI26nOm8YTbVC5pEmsXP9Cya0hC
CCTReZ9AhJvKVvTse68+XYMwJVeW4JOhGKi9Gm4zJY6/FUSIpd6PL9qbXNPUDQac
L5RXxF1HMUEWClqGrd2D8n8gBVSZ1nE2bvvqY8OnSUJKwCjkYMNPrSvsnzJlQREY
gm0YKn06Hicm3qYrwi7ivpIQSumjSQD3aR6sZpL1SSsHgan8JHSarR8Fd7IxB13S
X5ekFL6dOKs79E/oVZC4Q+SOKox1wnINxo9d3jE2pgWE0tfWrQa9yvgdObNRSgjg
FuxWXfeFVKXY9QOtT46HjdjeC28eCw==
=Vtgv
-----END PGP SIGNATURE-----
regulator: Merge up v6.8-rc5
There are dependencies on the PWM fixes for some new work on the PWM
driver.
The max5970 datasheet gives the impression that IRQ status bits must
be cleared by writing a one to set bits, as those are marked with 'R/C',
however tests showed that a zero must be written.
Fixes an IRQ storm as the interrupt handler actually clears the IRQ
status bits.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://msgid.link/r/20240130150257.3643657-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We can't use devm_platform_ioremap_resource_byname() to remap the
interrupt register that can be shared between
regulator-abb-{ivahd,dspeve,gpu} drivers instances.
The combined helper introduce a call to devm_request_mem_region() that
creates a new busy resource region on PRM_IRQSTATUS_MPU register
(0x4ae06010). The first devm_request_mem_region() call succeeds for
regulator-abb-ivahd but fails for the two other regulator-abb-dspeve
and regulator-abb-gpu.
# cat /proc/iomem | grep -i 4ae06
4ae06010-4ae06013 : 4ae07e34.regulator-abb-ivahd int-address
4ae06014-4ae06017 : 4ae07ddc.regulator-abb-mpu int-address
regulator-abb-dspeve and regulator-abb-gpu are missing due to
devm_request_mem_region() failure (EBUSY):
[ 1.326660] ti_abb 4ae07e30.regulator-abb-dspeve: can't request region for resource [mem 0x4ae06010-0x4ae06013]
[ 1.326660] ti_abb: probe of 4ae07e30.regulator-abb-dspeve failed with error -16
[ 1.327239] ti_abb 4ae07de4.regulator-abb-gpu: can't request region for resource [mem 0x4ae06010-0x4ae06013]
[ 1.327270] ti_abb: probe of 4ae07de4.regulator-abb-gpu failed with error -16
>From arm/boot/dts/dra7.dtsi:
The abb_mpu is the only instance using its own interrupt register:
(0x4ae06014) PRM_IRQSTATUS_MPU_2, ABB_MPU_DONE_ST (bit 7)
The other tree instances (abb_ivahd, abb_dspeve, abb_gpu) share
PRM_IRQSTATUS_MPU register (0x4ae06010) but use different bits
ABB_IVA_DONE_ST (bit 30), ABB_DSPEVE_DONE_ST( bit 29) and
ABB_GPU_DONE_ST (but 28).
The commit b36c6b1887 ("regulator: ti-abb: Make use of the helper
function devm_ioremap related") overlooked the following comment
implicitly explaining why devm_ioremap() is used in this case:
/*
* We may have shared interrupt register offsets which are
* write-1-to-clear between domains ensuring exclusivity.
*/
Fixes and partially reverts commit b36c6b1887 ("regulator: ti-abb:
Make use of the helper function devm_ioremap related").
Improve the existing comment to avoid further conversion to
devm_platform_ioremap_resource_byname().
Fixes: b36c6b1887 ("regulator: ti-abb: Make use of the helper function devm_ioremap related")
Signed-off-by: Romain Naour <romain.naour@skf.com>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Link: https://msgid.link/r/20240123111456.739381-1-romain.naour@smile.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Odroid-C1 uses a Monolithic Power Systems MP2161 controlled via PWM for
the VDDEE voltage supply of the Meson8b SoC. Commit 6b9352f3f8 ("pwm:
meson: modify and simplify calculation in meson_pwm_get_state") results
in my Odroid-C1 crashing with memory corruption in many different places
(seemingly at random). It turns out that this is due to a currently not
supported corner case.
The VDDEE regulator can generate between 860mV (duty cycle of ~91%) and
1140mV (duty cycle of 0%). We consider it to be enabled by the bootloader
(which is why it has the regulator-boot-on flag in .dts) as well as
being always-on (which is why it has the regulator-always-on flag in
.dts) because the VDDEE voltage is generally required for the Meson8b
SoC to work. The public S805 datasheet [0] states on page 17 (where "A5"
refers to the Cortex-A5 CPU cores):
[...] So if EE domains is shut off, A5 memory is also shut off. That
does not matter. Before EE power domain is shut off, A5 should be shut
off at first.
It turns out that at least some bootloader versions are keeping the PWM
output disabled. This is not a problem due to the specific design of the
regulator: when the PWM output is disabled the output pin is pulled LOW,
effectively achieving a 0% duty cycle (which in return means that VDDEE
voltage is at 1140mV).
The problem comes when the pwm-regulator driver tries to initialize the
PWM output. To do so it reads the current state from the hardware, which
is:
period: 3666ns
duty cycle: 3333ns (= ~91%)
enabled: false
Then those values are translated using the continuous voltage range to
860mV.
Later, when the regulator is being enabled (either by the regulator core
due to the always-on flag or first consumer - in this case the lima
driver for the Mali-450 GPU) the pwm-regulator driver tries to keep the
voltage (at 860mV) and just enable the PWM output. This is when things
start to go wrong as the typical voltage used for VDDEE is 1100mV.
Commit 6b9352f3f8 ("pwm: meson: modify and simplify calculation in
meson_pwm_get_state") triggers above condition as before that change
period and duty cycle were both at 0. Since the change to the pwm-meson
driver is considered correct the solution is to be found in the
pwm-regulator driver. Update the duty cycle during driver probe if the
regulator is flagged as boot-on so that a call to pwm_regulator_enable()
(by the regulator core during initialization of a regulator flagged with
boot-on) without any preceding call to pwm_regulator_set_voltage() does
not change the output voltage.
[0] https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://msgid.link/r/20240113224628.377993-4-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If a PWM output is disabled then it's voltage has to be calculated
based on a zero duty cycle (for normal polarity) or duty cycle being
equal to the PWM period (for inverted polarity). Add support for this
to pwm_regulator_get_voltage().
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://msgid.link/r/20240113224628.377993-3-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Continuous regulators can be configured to operate only in a certain
duty cycle range (for example from 0..91%). Add a check to error out if
the duty cycle translates to an unsupported (or out of range) voltage.
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://msgid.link/r/20240113224628.377993-2-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For no apparent reason (as there's just one RPM per SoC), all vregs
currently store a copy of a pointer to smd_rpm. Introduce a single,
global one to save up on space in each definition.
bloat-o-meter reports a slight uptick:
Total: Before=44008, After=44080, chg +0.16%
However the saved n * sizeof(ptr) for every dynamically allocated
regulator quickly makes up for it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://msgid.link/r/20240109-rpm_vreg_cleanup-v3-1-fa0201029f78@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This contains a bunch of cleanups and simplifications across the board,
as well as a number of small fixes.
Perhaps the most notable change here is the addition of an API that
allows PWMs to be used in atomic contexts, which is useful when time-
critical operations are involved, such as using a PWM to generate IR
signals.
Finally, I have decided to step down as PWM subsystem maintainer. Due to
other responsibilities I have lately not been able to find the time that
the subsystem deserves and Uwe, who has been helping out a lot for the
past few years and has many things planned for the future, has kindly
volunteered to take over. I have no doubt that he will be a suitable
replacement.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmWhYQAZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zobK8EACtzJX+AeoTkN2S671A7QoG
IGl9mrFhvrqN/6syigAIU8ZGOgb5uScZDH58PeTXH/oGEMn+bhQ9MK7JyWF5BUzF
I8p6CqaVjG66LsfWz1m8AEAl/0N2Sc2032fWQSJB0o8qgYH0ZRBKc1j371Zm2DgD
HT78pZJDSnyCnltPKjbDLShRfBwGINspmbihZKFa6yxrPbvADixCTo19b9Pk8XGa
S9k2R/9S/QKPxvB+3DiZAHFstwoTn2p+1IBsg+hp/jLniw8XidZp2Rq0RJuwTjqO
jVQDnOFOqNBa3VQccvNe23rDaKUkrmYwk+zzuFF27URam2Gp9wHZ8Y86WPSO5TA9
ftNsoeW++R25PBsOVZFGMU9r9aI9XI1tNyVuv2blNc0yr1fNSRzwjcELzLzG2myp
gHgdayJofnvlKM7JV5ZDY6BDPwTP9jfDRdZOqKKNUeB8e9IiQD9JtAV9P+EL/5Hl
C+7mh5Xb17bVlczWHqNkTd89Omp+Eu2z5BMfJyiQWQ2lzZpxOkBwB0nrlPshZpPi
hz5IhsGjREkEfNV2qz/YDEyaj+CAYO8toitFGt5HeAYTftuG4WD49rHE5VQ8nhwg
P9XpWNFHK2EtpU3/BRuupWHZRVd7MU4kMx4WQvWZGOFEqc9DYaC29ynk6sK0ryaC
ba8U4gpBS66d3wNvVpkN3A==
=pIh8
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This contains a bunch of cleanups and simplifications across the
board, as well as a number of small fixes.
Perhaps the most notable change here is the addition of an API that
allows PWMs to be used in atomic contexts, which is useful when time-
critical operations are involved, such as using a PWM to generate IR
signals.
Finally, I have decided to step down as PWM subsystem maintainer. Due
to other responsibilities I have lately not been able to find the time
that the subsystem deserves and Uwe, who has been helping out a lot
for the past few years and has many things planned for the future, has
kindly volunteered to take over. I have no doubt that he will be a
suitable replacement"
* tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
MAINTAINERS: pwm: Thierry steps down, Uwe takes over
pwm: linux/pwm.h: fix Excess kernel-doc description warning
pwm: Add pwm_apply_state() compatibility stub
pwm: cros-ec: Drop documentation for dropped struct member
pwm: Drop two unused API functions
pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs
pwm: meson: Simplify using dev_err_probe()
pwm: stmpe: Silence duplicate error messages
pwm: Reduce number of pointer dereferences in pwm_device_request()
pwm: crc: Use consistent variable naming for driver data
pwm: omap-dmtimer: Drop locking
dt-bindings: pwm: ti,pwm-omap-dmtimer: Update binding for yaml
media: pwm-ir-tx: Trigger edges from hrtimer interrupt context
pwm: bcm2835: Allow PWM driver to be used in atomic context
pwm: Make it possible to apply PWM changes in atomic context
pwm: renesas: Remove unused include
pwm: Replace ENOTSUPP with EOPNOTSUPP
pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
pwm: Stop referencing pwm->chip
pwm: Update kernel doc for struct pwm_chip
...
Previously, the sequence number in the regulator event subsystem was
updated without atomic operations, potentially leading to race
conditions. This commit addresses the issue by making the sequence
number atomic.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://msgid.link/r/20240104141314.3337037-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:
int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
int pwm_apply_atomic(struct pwm *, struct pwm_state *);
This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Merge series from Fenglin Wu <quic_fenglinw@quicinc.com>:
There are 2 PM8010 PMICs present in sm8550-mtp/sm8550-qrd boards and
each of them exposes 7 LDOs. Add RPMH regulator support for them.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
Changes in v2:
- Updated subject prefix in the dt-binding commit and fixed the typo.
- Separate the DTS commit with board name prefixes.
- Link to v1: https://lore.kernel.org/r/20231211-pm8010-regulator-v1-0-571e05fb4ecc@quicinc.com
---
Fenglin Wu (5):
regulator: qcom-rpmh: extend to support multiple linear voltage ranges
regulator: dt-bindings: qcom,rpmh: add compatible for pm8010
regulator: qcom-rpmh: add support for pm8010 regulators
arm64: dts: qcom: sm8550-mtp: Add pm8010 regulators
arm64: dts: qcom: sm8550-qrd: add PM8010 regulators
.../bindings/regulator/qcom,rpmh-regulator.yaml | 14 ++
arch/arm64/boot/dts/qcom/sm8550-mtp.dts | 120 ++++++++++++++
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 120 ++++++++++++++
drivers/regulator/qcom-rpmh-regulator.c | 177 ++++++++++++++++++---
4 files changed, 405 insertions(+), 26 deletions(-)
---
base-commit: 753e4d5c43
change-id: 20231205-pm8010-regulator-0348cb19087a
Best regards,
--
Fenglin Wu <quic_fenglinw@quicinc.com>
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PM8010
PMIC. It has 7 LDOs with 3 different types, LDO1 - LDO2 are L502
NMOS LDOs, LDO5 and LDO7 are L502 PMOS LDOs, LDO3/LDO4/LDO6 are
L502 PMOS LDO for low noise applications. Also, LDO3 - LDO7 don't
support LPM.
Suggested-by: David Collins <quic_collinsd@quicinc.com>
Reviewed-by: David Collins <quic_collinsd@quicinc.com>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Link: https://msgid.link/r/20231214-pm8010-regulator-v2-3-82131df6b97b@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Update rpmh_vreg_hw_data to support multiple linear voltage ranges for
potential regulators which have discrete voltage program ranges.
Suggested-by: David Collins <quic_collinsd@quicinc.com>
Reviewed-by: David Collins <quic_collinsd@quicinc.com>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Link: https://msgid.link/r/20231214-pm8010-regulator-v2-1-82131df6b97b@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/1f7bbc545829a1cc3df40be0424fe46d7449fb72.1701778038.git.u.kleine-koenig@pengutronix.de
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/d9954f02ae51b1b0b0077c710d16bfaeafa216ec.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/89c5f261707bf178e1508cf5dd55121f0da2dc3f.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/ced2a73a1aeca3f33d4b194e4dbe2672ad84a50a.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/2e96cf99c8d97b728d891a745e8f94ee39fbfee8.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/fcaa42d7dd707031ed8dd9e8c28483891b879965.1701778038.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/639e796b36815a219ff1172cc758ba7378211d74.1701778038.git.u.kleine-koenig@pengutronix.de
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/76c7af01e2c8b3ab6585a04bc3f0d163fbb7fdf7.1701778038.git.u.kleine-koenig@pengutronix.de
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit introduces netlink event support to the regulator subsystem.
Changes:
- Introduce event.c and regnl.h for netlink event handling.
- Implement reg_generate_netlink_event to broadcast regulator events.
- Update Makefile to include the new event.c file.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Dang Huynh <danct12@riseup.net>:
PM8937 is a power management IC. It is used in various boards with
MSM8917, MSM8937, MSM8940 and APQ variants.
Pointer pdata is being initialized with a value that is never read. It is
being re-assigned later on with the return from a devm_kzalloc call.
Remove the redundant initialization, cleans up clang scan build warning:
drivers/regulator/palmas-regulator.c:1597:36: warning: Value stored
to 'pdata' during its initialization is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20231111195330.338324-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The use_count of a regulator should only be incremented when the
enable_count changes from 0 to 1. Similarly, the use_count should
only be decremented when the enable_count changes from 1 to 0.
In the previous implementation, use_count was sometimes decremented
to 0 when some consumer called unbalanced disable,
leading to unexpected disable even the regulator is enabled by
other consumers. With this change, the use_count accurately reflects
the number of users which the regulator is enabled.
This should make things more robust in the case where a consumer does
leak references.
Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This may be useful for debugging and develompent purposes, when there are
drivers that depend on regulators to be enabled but do not request them.
It is inspired from the clk_ignore_unused and pd_ignore_unused parameters,
that are used to keep firmware-enabled clocks and power domains on even if
these are not used by drivers.
The parameter is not expected to be used in normal cases and should not be
needed on a platform with proper driver support.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add 'uv_survival_time' field to regulation_constraints for specifying
survival time post critical under-voltage event. Update the regulator
notifier call chain and Device Tree property parsing to use this new
field, allowing a configurable timeout before emergency shutdown.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Handle under-voltage events for crucial regulators to maintain system
stability and avoid issues during power drops.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8937 is found on boards with MSM8917, MSM8937, MSM8940 SoCs and
APQ variants.
It provides 6 SMPS (two are controlled by SPMI) and 23 LDO regulators.
Signed-off-by: Dang Huynh <danct12@riseup.net>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231106-pm8937-v1-5-ec51d9eeec53@riseup.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8937 has 4 HFSMPS, 2 FTSMPS2.5 (for controlling APC voltage)
and 23 LDO regulators.
Add the configuration for this chip.
Signed-off-by: Dang Huynh <danct12@riseup.net>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231106-pm8937-v1-3-ec51d9eeec53@riseup.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Utilize the integrated 10-bit ADC in Max5970/Max5978 to enable voltage
and current monitoring. This feature is seamlessly integrated through
the hwmon subsystem.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20231027152830.1269895-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The type of the smps4 regulator from pm8550ve is actually FTSMPS525
medium voltage. So fix it accordingly.
Fixes: e6e3776d68 ("regulator: qcom-rpmh: Add support for PM8550 regulators")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20231024134626.2364426-1-abel.vesa@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support from RPMH regulators found in PMC8380 for SC8380XP platform.
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231025135550.13162-3-quic_sibis@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add interrupt support for under-voltage notification. This functionality
can be used on systems capable to detect under-voltage state and having
enough capacity to let the SoC do some emergency preparation.
This change enforce default policy to shutdown system as soon as
interrupt is triggered.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231025084614.3092295-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203442.2699322-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use preferred i2c_get_match_data() instead of of_match_device() to get
the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203429.2699039-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If probe is reached, we've already matched the device and in the case of
DT matching, the struct device_node pointer will be set. Therefore, there
is no need to call of_match_device() in probe.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203507.2699826-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct da9063_regulators.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175207.work.576-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct da9062_regulators.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175330.work.066-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT bindings for MT6366 regulator defines the supply names for the
PMIC.
Add support for them by adding .supply_name field settings for each
regulator. The buck regulators each have their own supply whose name
can be derived from the regulator name. The LDOs have shared supplies.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-12-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When support for the MT6366 PMIC regulators was added, it was assumed
that it had the same functionality as MT6358. In reality there are
differences. A few regulators have different ranges, or were renamed
and repurposed, or removed altogether.
Add the 3 regulators that were missing from the original submission.
These are added for completeness. VSRAM_CORE is not used in existing
projects. VM18 and VMDDR feed DRAM related consumers, and are not used
in-kernel.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230928085537.3246669-11-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The VCN18 regulator on the MT6366 (only) actually has a wide
configurable range of voltages, even though its name suggests a fixed
output voltage.
Convert it from a fixed LDO to a configurable LDO. Its range of settings
is the same as the VM18 regulator, which is missing and will be added in
a subsequent patch.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-10-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The new MT6366 binding does away with the type prefix ("buck_", "ldo_")
in the regulator node names. This better matches the PMIC pin names.
Remaining underscores in names are also replaced with hyphens.
Drop the type prefixes and replace remaining underscores to match the
MT6366 binding.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-9-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT bindings for MT6358 regulator now defines the supply names for the
PMIC.
Add support for them by adding .supply_name field settings for each
regulator.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-8-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The (undocumented) possible values for the buck operating modes on the
MT6358 are the same as those on the MT6397, both for the device tree
bindings and the actual hardware register values.
Reuse the macros for the MT6397 PMIC in the MT6358 regulator driver by
including the mt6397-regulator.h binding header and replacing the
existing macros. This aligns it with other PMIC.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-7-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the necessary definitions for the PMA8084 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-6-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the necessary definitions for the PM8019 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-4-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the necessary definitions for the PM8909 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-2-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
When fixing a memory leak in commit d3c731564e ("regulator: plug
of_node leak in regulator_register()'s error path") it moved the
device_initialize() call earlier, but did not move the `dev->class`
initialization. The bug was spotted and fixed by reverting part of
the commit (in commit 5f4b204b6b "regulator: core: fix kobject
release warning and memory leak in regulator_register()") but
introducing a different bug: now early error paths use `kfree(dev)`
instead of `put_device()` for an already initialized `struct device`.
Move the missing assignments to just after `device_initialize()`.
Fixes: d3c731564e ("regulator: plug of_node leak in regulator_register()'s error path")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/b5b19cb458c40c9d02f3d5a7bd1ba7d97ba17279.1695077303.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Chen-Yu Tsai <wenst@chromium.org>:
Hi,
This is v3 of the remainder of the MT6358 regulator driver cleanup
and improvement series. v1 can be found here [1]; v2 is here [2].
Changes since v2:
- Merged patches dropped
- Fixed up pickable linear ranges' selector values
- Collected tags
- Patch adding missing regulator definitions squashed into patch using
the definitions; recommended by Krzysztof on my MT6366 series.
- Remaining dts patch split out to be sent separately
Changes since v1:
- Merged patches dropped
- Added patch to move VCN33 regulator status sync after ID check
- Added patch to fix VCN33 sync fail error message
- Added patch to add missing register definitions
Various discrepancies were found while preparing to upstream MT8186
device trees, which utilize the MT6366 PMIC, that is also covered by
this driver.
Patches 1~3 should go through the regulator tree, and patch 4 through
the soc/mediatek tree.
** Note: patch 2 needs an ack from Lee for the mfd header change.
This v3 series can be seen as two parts. v1 had three parts, but one
part was fully merged, and then v2 gained another cleanup. v3 drops
the "fixing bogus regulators" part: driver changes are fully merged
and device tree change will be sent separately.
Part 1 - Robust chip ID checking (patch 1)
Angelo suggested making the driver fail to probe if an unexpected chip
ID was found. Patch 1 implements this.
Part 2 - Output voltage fine tuning support (patches 2, 3)
Many of the LDOs on these PMIC support an extra level of output voltage
fine tuning. Most default to no offset, but a couple have a non-zero
offset by default. Previously this was unaccounted for in the driver and
device tree constraints. On the outputs with non-zero offset, this ends
up becoming a discrepancy between the device tree and actual hardware.
These two patches adds support for this second level of tuning, modeled
as bunch of linear ranges. While it's unlikely we need this level of
control, it's nice to be able to read back the accurate hardware
settings.
Please have a look.
Thanks
ChenYu
[1] https://lore.kernel.org/linux-arm-kernel/20230609083009.2822259-1-wenst@chromium.org/
[2] https://lore.kernel.org/linux-mediatek/20230721082903.2038975-1-wenst@chromium.org/
Chen-Yu Tsai (3):
regulator: mt6358: Fail probe on unknown chip ID
regulator: mt6358: Add output voltage fine tuning to fixed regulators
regulator: mt6358: Add output voltage fine tuning to variable LDOs
drivers/regulator/mt6358-regulator.c | 304 ++++++++++++---------------
include/linux/mfd/mt6358/registers.h | 6 +
2 files changed, 144 insertions(+), 166 deletions(-)
--
2.42.0.283.g2d96d420d3-goog
Some of the LDO regulators in the MT6358/MT6366 have sparsely populated
voltage tables, supported by custom get/set operators. While it works,
it requires more code and an extra field to store the lookup table.
These LDOs also have fine voltage calibration settings that can slightly
boost the output voltage from 0 mV to 100 mV, in 10 mV increments.
These combined could be modeled as a pickable set of linear ranges. The
coarse voltage setting is modeled as the range selector, while each
range has 11 selectors, starting from the range's base voltage, up to
+100 mV, in 10mV increments.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230913082919.1631287-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The "fixed" LDO regulators found on the MT6358 and MT6366 PMICs have
either no voltage selection register, or only one valid setting.
However these do have a fine voltage calibration setting that can
slightly boost the output voltage from 0 mV to 100 mV, in 10 mV
increments.
Add support for this by changing these into linear range regulators.
Some register definitions that are missing are also added.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230913082919.1631287-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6358 and MT6366 PMICs, and likely many others from MediaTek, have
a chip ID register, making the chip semi-discoverable.
The driver currently supports two PMICs and expects to be probed on one
or the other. It does not account for incorrect mfd driver entries or
device trees. While these should not happen, if they do, it could be
catastrophic for the device. The driver should be sure the hardware is
what it expects.
Make the driver fail to probe if the chip ID presented is not a known
one.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Fixes: f0e3c6261a ("regulator: mt6366: Add support for MT6366 regulator")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230913082919.1631287-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mc13xxx_regulator_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230922175402.work.819-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The buck and linear range LDO (VSRAM_*) regulators share one set of ops.
This set includes support for get/set mode. However this only makes
sense for buck regulators, not LDOs. The callbacks were not checking
whether the register offset and/or mask for mode setting was valid or
not. This ends up making the kernel report "normal" mode operation for
the LDOs.
Create a new set of ops without the get/set mode callbacks for the
linear range LDO regulators.
Fixes: f67ff1bd58 ("regulator: mt6358: Add support for MT6358 regulator")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230920085336.136238-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The RK808 is already using the proper <linux/gpio/consumer.h>
header and includes the legacy headers <linux/gpio.h> and
<linux/of_gpio.h> for no reason, drop the includes.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230911-descriptors-regulator-v2-1-ce978c52c557@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
This patch series aims to add match data improvements for pv880x0
regulator driver.
These patches are only compile tested.
Use the correct field to fix wrong voltage range selection on regulators
such as tps6287x since the blamed commit.
Fixes: 269cb04b60 ("regulator: Use bitfield values for range selectors")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20230911-regulator-voltage-sel-v1-1-886eb1ade8d8@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
While at it, remove trailing comma in the terminator entry for OF/ID
table and drop a space from terminator entry for ID table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903160301.79111-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
While at it, drop blank lines before MODULE_DEVICE_TABLE* and remove
trailing comma in the terminator entry for OF/ID table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903154257.70800-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230826173841.91807-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert enum->pointer for data in the match tables, so that the hw
differences can be stored in pointer and there by simpily the code.
Add struct ltc3589_info for hw differences between the devices and replace
ltc3589_variant->ltc3589_info for data in the match table. Simplify the
probe() by replacing of_device_get_match_data() and ID lookup for
retrieving data by i2c_get_match_data(). Drop enum ltc3589_variant and
variant from struct ltc3589_info as there are no users.
While at it, dropped trailing comma in the terminator entries for ID
table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230828162830.97881-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
While at it, drop trailing comma in the terminator entry from ID
table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230828165447.106058-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify probe() by replacing of_device_get_match_data() and ID lookup for
retrieving match data by i2c_get_match_data().
While at it, use dev_fwnode() API instead of 'client->dev.of_node'.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230828164746.102992-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace pv88080_types->pv88080_compatible_regmap in OF/ID tables and
simplify the probe() by replacing of_match_node() and ID lookup for
retrieving match data by i2c_get_match_data(). After this there is
no user of enum pv88080_types. So drop it.
While at it, move OF table near to the user.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903164832.83077-3-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop of_match_ptr() from pv88080_regulator_driver and get rid of ugly
CONFIG_OF ifdeffery. This slightly increases the size of pv88080_dt_ids
on non-OF system and shouldn't be an issue.
Add mod_devicetable.h include.
While at it, remove trailing comma in the terminator entry for OF/ID
table.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903164832.83077-2-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A couple of fixes that came in during the merge window, both driver
specific - one for a bug that came up in testing, one for a bug due to a
misreading of the datasheet.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmT5wtcACgkQJNaLcl1U
h9D42Qf+LB9UYFJKAXPyLkpQYGHKbSaqz6hIMFWjmpsVjvuahI63wVRv/GoPZDIU
B1Zy8mrC4t37BK/CmjlwvxVFPuY+DaYTTBjjnSEnfrDsQZ+PgfIRmfqzxp/q6TYr
cpDOg/HrLkvfzNoTVtnUDz4Kn1l66OAMWXlwZ/AZEW8uD/JY172H7tBfjqDdzDvc
NCxKW0FO/pX07kc1IFaPl6UvZRqJLQUkYl7dKFl7PrG6Lzh1+FKQSUmtZY33Ndgd
LqFux/mc3jsV5E6Y0F899Lf1890VxzYHpbwT1QrHdaXhbqoACrQoaFfLfvd5YQLY
K9ncwzj8hNM87t0LYLH09lSsH5L2Xw==
=UyE6
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.6-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of fixes that came in during the merge window, both driver
specific - one for a bug that came up in testing, one for a bug due
to a misreading of the datasheet"
* tag 'regulator-fix-v6.6-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: tps6594-regulator: Fix random kernel crash
regulator: tps6287x: Fix n_voltages
Random kernel crash detected in TI CICD when regulator driver is added.
This is root caused to irq index increment being done twice causing
irq_data being allocated outside of the range.
- Rework tps6594_request_reg_irqs with correct index increment
- Adjust irq_data kmalloc size to the exact size needed for the device
This has been reported on TI mainline. No public bug report associated.
Reported-by: Udit Kumar <u-kumar1@ti.com>
Fixes: f17ccc5deb ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators")
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20230828-tps6594_random_boot_crash_fix-v1-1-f29cbf9ddb37@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 256 possible voltage settings for each range, not 256 possible
voltage settings in total.
Fixes: 15a1cd245d ("regulator: tps6287x: Fix missing .n_voltages setting")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com
Link: https://lore.kernel.org/r/20230829-tps-voltages-v1-1-7ba4f958a194@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org
Other tha new device support and some minor fixes this has been a really
quiet release, the only notable things are the new drivers. There's a
couple of MFDs among the new devices so the generic parts are pulled in:
- Support for Analog Devices MAX77831/57/59, Awinc AW37503, Qualcom
PMX75 and RFGEN, RealTek RT5733, RichTek RTQ2208 and Texas
Instruments TPS65086.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmTp6U4ACgkQJNaLcl1U
h9Cu4gf/RZZirDVcISmKrIYn95Dc838pHFe3tIK9Ehbwms/pzBWBzT0Eiy36g4Vd
1pUB6YJKJZIKLOfFAjmudGtT9C3Yrui+3cR3dPtxN793ixfCkT2RVdeaNJDCJ6xo
cPpAekMroDpMSczDvsTaqJzCXb4y+rjsAQ201w+WhegkSLk/yMsW7Y+a6wpaMjwt
qGD/+EDk/54aogPhrGvKq7uLwCgDo2A6HrU2rIIMHYnZuPaSjsPGcd0fZahlP7Mk
1b6/SSJ+KvN0XSAgBz4yFixECb0OG9p5ukpV17hwDAPBbNqLRp+O/o3LFLq+nsoY
yG3RpJQM6r3Bw3KqdxWF/e5sUNkEsQ==
=ZB93
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"Other than new device support and some minor fixes this has been a
really quiet release, the only notable things are the new drivers.
There's a couple of MFDs among the new devices so the generic parts
are pulled in:
- Support for Analog Devices MAX77831/57/59, Awinc AW37503, Qualcom
PMX75 and RFGEN, RealTek RT5733, RichTek RTQ2208 and Texas
Instruments TPS65086"
* tag 'regulator-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (68 commits)
regulator: userspace-consumer: Drop event support for this cycle
regulator: aw37503: Switch back to use struct i2c_driver's .probe()
dt-bindings: regulator: qcom,rpmh-regulator: allow i, j, l, m & n as RPMh resource name suffix
regulator: dt-bindings: Add Awinic AW37503
regulator: aw37503: add regulator driver for Awinic AW37503
regulator: tps65086: Select dedicated regulator config for chip variant
mfd: tps65086: Read DEVICE ID register 1 from device
regulator: raa215300: Update help description
regulator: raa215300: Add missing blank space
regulator: raa215300: Change rate from 32000->32768
regulator: db8500-prcmu: Remove unused declaration power_state_active_is_enabled()
regulator: raa215300: Add const definition
regulator: raa215300: Fix resource leak in case of error
regulator: rtq2208: Switch back to use struct i2c_driver's .probe()
regulator: lp872x: Fix Wvoid-pointer-to-enum-cast warning
regulator: max77857: Fix Wvoid-pointer-to-enum-cast warning
regulator: ltc3589: Fix Wvoid-pointer-to-enum-cast warning
regulator: qcom_rpm-regulator: Use devm_kmemdup to replace devm_kmalloc + memcpy
regulator: tps6286x-regulator: Remove redundant of_match_ptr() macros
regulator: pfuze100-regulator: Remove redundant of_match_ptr() macro
...
Drop commit 22475bcc20 ("regulator: userspace-consumer: Add regulator
event support") since Zev Weiss points out that it leaks the constants
we use for notifications out as ABI which isn't ideal, we should have
something more abstracted there. There's a definite need for this
feature but it needs some more work on the interface.
Signed-off-by: Mark Brown <broonie@kernel.org
Link: https://lore.kernel.org/r/20230824-regulator-remove-status-sysfs-v1-1-554956e8c1ca@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org
struct i2c_driver::probe_new is about to go away. Switch the driver to
use the probe callback with the same prototype.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Link: https://lore.kernel.org/r/20230824195617.8888-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org
Merge series from like@awinic.com:
Add regulator driver for the device Awinic AW37503 which is
single inductor - dual output power supply device. AW37503
device is designed to support general positive/negative
driven applications like TFT display panels.
Add regulator driver for the device Awinic AW37503 which is single
inductor - dual output power supply device. AW37503 device is
designed to support general positive/negative driven applications
like TFT display panels.
AW37503 regulator driver supports to enable/disable and set voltage
on its output.
Signed-off-by: Alec Li <like@awinic.com>
Link: https://lore.kernel.org/r/20230821035355.1269976-2-like@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some configurations differ between chip variants, e,g. the register
to control the on of state of LDOA1 and SWB2. Thus, it is necessary
to choose the correct configuration for a dedicated device.
If the wrong configuration was used, the LDOA1 output that was
disabled by the bootloader was enabled in Kernel again.
Each chip variant gets its dedicated configuration selected by
the chip ID previously collected from MFD probe function.
The VTT enum value (tps65086_regulators) is shifted because not all
chip variants have a separate SWB2 switch. Sometimes they are merged.
So the configuration possibilities differ, thus the regulator
configuration arrays have a different length.
Signed-off-by: Andre Werner <andre.werner@systec-electronic.com>
Link: https://lore.kernel.org/r/20230818083721.29790-5-andre.werner@systec-electronic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add const definition to the initialized local variable name to avoid
overriding. Also the second parameter in strscpy is const char * instead of
char *.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230816135550.146657-3-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The clk_register_clkdev() allocates memory by calling vclkdev_alloc() and
this memory is not freed in the error path. Similarly, resources allocated
by clk_register_fixed_rate() are not freed in the error path.
Fix these issues by using devm_clk_hw_register_fixed_rate() and
devm_clk_hw_register_clkdev().
After this, the static variable clk is not needed. Replace it with
local variable hw in probe() and drop calling clk_unregister_fixed_rate()
from raa215300_rtc_unregister_device().
Fixes: 7bce166308 ("regulator: Add Renesas PMIC RAA215300 driver")
Cc: stable@kernel.org
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230816135550.146657-2-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
struct i2c_driver::probe_new is about to go away. Switch the driver to
use the probe callback with the same prototype.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230814210759.26395-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
'id' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
lp872x.c:867:5: error: cast to smaller integer type 'enum lp872x_regulator_id' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810111914.204847-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'id' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:
max77857-regulator.c:56:24: error: cast to smaller integer type 'enum max77857_id' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810111914.204847-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'variant' is an enum, thus cast of pointer on 64-bit compile test with
W=1 causes:
ltc3589.c:394:22: error: cast to smaller integer type 'enum ltc3589_variant' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810111914.204847-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the helper function devm_kmemdup() rather than duplicating its
implementation, which helps to enhance code readability.
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230810114858.2103928-1-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver tps6286x-regulator depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove of_match_ptr() macros to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-8-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver pfuze100-regulator depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove the of_match_ptr() macro to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-7-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver mpq7920 depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove the of_match_ptr() macro to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-6-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver mcp16502 depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove of_match_ptr() macros to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-5-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver hi6421-regulator depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove of_match_ptr() macros to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-4-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver lp87565-regulator depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove of_match_ptr() macros to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-3-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the driver da9121-regulator depends on CONFIG_OF,
it makes no difference to wrap of_match_ptr() here.
Remove of_match_ptr() macros to clean it up.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Link: https://lore.kernel.org/r/20230809100428.2669817-2-chenjiahao16@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The bd71815 regulator driver includes the legacy header
<linux/gpio.h> for no reason, it is already using the proper
<linux/gpio/consumer.h> include. Drop the include.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230808-descriptors-regulator-v1-11-939b5e84dd18@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The bd71828 includes the legacy header <linux/gpio.h> for no
reason, drop the include. The documentation mentions GPIO but there
is no usage of the GPIO namespace.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230808-descriptors-regulator-v1-10-939b5e84dd18@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The max20086 regulator driver includes the legacy header
<linux/gpio.h> for no reason, it is already using the proper
<linux/gpio/consumer.h> include. Drop the include.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230808-descriptors-regulator-v1-8-939b5e84dd18@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The mcp16502 regulator driver includes the legacy header
<linux/gpio.h> for no reason, it is already using the proper
<linux/gpio/consumer.h> include. Drop the include.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230808-descriptors-regulator-v1-7-939b5e84dd18@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The RPI panel regulator driver includes the legacy header
<linux/gpio.h> for no reason, this is a driver and <linux/gpio/driver.h>
is already included. Drop the include.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230808-descriptors-regulator-v1-3-939b5e84dd18@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver depends on CONFIG_OF, so it is not necessary to use
of_match_ptr() here, and __maybe_unused can also be removed.
Even for drivers that do not depend on CONFIG_OF, it's almost always
better to leave out the of_match_ptr(), since the only thing it can
possibly do is to save a few bytes of .text if a driver can be used both
with and without it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230807134127.2380390-1-ruanjinjie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Alina Yu <alina_yu@richtek.com>:
This patch series adds support for RTQ2208 SubPMIC regulators.
The RTQ2208 is a multi-phase, programmable power management IC that
integrate with dual multi-configurable, synchronous buck converters
and two ldos. The bucks features wide output voltage range from 0.4V to 2.05V
and the capability to configure the corresponding power stages.
The LDO 12 is NLDO 515 low voltage type, so fix accordingly.
Fixes: e6e3776d68 ("regulator: qcom-rpmh: Add support for PM8550 regulators")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230801095702.2891127-1-abel.vesa@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The previous version of this driver included wildcards in file names and
descriptions. This patch renames the driver to only support MAX5970 and
MAX5978, which are the only chips that the driver actually supports.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230801102453.1798292-1-Naresh.Solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Two versions of the original patch were sent but V1 was merged instead
of V2 due to a mistake.
So update to V2.
The advantage of V2 is that it completely avoids dereferencing the pointer,
even just to take the address, which may fix problems with some compilers.
Both versions work on my gcc 9.4 but use the safer one.
Fixes: 98e2dd5f7a ("regulator: da9063: fix null pointer deref with partial DT config")
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Tested-by: Benjamin Bara <benjamin.bara@skidata.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230804083514.1887124-1-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>
When using low verion gcc(7.5) to build the max77857-regulator driver,
got the following error:
drivers/regulator/max77857-regulator.c:312:16: error: initializer element is not constant
.ramp_delay = max77857_ramp_table[0][0],
To fix this by introducing a macro RAMAP_DELAY_INIT_VAL to define the
value of max77857_ramp_table[0[0].
Fixes: af71cccade ("regulator: max77857: Add ADI MAX77857/59/MAX77831 Regulator Support")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230803113654.818640-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
max77857_regmap_config and max77857_driver are only used
in max77857-regulator.c now, change them to static.
Fixes: af71cccade ("regulator: max77857: Add ADI MAX77857/59/MAX77831 Regulator Support")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230801130354.552243-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Qualcomm MMIO-mapped reference voltage regulator is only present on
Qualcomm SoCs. Hence add a dependency on ARCH_QCOM, to prevent asking
the user about this driver when configuring a kernel without Qualcomm
SoC support.
Fixes: 7cbfbe2379 ("regulator: Introduce Qualcomm REFGEN regulator driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/60938ed138c9331ba3d2891fbd3b3d6644d3fbdc.1690300012.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
Right now the regulator helpers expect raw register values for the range
selectors. This is different from the voltage selectors, which are
normalized as bitfield values. This leads to a bit of confusion. Also,
raw values are harder to copy from datasheets or match up with them,
as datasheets will typically have bitfield values.
Make the helpers expect bitfield values, and convert existing users. The
field in regulator_desc is renamed to |linear_range_selectors_bitfield|.
This is intended to cause drivers added in the same merge window and
out-of-tree drivers using the incorrect variable and values to break,
preventing incorrect values being used on actual hardware and potentially
producing magic smoke.
Also include bitops.h explicitly for ffs(), and reorder the header include
statements. While at it, also replace module.h with export.h, since the
only use is EXPORT_SYMBOL_GPL.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230714081408.274567-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
