This series adds support for the Monolithic Power Systems MPQ4210, a 40V
synchronous four-switch buck-boost controller with an I2C interface.

The output voltage is programmed through an 11-bit feedback reference DAC
with a 1mV step and is then scaled by an external feedback resistor
divider, so the divider ratio has to be described in the device tree. The
same ratio applies to the reference slew rate, so the four rates that the
Control 1 SR field selects are scaled into a per-device ramp_delay_table
and the field is exposed through regulator_set_ramp_delay_regmap(). The
current limit, switching frequency, dither and interrupt registers are
left at their reset values.

Only 0.3V to 2.047V of the DAC range is specified, so linear_min_sel
holds the driver to that and the lower selectors are not offered. On a
board with a gain of 14 that is the difference between a floor of 4.2V
and one of 0V, and the lower part of that range does not regulate.

Scaling the ramp table is a deliberate difference from ltc3589 and
mp886x, which read an equivalent feedback-divider property but keep their
ramp values unscaled. Every other constraint in the device tree is
expressed at the regulator output, so the selectable rates have to be as
well, or regulator-ramp-delay would select the wrong SR encoding. It does
mean the reachable rates are board specific and no value can be copied
between boards, so the binding documents how they are derived and shows
the calculation in its example.

Two details are worth a reviewer's attention.

Enable follows the start-up sequence the datasheet spells out: commit the
reference with the GO bit, wait 200ms, then set ENPWR. That is why
.enable is open coded rather than using regulator_enable_regmap.

Control 1 bit 2 is documented only as "Reserved", but the datasheet notes
that it must be set to one before the IC starts up. Its reset value is
zero, so probe sets it.

One consequence of the hardware worth spelling out: the MPQ4210 does not
respond on the I2C bus while EN is deasserted. The enable GPIO is
therefore claimed and asserted before the first register access and held
for the lifetime of the device, rather than being handed to the core as
regulator_config::ena_gpiod, which would drop the bus along with the
output.

Tested on an i.MX6SX board, regulator behind an I2C mux, feedback divider
100k/7.685k giving a gain of 14.0124, a 14012uV step and a 4.204V floor:

- A 16 point staircase from 4.204V to 25.2V: the commanded voltage, the
  value read back and the selector decoded from the two reference
  registers agree exactly at every point, and a meter on the rail
  follows.
- With the rail up and no regulator-ramp-delay in the device tree,
  Control 1 reads 0x45: SR at its reset value, bit 2 set, GO
  self-cleared and ENPWR set. Interrupt status reads clear.
- regulator-ramp-delay picks the SR encoding as intended. 1050, an exact
  entry of this board's scaled table, gives 0x85. 3000, above every
  entry, warns "Can't set ramp-delay 3000, setting 2101" and gives 0xC5.
- Sampling Control 1 across a disable and re-enable shows 0x45, 0x44,
  0x45, so ENPWR is cleared and restored as expected.
- Enable takes 230ms, against roughly 16ms for a plain register write on
  this bus.

Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
Tapio Reijonen (2):
      regulator: dt-bindings: Add MPS MPQ4210
      regulator: Add MPS MPQ4210 buck-boost regulator driver

 .../devicetree/bindings/regulator/mps,mpq4210.yaml |  69 ++++++
 MAINTAINERS                                        |   6 +
 drivers/regulator/Kconfig                          |  11 +
 drivers/regulator/Makefile                         |   1 +
 drivers/regulator/mpq4210.c                        | 243 +++++++++++++++++++++
 5 files changed, 330 insertions(+)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260903-mpq4210-regulator-d4b58046299a

Best regards,
-- 
Tapio Reijonen <tapio.reijonen@vaisala.com>

On Thu, 10 Sep 2026 08:51:40 +0000, Tapio Reijonen wrote:
> regulator: Add MPS MPQ4210 buck-boost regulator support
> 
> This series adds support for the Monolithic Power Systems MPQ4210, a 40V
> synchronous four-switch buck-boost controller with an I2C interface.
> 
> The output voltage is programmed through an 11-bit feedback reference DAC
> with a 1mV step and is then scaled by an external feedback resistor
> divider, so the divider ratio has to be described in the device tree. The
> same ratio applies to the reference slew rate, so the four rates that the
> Control 1 SR field selects are scaled into a per-device ramp_delay_table
> and the field is exposed through regulator_set_ramp_delay_regmap(). The
> current limit, switching frequency, dither and interrupt registers are
> left at their reset values.
> 
> [...]

Applied to

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

Thanks!

[1/2] regulator: dt-bindings: Add MPS MPQ4210
      https://git.kernel.org/broonie/regulator/c/e3c05a881fc9
[2/2] regulator: Add MPS MPQ4210 buck-boost regulator driver
      https://git.kernel.org/broonie/regulator/c/61879d561e91

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

On Thu, Sep 10, 2026 at 08:51:40AM +0000, Tapio Reijonen wrote:

> One consequence of the hardware worth spelling out: the MPQ4210 does not
> respond on the I2C bus while EN is deasserted. The enable GPIO is
> therefore claimed and asserted before the first register access and held
> for the lifetime of the device, rather than being handed to the core as
> regulator_config::ena_gpiod, which would drop the bus along with the
> output.

This is what regmap's cache only mode is for.