2023-09-13 14:04:33

by Chen-Yu Tsai

[permalink] [raw]
Subject: [PATCH v3 0/3] regulator: mt6358: Remove bogus regulators and improvements

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/[email protected]/
[2] https://lore.kernel.org/linux-mediatek/[email protected]/

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


2023-09-13 21:13:27

by Chen-Yu Tsai

[permalink] [raw]
Subject: [PATCH v3 1/3] regulator: mt6358: Fail probe on unknown chip ID

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 <[email protected]>
Fixes: f0e3c6261af1 ("regulator: mt6366: Add support for MT6366 regulator")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
---
drivers/regulator/mt6358-regulator.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/mt6358-regulator.c b/drivers/regulator/mt6358-regulator.c
index 120c60d40ed4..935c7ad56c7e 100644
--- a/drivers/regulator/mt6358-regulator.c
+++ b/drivers/regulator/mt6358-regulator.c
@@ -682,12 +682,18 @@ static int mt6358_regulator_probe(struct platform_device *pdev)
const struct mt6358_regulator_info *mt6358_info;
int i, max_regulator, ret;

- if (mt6397->chip_id == MT6366_CHIP_ID) {
- max_regulator = MT6366_MAX_REGULATOR;
- mt6358_info = mt6366_regulators;
- } else {
+ switch (mt6397->chip_id) {
+ case MT6358_CHIP_ID:
max_regulator = MT6358_MAX_REGULATOR;
mt6358_info = mt6358_regulators;
+ break;
+ case MT6366_CHIP_ID:
+ max_regulator = MT6366_MAX_REGULATOR;
+ mt6358_info = mt6366_regulators;
+ break;
+ default:
+ dev_err(&pdev->dev, "unsupported chip ID: %d\n", mt6397->chip_id);
+ return -EINVAL;
}

ret = mt6358_sync_vcn33_setting(&pdev->dev);
--
2.42.0.283.g2d96d420d3-goog

2023-09-26 13:00:27

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH v3 0/3] regulator: mt6358: Remove bogus regulators and improvements

On Wed, 13 Sep 2023 16:29:15 +0800, Chen-Yu Tsai wrote:
> 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
>
> [...]

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/3] regulator: mt6358: Fail probe on unknown chip ID
commit: 7442edec72bc657e6ce38ae01de9f10e55decfaa
[2/3] regulator: mt6358: Add output voltage fine tuning to fixed regulators
commit: cf08fa74c716cf20e5038d1e7dbbd7dba1b76062
[3/3] regulator: mt6358: Add output voltage fine tuning to variable LDOs
commit: 017c6658fd59740f9845ca0d3369ddd778e3e0c0

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark