[PATCH 0/5] Add TI LM51772 buck-boost voltage regulator

[Paul Louvel]

Hi,

This series provides support for the LM51772, a buck-boost controller
from TI with I2C control, designed for USB Power Delivery applications.
The output voltage is software-configurable from 1 V to 48 V, and the
peak current limit threshold is programmed through software. The
LM51772 also provides an auxiliary fixed 5 V regulator output (VCC1).

Core changes
------------

Patch #3:

Some context for this patch: I am working on a board featuring the
PTN5110. This chip implements a Type-C Port Controller along with
other vendor-defined features. It can support up to two source power
rails for the source-only role in Power Delivery. One power rail is
used for vSafe5V, and the other is the so-called
"SourceVbusHighVoltage", providing voltages > 5 V. On my board, the
LM51772 provides this power path.

The PTN5110 driver is currently supported by the generic tcpci.c
implementation, but it had to be split out into a standalone module to
implement a custom set_vbus() callback. If a "HighVoltage" has been
negotiated between the source and the sink, this callback is
responsible for enabling the regulator supplying such voltages.

In short, the callback looks like this (my kernel changes related to
the functionality above are not upstream yet):

static int ptn5110_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data, bool source,
				 bool sink)
{
	struct ptn5110_priv *priv = container_of(data, struct ptn5110_priv, data);
	int ret;

	ret = regulator_is_enabled(priv->vbus_high);
	if (ret < 0)
		return ret;

	if (ret && !source)
		return regulator_disable(priv->vbus_high);

	if (!ret && source)
		return regulator_enable(priv->vbus_high);

	return 0;
}

set_vbus() is called when the port is registered, at boot time, with
source=false and sink=false. Call trace:

    ptn5110_tcpc_set_vbus
    tcpci_set_vbus
    tcpm_reset_port
    tcpm_init
    tcpm_register_port
    tcpci_register_port
    ptn5110_tcpc_probe
    i2c_device_probe
    really_probe
    __driver_probe_device
    driver_probe_device
    __device_attach_driver
    bus_for_each_drv
    ...

The LM51772 output stage is enabled by default because the CONV_EN2
bit is set. Thus, regulator_is_enabled() returns true, and
regulator_disable() is then called, leading to an unbalanced disable.

My idea is to add a new device tree property,
"regulator-boot-force-off", to disable the regulator immediately when
it is registered with the regulator core, regardless of its previous
state.

Patch #4:

To avoid code duplication when setting and getting the voltage
selector, introduces a new vsel_reg_oversize member in
struct regulator_desc. The LM51772 stores the voltage selector across
two 8-bit registers: one for the least significant bits and one for
the most significant bits.

Thanks,

Signed-off-by: Paul Louvel <paul.louvel@xxxxxxxxxxx>
---
Paul Louvel (5):
      regulator: dt-bindings: Add regulator-boot-force-off property
      regulator: dt-bindings: Add TI LM51772 support
      regulator: core: Add mechanism to force disable a regulator at boot
      regulator: Support regulators where the voltage selector spans two registers
      regulator: Add TI LM51772 support

 .../devicetree/bindings/regulator/regulator.yaml   |   8 +
 .../devicetree/bindings/regulator/ti,lm51772.yaml  | 239 ++++++
 MAINTAINERS                                        |   6 +
 drivers/regulator/Kconfig                          |  11 +
 drivers/regulator/Makefile                         |   1 +
 drivers/regulator/core.c                           | 154 ++--
 drivers/regulator/helpers.c                        |  71 +-
 drivers/regulator/lm51772-regulator.c              | 826 +++++++++++++++++++++
 drivers/regulator/of_regulator.c                   |   1 +
 include/linux/regulator/driver.h                   |   2 +
 include/linux/regulator/machine.h                  |   3 +-
 11 files changed, 1235 insertions(+), 87 deletions(-)
---
base-commit: 0785f7172040512cba759838b27286646773c735
change-id: 20261021-paul-lm51772-c96bbce762a8

Best regards,
--  
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com