mbox series

[RESEND,v2,0/7] regulator: mt6358: Remove bogus regulators and improvements

Message ID 20230721082903.2038975-1-wenst@chromium.org
Headers
Series regulator: mt6358: Remove bogus regulators and improvements |

Message

Chen-Yu Tsai July 21, 2023, 8:28 a.m. UTC 
  (Resending with Lee added to recipients)

Hi,

This is v2 of the remainder of the MT6358 regulator driver cleanup
and improvement series. v1 can be found here [1].

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.

Patch 1 should either go through the mfd tree and an immutable branch
created for the regulator tree to consume, or given an Ack, merged
directly through the regulator tree.

Spoiler: a follow-up series dealing with the MT6366 PMIC, which is
covered by the same driver, also has an mfd header patch that would
need the same treatment.

Patches 2~6 should go through the regulator tree, and patch 7 through
the soc tree. Patches 2 and 3 should be merged as fixes for v6.5, as
the commit they fix was just introduced in -rc1.

Patches 5 and 6 depends on "[v3] regulator: Use bitfield values for
range selectors" [2] I sent out earlier.

This v2 series can be seen as three parts. v1 also had three parts, but
one part was fully merged, and then v2 gained another cleanup.


Part 1 - Fixing bogus regulators (patches 2, 3, and 7)

There are some regulators listed in the bindings and driver that have no
corresponding pin on the actual hardware. MediaTek says these are a
hardware construct for shared control of the same regulator in the
VCN33 case and an alternative control scheme for low power suspend.

In the VCN33 case, there's only one actual regulator, so we merge the
two and rename them to match the hardware pin. No existing devices use
these AFAICT, so this should be safe to change.

The driver changes for this part have been merged, but two review
comments were not accounted for. They are addressed here with two new
patches

Part 2 - Robust chip ID checking (patch 4)

Angelo suggested making the driver fail to probe if an unexpected chip
ID was found. Patch 4 implements this.

Part 3 - Output voltage fine tuning support (patches 1, 5, and 6)

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. After this series is done I'll send out patches for
the MT6366 PMIC, which is what started this. That will also include
updated YAML bindings for MT6366. I think we can merge MT6358 bindings
into them afterwards.

Thanks
ChenYu

[1] https://lore.kernel.org/linux-arm-kernel/20230609083009.2822259-1-wenst@chromium.org/
[2] https://lore.kernel.org/linux-arm-kernel/20230714081408.274567-1-wenst@chromium.org/


Chen-Yu Tsai (7):
  mfd: mt6358: Add missing registers for LDO voltage calibration
  regulator: mt6358: Sync VCN33_* enable status after checking ID
  regulator: mt6358: Fix incorrect VCN33 sync error message
  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
  arm64: dts: mediatek: mt6358: Merge ldo_vcn33_* regulators

 arch/arm64/boot/dts/mediatek/mt6358.dtsi |  11 +-
 drivers/regulator/mt6358-regulator.c     | 314 +++++++++++------------
 include/linux/mfd/mt6358/registers.h     |   6 +
 3 files changed, 151 insertions(+), 180 deletions(-)

Comments

AngeloGioacchino Del Regno July 21, 2023, 8:53 a.m. UTC | #1 
Il 21/07/23 10:28, Chen-Yu Tsai ha scritto:
> 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: f0e3c6261af1 ("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>
Mark Brown July 24, 2023, 12:14 p.m. UTC | #2 
On Fri, 21 Jul 2023 16:28:52 +0800, Chen-Yu Tsai wrote:
> (Resending with Lee added to recipients)
> 
> Hi,
> 
> This is v2 of the remainder of the MT6358 regulator driver cleanup
> and improvement series. v1 can be found here [1].
> 
> [...]

Applied to

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

Thanks!

[2/7] regulator: mt6358: Sync VCN33_* enable status after checking ID
      commit: 649fee5a17a7f96152fee2fb9111d9a4db535f35
[3/7] regulator: mt6358: Fix incorrect VCN33 sync error message
      commit: 67cb608838e0aac8efb48828b1165156f99c1af9

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