| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Core Frameworks:
- Fix 'mfd_of_node_list' OF node entry resource leak
New Drivers:
- Add support for Ocelot VSC7512 Networking Chip
- Add support for MediaTek MT6370 subPMIC
- Add support for Richtek RT5120 (I2C) PMIC
New Device Support:
- Add support for Rockchip RV1126 and RK3588 to Syscon
- Add support for Rockchip RK817 Battery Charger to RK808
- Add support for Silergy SY7636a Voltage Regulator to Simple MFD
- Add support for Qualcomm PMP8074 PMIC to QCOM SPMI
- Add support for Secure Update to Intel M10 BMC
New Functionality:
- Provide SSP type to Intel's LPSS (PCI) SPI driver
Fix-ups:
- Remove legacy / unused code; stmpe, intel_soc_pmic_crc, syscon
- Unify / simplify; intel_soc_pmic_crc
- Trivial reordering / spelling, etc; Makefile, twl-core
- Convert to managed resources; intel_soc_pmic_crc
- Use appropriate APIs; intel_soc_pmic_crc
- strscpy() conversion; htc-i2cpld, lpc_ich, mfd-core
- GPIOD conversion; htc-i2cpld, stmpe
- Add missing header file includes; twl4030-irq
- DT goodies; stmpe, mediatek,mt6370, x-powers,axp152,
aspeed,ast2x00-scu, mediatek,mt8195-scpsys, qcom,spmi-pmic, syscon,
qcom,tcsr, rockchip,rk817, sprd,ums512-glbreg, dlg,da9063
Bug Fixes:
- Properly check return values; sm501, htc-i2cpld
- Repair Two-Wire Bus Mode; da9062-core
- Fix error handling; intel_soc_pmic_core, fsl-imx25-tsadc, lp8788,
lp8788-irq"
* tag 'mfd-next-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (60 commits)
mfd: syscon: Remove repetition of the regmap_get_val_endian()
mfd: ocelot-spi: Add missing MODULE_DEVICE_TABLE
power: supply: Add charger driver for Rockchip RK817
dt-bindings: mfd: mt6370: Fix the indentation in the example
mfd: da9061: Fix Failed to set Two-Wire Bus Mode.
mfd: htc-i2cpld: Fix an IS_ERR() vs NULL bug in htcpld_core_probe()
dt-bindings: mfd: qcom,tcsr: Drop simple-mfd from IPQ6018
mfd: sm501: Add check for platform_driver_register()
dt-bindings: mfd: mediatek: Add scpsys compatible for mt8186
mfd: twl4030: Add missed linux/device.h header
dt-bindings: mfd: dlg,da9063: Add missing regulator patterns
dt-bindings: mfd: sprd: Add bindings for ums512 global registers
mfd: intel_soc_pmic_chtdc_ti: Switch from __maybe_unused to pm_sleep_ptr() etc
dt-bindings: mfd: syscon: Add rk3588 QoS register compatible
mfd: stmpe: Switch to using gpiod API
mfd: qcom-spmi-pmic: Add pm7250b compatible
dt-bindings: mfd: Add missing (unevaluated|additional)Properties on child nodes
mfd/omap1: htc-i2cpld: Convert to a pure GPIO driver
mfd: intel-m10-bmc: Add d5005 bmc secure update driver
dt-bindings: mfd: syscon: Drop ref from reg-io-width
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"The core work this time around has mostly been around the code to
manage regulator modes, simplifying the interface for configuring
modes to not take account of the voltage and as a side effect
resolving a bootstrapping issue on systems where we can't read the
voltage from the regulator.
Otherwise it's been quite a quiet release with some new drivers and a
devm helper:
- Make the load handling in the Qualcomm RPMH regulators much more
idiomatic and general cleanups to the handling of load
configuration
- devm helper for a combined get and enable operation
- Support for MediaTek MT6331, Qualcomm PM660, 660L and PM6125, Texas
Instruments TPS65219"
* tag 'regulator-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (45 commits)
dt-bindings: gpio-regulator: add vin-supply property support
regulator: gpio: Add input_supply support in gpio_regulator_config
regulator: tps65219: Fix is_enabled checking in tps65219_set_bypass
regulator: qcom,rpmh: add pm660 and pm660l pmics
regulator: qcom-rpmh: add pm660 and pm660l pmics
regulator: of: Fix kernel-doc
regulator: of: Fix kernel-doc
regulator: Add driver for MT6332 PMIC regulators
regulator: Add bindings for MT6332 regulator
regulator: Add driver for MT6331 PMIC regulators
regulator: Add bindings for MT6331 regulator
regulator: tps65219: Fix .bypass_val_on setting
regulator: qcom_rpm: Fix circular deferral regression
regulator: core: Prevent integer underflow
regulator: dt-bindings: qcom,rpmh: Indicate regulator-allow-set-load dependencies
regulator: bd9576: switch to using devm_fwnode_gpiod_get()
regulator: bd71815: switch to using devm_fwnode_gpiod_get()
regulator: core: Fix regulator supply registration with sysfs
regulator: tps65219: change tps65219_regulator_irq_types to static
regulator: core: Don't err if allow-set-load but no allowed-modes
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c updates from Wolfram Sang:
- 'remove' callback converted to return void. Big change with trivial
fixes all over the tree. Other subsystems depending on this change
have been asked to pull an immutable topic branch for this.
- new driver for Microchip PCI1xxxx switch
- heavy refactoring of the Mellanox BlueField driver
- we prefer async probe in the i801 driver now
- the rest is usual driver updates (support for more SoCs, some
refactoring, some feature additions)
* tag 'i2c-for-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (37 commits)
i2c: pci1xxxx: prevent signed integer overflow
i2c: acpi: Replace zero-length array with DECLARE_FLEX_ARRAY() helper
i2c: i801: Prefer async probe
i2c: designware-pci: Use standard pattern for memory allocation
i2c: designware-pci: Group AMD NAVI quirk parts together
i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch
docs: i2c: slave-interface: return errno when handle I2C_SLAVE_WRITE_REQUESTED
i2c: mlxbf: remove device tree support
i2c: mlxbf: support BlueField-3 SoC
i2c: cadence: Add standard bus recovery support
i2c: mlxbf: add multi slave functionality
i2c: mlxbf: support lock mechanism
macintosh/ams: Adapt declaration of ams_i2c_remove() to earlier change
i2c: riic: Use devm_platform_ioremap_resource()
i2c: mlxbf: remove IRQF_ONESHOT
dt-bindings: i2c: rockchip: add rockchip,rk3128-i2c
dt-bindings: i2c: renesas,rcar-i2c: Add r8a779g0 support
i2c: tegra: Add GPCDMA support
i2c: scmi: Convert to be a platform driver
i2c: rk3x: Add rv1126 support
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control updates from Rafael Wysocki:
"The most significant part of this update is the thermal control DT
initialization rework from Daniel Lezcano and the following conversion
of drivers to use the new API introduced by it
Apart from that, the maximum number of trip points in a thermal zone
is increased and there are some fixes and code cleanups
Specifics:
- Rework the device tree initialization, convert the drivers to the
new API and remove the old OF code (Daniel Lezcano)
- Fix return value to -ENODEV when searching for a specific thermal
zone which does not exist (Daniel Lezcano)
- Fix the return value inspection in of_thermal_zone_find() (Dan
Carpenter)
- Fix kernel panic when KASAN is enabled as it detects use after free
when unregistering a thermal zone (Daniel Lezcano)
- Move the set_trip ops inside the therma sysfs code (Daniel Lezcano)
- Remove unnecessary error message as it is already shown in the
underlying function (Jiapeng Chong)
- Rework the monitoring path and move the locks upper in the call
stack to fix some potentials race windows (Daniel Lezcano)
- Fix lockdep_assert() warning introduced by the lock rework (Daniel
Lezcano)
- Do not lock thermal zone mutex in the user space governor (Rafael
Wysocki)
- Revert the Mellanox 'hotter thermal zone' feature because it is
already handled in the thermal framework core code (Daniel Lezcano)
- Increase maximum number of trip points in the thermal core (Sumeet
Pawnikar)
- Replace strlcpy() with unused retval with strscpy() in the core
thermal control code (Wolfram Sang)
- Use module_pci_driver() macro in the int340x processor_thermal
driver (Shang XiaoJing)
- Use get_cpu() instead of smp_processor_id() in the intel_powerclamp
thermal driver to prevent it from crashing and remove unused
accounting for IRQ wakes from it (Srinivas Pandruvada)
- Consolidate priv->data_vault checks in int340x_thermal (Rafael
Wysocki)
- Check the policy first in cpufreq_cooling_register() (Xuewen Yan)
- Drop redundant error message from da9062-thermal (zhaoxiao)
- Drop of_match_ptr() from thermal_mmio (Jean Delvare)"
* tag 'thermal-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (55 commits)
thermal: core: Increase maximum number of trip points
thermal: int340x: processor_thermal: Use module_pci_driver() macro
thermal: intel_powerclamp: Remove accounting for IRQ wakes
thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
thermal: int340x_thermal: Consolidate priv->data_vault checks
thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register()
thermal: Drop duplicate words from comments
thermal: move from strlcpy() with unused retval to strscpy()
thermal: da9062-thermal: Drop redundant error message
thermal/drivers/thermal_mmio: Drop of_match_ptr()
thermal: gov_user_space: Do not lock thermal zone mutex
Revert "mlxsw: core: Add the hottest thermal zone detection"
thermal/core: Fix lockdep_assert() warning
thermal/core: Move the mutex inside the thermal_zone_device_update() function
thermal/core: Move the thermal zone lock out of the governors
thermal/governors: Group the thermal zone lock inside the throttle function
thermal/core: Rework the monitoring a bit
thermal/core: Rearm the monitoring only one time
thermal/drivers/qcom/spmi-adc-tm5: Remove unnecessary print function dev_err()
thermal/of: Remove old OF code
...
|
|
This is simillar as fixed-regulator.
Used to extract regulator parent from the device tree.
Without that property used, the parent regulator can be shut down (if not an always on).
Thus leading to inappropriate behavior:
On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion.
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220929132526.29427-2-jneanne@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a specific MFD_SY7636A config option.
As part of this change we can use MFD_SY7636A as a dependency for all
SY7636a components and also remove the name from MFD_SIMPLE_MFD_I2C as
it no longer needs to be selectable.
Signed-off-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20220525115554.430971-2-alistair@alistair23.me
|
|
Testing .enable cannot tell if a regulator is enabled or not, check return
value of .is_enabled() instead.
Also remove unneeded ret variable.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20220919122353.384171-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SDM630 and SDM660 both use RPM (not RPMh) for managing the PM660 and
PM660L. The SDM670 uses RPMh to manage them as PMIC 4s. To support the
SDM670, add the PM660 and PM660L to the RPMh regulator driver.
Link: https://android.googlesource.com/kernel/msm/+/58064f13c0a436a82c35f2e3b5a122d874ae5846%5E%21/#F0
Link: https://android.googlesource.com/kernel/msm/+/f676d3d24f9d802bfe63369167c4a8cc162b8950%5E%21/#F3
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220920223331.150635-3-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
drivers/regulator/ti-abb-regulator.c:161: warning: expecting prototype for ti_abb_wait_tranx(). Prototype was for ti_abb_wait_txdone() instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2206
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220919024830.111874-2-jiapeng.chong@linux.alibaba.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
drivers/regulator/of_regulator.c:689: warning: expecting prototype for of_parse_coupled regulator(). Prototype was for of_parse_coupled_regulator() instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2205#c0
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220919024830.111874-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Linux 6.0-rc5
|
|
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
In an effort to give some love to the apparently forgotten MT6795 SoC,
I am upstreaming more components that are necessary to support platforms
powered by this one apart from a simple boot to serial console.
This series adds support for the regulators found in MT6331 and MT6332
main/companion PMICs.
Adding support to each driver in each subsystem is done in different
patch series as to avoid spamming uninteresting patches to maintainers.
Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.
|
|
Add a driver for the regulators found in the MT6332 PMICs,
including six buck and four LDO regulators.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220913123456.384513-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a driver for the regulators found in the MT6331 PMIC.
This PMIC features six buck and 21 Low DropOut (LDO) regulators.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220913123456.384513-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The .bypass_val_on setting does not match the .bypass_mask setting, so the
.bypass_mask bit will never get set. Fix it by removing .bypass_val_on
setting, the regulator_set_bypass_regmap and regulator_get_bypass_regmap
helpers will use rdev->desc->bypass_mask as val_on if the val_on is 0.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20220828120153.1512508-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator)
does not come up if they are supplied by an SMPS-regulator. This
is not very strange since the regulators are registered in a long
array and the L-regulators are registered before the S-regulators,
and if an L-regulator defers, it will never get around to registering
the S-regulator that it needs.
See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts:
pm8058-regulators {
(...)
vdd_l13_l16-supply = <&pm8058_s4>;
(...)
Ooops.
Fix this by moving the PM8058 S-regulators first in the array.
Do the same for the PM8901 S-regulators (though this is currently
not causing any problems with out device trees) so that the pattern
of registration order is the same on all PMnnnn chips.
Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device")
Cc: stable@vger.kernel.org
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
By using a ratio of delay to poll_enabled_time that is not integer
time_remaining underflows and does not exit the loop as expected.
As delay could be derived from DT and poll_enabled_time is defined
in the driver this can easily happen.
Use a signed iterator to make sure that the loop exits once
the remaining time is negative.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"One core fix here improving the error handling on enable failure, plus
smaller fixes for the pfuze100 drive and the SPMI DT bindings"
* tag 'regulator-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix qcom,spmi-regulator schema
regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe()
regulator: core: Clean up on enable failure
|
|
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
While at it switch the rest of the calls to read properties in
bd957x_probe() to the generic device property API as well.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-9-b29adfb27a6c@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-8-b29adfb27a6c@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In "regulator: core: Resolve supply name earlier to prevent
double-init", we introduced a bug that prevented the regulator names
from registering properly with sysfs.
Reorder regulator_register such that supply names are properly resolved
and registered.
Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init")
Link: https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20220829165543.24856-1-christian@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
tps65219_regulator_irq_types is only used in tps65219-regulator.c now,
change it to static.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220826061941.1814723-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Apparently the device trees of some boards have the property
"regulator-allow-set-load" for some of their regulators but then they
don't specify anything for "regulator-allowed-modes". That's not
really legit, but...
...before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()") they used to get away with it, at
least on boards using RPMH regulators. That's because when a regulator
driver implements set_load() then the core doesn't look at
"regulator-allowed-modes" when trying to automatically adjust things
in response to the regulator's load. The core doesn't know what mode
we'll end up in, so how could it validate it?
Said another way: before commit efb0cb50c427 ("regulator: qcom-rpmh:
Implement get_optimum_mode(), not set_load()") some boards _were_
having the regulator mode adjusted despite listing no allowed
modes. After commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()") these same boards were now
getting an error returned when trying to use their regulators, since
simply enabling a regulator tries to update its load and that was
failing.
We don't really want to go back to the behavior from before commit
efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not
set_load()"). Boards shouldn't have been changing modes if no allowed
modes were listed. However, the behavior after commit efb0cb50c427
("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
isn't the best because now boards can't even turn their regulators on.
Let's choose to detect this case and return "no error" from
drms_uA_update(). The net-result will be _different_ behavior than we
had before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()"), but this new behavior seems more
correct. If a board truly needed the mode switched then its device
tree should be updated to list the allowed modes.
Reported-by: Andrew Halaney <ahalaney@redhat.com>
Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The get_optimum_mode() for regulator drivers is passed the input
voltage and output voltage as well as the current. This is because, in
theory, the optimum mode can depend on all three things.
It turns out that for all regulator drivers in mainline only the
current is looked at when implementing get_optimum_mode(). None of the
drivers take the input or output voltage into account. Despite the
fact that none of the drivers take the input or output voltage into
account, though, the regulator framework will error out before calling
into get_optimum_mode() if it doesn't know the input or output
voltage.
The above behavior turned out to be a probelm for some boards when we
landed commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()"). Before that change we'd have no
problems running drms_uA_update() for RPMH regulators even if a
regulator's input or output voltage was unknown. After that change
drms_uA_update() started to fail. This is because typically boards
using RPMH regulators don't model the input supplies of RPMH
regulators. Input supplies for RPMH regulators nearly always come from
the output of other RPMH regulators (or always-on regulators) and RPMH
firmware is initialized with this knowledge and handles enabling (and
adjusting the voltage of) input supplies. While we could model the
parent/child relationship of the regulators in Linux, many boards
don't bother since it adds extra overhead.
Let's change the regulator core to make things work again. Now if we
fail to get the input or output voltage we'll still call into
get_optimum_mode() and we'll just pass error codes in for input_uV
and/or output_uV parameters.
Since no existing regulator drivers even look at input_uV and
output_uV we don't need to add this error handling anywhere right
now. We'll add some comments in the core so that it's obvious that (if
regulator drivers care) it's up to them to add the checks.
Reported-by: Andrew Halaney <ahalaney@redhat.com>
Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The print function dev_err() is redundant because
platform_get_irq_byname() already prints an error.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1986
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220825070438.128093-1-yang.lee@linux.alibaba.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
pfuze100_regulator_probe()
The pfuze_chip::regulator_descs is an array of size
PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators
is the pointer to the real regulators of a specific device.
The number of real regulator is supposed to be less than
the PFUZE100_MAX_REGULATOR, so we should use the size of
'regulator_num * sizeof(struct pfuze_regulator)' in memcpy().
This fixes the out of bounds access bug reported by KASAN.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux
Pull thermal control changes for v6.1-rc1 from Daniel Lezcano:
"- Rework the device tree initialization, convert the drivers to the
new API and remove the old OF code (Daniel Lezcano)
- Fix return value to -ENODEV when searching for a specific thermal
zone which does not exist (Daniel Lezcano)
- Fix the return value inspection in of_thermal_zone_find() (Dan
Carpenter)
- Fix kernel panic when KASAN is enabled as it detects use after
free when unregistering a thermal zone (Daniel Lezcano)
- Move the set_trip ops inside the therma sysfs code (Daniel Lezcano)
- Remove unnecessary error message as it is already showed in the
underlying function (Jiapeng Chong)
- Rework the monitoring path and move the locks upper in the call
stack to fix some potentials race windows (Daniel Lezcano)
- Fix lockdep_assert() warning introduced by the lock rework (Daniel
Lezcano)
- Revert the Mellanox 'hotter thermal zone' feature because it is
already handled in the thermal framework core code (Daniel Lezcano)"
* tag 'thermal-v6.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux: (46 commits)
Revert "mlxsw: core: Add the hottest thermal zone detection"
thermal/core: Fix lockdep_assert() warning
thermal/core: Move the mutex inside the thermal_zone_device_update() function
thermal/core: Move the thermal zone lock out of the governors
thermal/governors: Group the thermal zone lock inside the throttle function
thermal/core: Rework the monitoring a bit
thermal/core: Rearm the monitoring only one time
thermal/drivers/qcom/spmi-adc-tm5: Remove unnecessary print function dev_err()
thermal/of: Remove old OF code
thermal/core: Move set_trip_temp ops to the sysfs code
thermal/drivers/samsung: Switch to new of thermal API
regulator/drivers/max8976: Switch to new of thermal API
Input: sun4i-ts - switch to new of thermal API
iio/drivers/sun4i_gpadc: Switch to new of thermal API
hwmon/drivers/core: Switch to new of thermal API
hwmon: pm_bus: core: Switch to new of thermal API
ata/drivers/ahci_imx: Switch to new of thermal API
thermal/drivers/ti-soc: Switch to new of API
thermal/drivers/hisilicon: Switch to new of API
thermal/drivers/maxim: Switch to new of API
...
|
|
Return the value from regmap_write() directly instead of storing it
in another redundant variable.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Link: https://lore.kernel.org/r/20220824074707.221159-1-ye.xingchen@zte.com.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Merge series from Iskren Chernev <iskren.chernev@gmail.com>:
This patch series adds SPMI and SMD regulator support for the PM6125 found on
SM4250/SM6115 SoCs from QCom.
This code has been tested on:
* OnePlus Nord N100 (oneplus,billie2, SoC sm4250)
* Redmi 9T (redmi,lemon, SoC sm6115)
The main source used for this change is qpnp pm6125 support patch from caf [1]:
[1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5
v3: https://lkml.org/lkml/2022/7/31/303
v2: https://lkml.org/lkml/2022/7/26/885
v1: https://lkml.org/lkml/2021/8/28/144
Changes from v3:
- fix compilation issue reported by kernel test robot
- reorder HFSMPS/LDO+FTSMPS patches
- add new slew-rate computation for HFSMPS
- add proper pull-down support for new regs
- name new regs/vals after HFSMPS instead of FTSMPS
- address indentation/newline issues reported by Krzysztof
- improve commit messages on SPMI/RPM related patches
Changes from v2:
- split spmi new regulator support in 2 patches
- FTS and LDOs now have set_load and set_pull_down ops
- add better commit messages on spmi patches
- fix sob header order
- fix tested device info (Redmi 9T, NOT Xiaomi 9T)
- improve formatting in spmi binding docs
- sort alphabetically in smd binding docs
- sort alphabetically spmi pmics
- sort alphabetically smd pmics
Changes from v1:
- add dt-bindings
- split SPMI patch into new reg types and the new PMIC
- add correct supply mapping
Iskren Chernev (13):
dt-bindings: regulator: qcom_spmi: Improve formatting of if-then
blocks
dt-bindings: regulator: qcom_spmi: Document PM6125 PMIC
dt-bindings: regulator: qcom_smd: Sort compatibles alphabetically
dt-bindings: regulator: qcom_smd: Document PM6125 PMIC
regulator: qcom_spmi: Add support for HFSMPS regulator type
regulator: qcom_spmi: Add support for LDO_510 and FTSMPS
regulator: qcom_spmi: Sort pmics alphabetically (part 1)
regulator: qcom_spmi: Sort pmics alphabetically (part 2)
regulator: qcom_spmi: Add PM6125 PMIC support
regulator: qcom_smd: Sort pmics alphabetically (part 1)
regulator: qcom_smd: Sort pmics alphabetically (part 2)
regulator: qcom_smd: Sort pmics alphabetically (part 3)
regulator: qcom_smd: Add PM6125 RPM regulators
.../regulator/qcom,smd-rpm-regulator.yaml | 26 +-
.../regulator/qcom,spmi-regulator.yaml | 32 ++
drivers/regulator/qcom_smd-regulator.c | 400 ++++++++++--------
drivers/regulator/qcom_spmi-regulator.c | 378 ++++++++++++-----
4 files changed, 551 insertions(+), 285 deletions(-)
--
2.37.1
|
|
The regulators set consists of 3 bucks DCDCs and 4 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Validation:
Visual check: cat /sys/kernel/debug/regulator/regulator_summary
Validation: userspace-consumer and virtual-regulator required
to test further
Enable/Disable:
cat /sys/devices/platform/userspace-consumer-VDDSHV_SD_IO_PMIC/state
echo disabled > /sys/devices/platform/
userspace-consumer-VDDSHV_SD_IO_PMIC/state
echo enabled > /sys/devices/platform/
userspace-consumer-VDDSHV_SD_IO_PMIC/state
Change voltage:
cat /sys/devices/platform/regulator-virtual-ldo1/min_microvolts
echo 1000000 > /sys/devices/platform/regulator-virtual-ldo1/
min_microvolts
echo 3000000 > /sys/devices/platform/regulator-virtual-ldo1/
max_microvolts
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220805121852.21254-9-jneanne@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ranges and types are taken from the relevant SPMI driver:
- ftsmps_510: s1-s4, s8
- buck_510: s5-s7
- ldo_nX_510: l1-l4, l6-l8, l17-18
- ldo_mv_pX_510: l5, l15, l19-l24
- ldo_lv_pX_510: l9-l14, l16
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220802221112.2280686-14-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-13-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-12-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-11-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add support for PM6125 PMIC which is found on SM4250/6115 SoCs.
S1, S2, S3, S4, S8 are FTS+FTSMPS_510, rev 2
- range is 0.3-1.372V by 4mV increments
S5, S6, s7 are BUCK+HFSMPS_510, rev 4
- range is 0.32-2.04V by 8mV increment
L1, L3, L7 are LDO+N600_510, rev 2
L2, L4, L8, L17, L18 are LDO+N300_510, rev 2
L6 is LDO+N1200_510, rev 2
- range is 0.32-1.304V by 8mV increment
L5 is LDO+MV_P50_510, rev 2
L15, L19, L20 are LDO+MV_P150_510, rev 2
L21, L22, L23, L24 are LDO+MV_P600_510, rev 2
- range is 1.504-3.544V by 8mV increment
L9, L11, L14 are LDO+LV_P600_510, rev 2
L10, L16 are LDO+LV_P150_510, rev 2
L12, L13 are LDO+LV_P300_510, rev 2
- range 1.504-2V by 8mV increment
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220802221112.2280686-10-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-9-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The sorting is split in multiple commits for easier reviewing.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-8-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add support for LDO_510 and FTSMPS3 regulators, all belonging to register
layout HFSMPS. This is done in preparation for adding support for the
PM6125 PMIC.
For FTSMPS3 and LDO_510, only IDLE and NORMAL modes are selectable (no
FAST).
The inspiration for the magic constants was taken from [1]
[1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-7-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This is preparation for supporing PM6125.
The HFSMPS is a BUCK type regulator with subtype 0x0a, same as the
existing HFS430 regulator.
Even though the HFSMPS and HFS430 share a type and subtype, the HFSMPS has
an updated register map, including different mode values, moved pull down
register, and different slew rate address and formula.
In addition to NORMAL (NPM), FAST (AUTO_LPM) and IDLE (LPM), the
regulator also supports RETENTION and AUTO_RM which are currently
unselectable by the driver.
The inspiration of this is taken from [1].
[1] https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20220802221112.2280686-6-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This message shows up occasionally but in bursts (seen up to 30 times
per second on my ODROID N2+).
According to Matthias Kaehlcke's comment in 'regulator: core: silence
warning: "VDD1: ramp_delay not set"', this message should have been
removed after restructuring previous code that assumed that ramp_delay
being zero in that function was an error.
Link: https://lore.kernel.org/lkml/625675256c0d75805f088b4be17a3308dc1b7ea4.1477571498.git.hns@goldelico.com/T/
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Link: https://lore.kernel.org/r/20220820131420.16608-1-christian@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If regulator_enable() fails, enable_count is incremented still.
A consumer, assuming no matching regulator_disable() is necessary on
failure, will then get this error message upon regulator_put()
since enable_count is non-zero:
[ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170
The consumer could try to fix this in their driver by cleaning up on
error from regulator_enable() (i.e. call regulator_disable()), but that
results in the following since regulator_enable() failed and didn't
increment user_count:
[ 1.258112] unbalanced disables for vreg_l17c
[ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190
Fix this by decrementing enable_count upon failure to enable.
With this in place, just the reason for failure to enable is printed
as expected and developers can focus on the root cause of their issue
instead of thinking their usage of the regulator consumer api is
incorrect. For example, in my case:
[ 1.240426] vreg_l17c: invalid input voltage found
Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Previously, an unresolved regulator supply reference upon calling
regulator_register on an always-on or boot-on regulator caused
set_machine_constraints to be called twice.
This in turn may initialize the regulator twice, leading to voltage
glitches that are timing-dependent. A simple, unrelated configuration
change may be enough to hide this problem, only to be surfaced by
chance.
One such example is the SD-Card voltage regulator in a NanoPI R4S that
would not initialize reliably unless the registration flow was just
complex enough to allow the regulator to properly reset between calls.
Fix this by re-arranging regulator_register, trying resolve the
regulator's supply early enough that set_machine_constraints does not
need to be called twice.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Merge series from Matti Vaittinen <mazziesaccount@gmail.com>:
A few* drivers seem to use pattern demonstrated by pseudocode:
- devm_regulator_get()
- regulator_enable()
- devm_add_action_or_reset(regulator_disable())
Introducing devm helpers for this pattern would remove bunch of code from
drivers. Typically following:
- replace 3 calls (devm_regulator_get[_optional](), regulator_enable(),
devm_add_action_or_reset()) with just one
(devm_regulator_get_enable[_optional]()).
- drop disable callback.
- remove stored pointer to struct regulator - which can lead to problem
when an devm action for regulator_disable is used.
I believe this simplifies things by removing some dublicated code.
The suggested managed 'get_enable' APIs do not return the pointer to
regulators for user because any call to regulator_disable()
(or regulator_enable()) may easily lead to regulator enable count imbalance
upon device detach. (Eg, if someone calls regulator_disable() and the
device is then detached before user has re-enabled the regulator). Not
returning the pointer to obtained regulator to caller is a good hint that
the enable/disable should not be manually handled when these APIs are used.
OTOH, not returning the pointer reduces the use-cases by not allowing
the consumers to perform other regulator actions. For example request the
voltages. A few drivers which used the "get, enable,
devm_action_to_disable" did also query the voltages. The API does not suit
needs of such users.
|
|
A few regulator consumer drivers seem to be just getting a regulator,
enabling it and registering a devm-action to disable the regulator at
the driver detach and then forget about it.
We can simplify this a bit by adding a devm-helper for this pattern.
Add devm_regulator_get_enable() and devm_regulator_get_enable_optional()
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The thermal OF code has a new API allowing to migrate the OF
initialization to a simpler approach. The ops are no longer device
tree specific and are the generic ones provided by the core code.
Convert the ops to the thermal_zone_device_ops format and use the new
API to register the thermal zone with these generic ops.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220804224349.1926752-31-daniel.lezcano@linexp.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of small fixes that came in since my pull request, nothing
major here"
* tag 'regulator-fix-v6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Fix missing error return from regulator_bulk_get()
regulator: pca9450: Remove restrictions for regulator-name
|
|
The value returned by an i2c driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com>
Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/*
Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5
Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio
Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860
Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b
Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
|
Since we don't actually pass the load to the firmware, switch to using
get_optimum_mode() instead of open-coding it.
This is intended to have no effect other than cleanup.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220726102024.1.Icc838fe7bf0ef54a014ab2fee8af311654f5342a@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
|
|
In commit 6eabfc018e8d ("regulator: core: Allow specifying an initial
load w/ the bulk API") I changed the error handling but had a subtle
that caused us to always return no error even if there was an
error. Fix it.
Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
|
