The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to
nearly all registers when locked. Unlock the registers at probe time and
leave them unlocked permanently.

This approach is justified because:
- Register locking is very uncommon in typical system operation
- No code path is expected to lock the registers during runtime
- Adding a custom regmap write function would add overhead to every
  register write, including voltage changes triggered by CPU OPP
  transitions from the cpufreq governor which could happen quite
  frequently

Cc: stable@vger.kernel.org
Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC")
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
---
Changes in v4:
- Move the registers unlock in the probe instead of a custom regmap write
  operation.

Changes in v3:
- Removed unused variable.

Changes in v2:
- Setup a custom regmap_bus only for the TPS65214 instead of checking
  the chip_id every time reg_write is called.
---
 drivers/mfd/tps65219.c       | 7 +++++++
 include/linux/mfd/tps65219.h | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
index 65a952555218d..f1115c5585545 100644
--- a/drivers/mfd/tps65219.c
+++ b/drivers/mfd/tps65219.c
@@ -498,6 +498,13 @@ static int tps65219_probe(struct i2c_client *client)
 		return ret;
 	}
 
+	if (chip_id == TPS65214) {
+		ret = i2c_smbus_write_byte_data(client, TPS65214_REG_LOCK,
+						TPS65214_LOCK_ACCESS_CMD);
+		if (ret)
+			return ret;
+	}
+
 	ret = devm_regmap_add_irq_chip(tps->dev, tps->regmap, client->irq,
 				       IRQF_ONESHOT, 0, pmic->irq_chip,
 				       &tps->irq_data);
diff --git a/include/linux/mfd/tps65219.h b/include/linux/mfd/tps65219.h
index 55234e771ba73..3abf937191d0c 100644
--- a/include/linux/mfd/tps65219.h
+++ b/include/linux/mfd/tps65219.h
@@ -149,6 +149,8 @@ enum pmic_id {
 #define TPS65215_ENABLE_LDO2_EN_MASK                    BIT(5)
 #define TPS65214_ENABLE_LDO1_EN_MASK			BIT(5)
 #define TPS65219_ENABLE_LDO4_EN_MASK			BIT(6)
+/* Register Unlock */
+#define TPS65214_LOCK_ACCESS_CMD			0x5a
 /* power ON-OFF sequence slot */
 #define TPS65219_BUCKS_LDOS_SEQUENCE_OFF_SLOT_MASK	GENMASK(3, 0)
 #define TPS65219_BUCKS_LDOS_SEQUENCE_ON_SLOT_MASK	GENMASK(7, 4)

-- 
2.43.0

On 11/12/25 9:14 AM, Kory Maincent (TI.com) wrote:
> The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to
> nearly all registers when locked. Unlock the registers at probe time and
> leave them unlocked permanently.
> 
> This approach is justified because:
> - Register locking is very uncommon in typical system operation
> - No code path is expected to lock the registers during runtime

Any other entity in the system that could re-lock these registers?
How about low power modes or other PM handling?

> - Adding a custom regmap write function would add overhead to every
>    register write, including voltage changes triggered by CPU OPP
>    transitions from the cpufreq governor which could happen quite
>    frequently
> 
> Cc: stable@vger.kernel.org
> Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC")
> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
> ---
> Changes in v4:
> - Move the registers unlock in the probe instead of a custom regmap write
>    operation.
> 
> Changes in v3:
> - Removed unused variable.
> 
> Changes in v2:
> - Setup a custom regmap_bus only for the TPS65214 instead of checking
>    the chip_id every time reg_write is called.
> ---
>   drivers/mfd/tps65219.c       | 7 +++++++
>   include/linux/mfd/tps65219.h | 2 ++
>   2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
> index 65a952555218d..f1115c5585545 100644
> --- a/drivers/mfd/tps65219.c
> +++ b/drivers/mfd/tps65219.c
> @@ -498,6 +498,13 @@ static int tps65219_probe(struct i2c_client *client)
>   		return ret;
>   	}
>   
> +	if (chip_id == TPS65214) {
> +		ret = i2c_smbus_write_byte_data(client, TPS65214_REG_LOCK,
> +						TPS65214_LOCK_ACCESS_CMD);
> +		if (ret)
> +			return ret;

Might be good to print out some error message here, otherwise LGTM,

Reviewed-by: Andrew Davis <afd@ti.com>

> +	}
> +
>   	ret = devm_regmap_add_irq_chip(tps->dev, tps->regmap, client->irq,
>   				       IRQF_ONESHOT, 0, pmic->irq_chip,
>   				       &tps->irq_data);
> diff --git a/include/linux/mfd/tps65219.h b/include/linux/mfd/tps65219.h
> index 55234e771ba73..3abf937191d0c 100644
> --- a/include/linux/mfd/tps65219.h
> +++ b/include/linux/mfd/tps65219.h
> @@ -149,6 +149,8 @@ enum pmic_id {
>   #define TPS65215_ENABLE_LDO2_EN_MASK                    BIT(5)
>   #define TPS65214_ENABLE_LDO1_EN_MASK			BIT(5)
>   #define TPS65219_ENABLE_LDO4_EN_MASK			BIT(6)
> +/* Register Unlock */
> +#define TPS65214_LOCK_ACCESS_CMD			0x5a
>   /* power ON-OFF sequence slot */
>   #define TPS65219_BUCKS_LDOS_SEQUENCE_OFF_SLOT_MASK	GENMASK(3, 0)
>   #define TPS65219_BUCKS_LDOS_SEQUENCE_ON_SLOT_MASK	GENMASK(7, 4)
>

On Wed, 12 Nov 2025 13:03:22 -0600
Andrew Davis <afd@ti.com> wrote:

> On 11/12/25 9:14 AM, Kory Maincent (TI.com) wrote:
> > The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to
> > nearly all registers when locked. Unlock the registers at probe time and
> > leave them unlocked permanently.
> > 
> > This approach is justified because:
> > - Register locking is very uncommon in typical system operation
> > - No code path is expected to lock the registers during runtime  
> 
> Any other entity in the system that could re-lock these registers?
> How about low power modes or other PM handling?

No there is no reason to re-lock these registers. It will be locked again only
if the PMIC is reset.
In any case, if one case appears that needs to lock these register (even
if I think it is unlikely) we could come back to the regmap custom write
design. 

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com