This series introduces a boolean DT property, dlg,no-gpio-control, for
the DA91xx regulators. Use this property to indicate that GPIO control
is not configured with the functions DVC/RELOAD/EN, allowing buck
registers to be cached.

The DA9121 driver checks dlg,no-gpio-control and updates regmap_config's
volatile_table if the property is present. Buck registers are removed
from the volatile_table if the property is present, enabling caching of
the registers, which removes I2C reads when performing an I2C write to
the buck registers.

---
Changes in v2:
- Update commit messages to clarify why dlg,no-gpio-control is needed.
- Add error check for mutually exclusive properties.
- Link to v1: https://lore.kernel.org/r/20260309-no-gpio-control-v1-0-06d2365917c6@axis.com

---
André Svensson (2):
      regulator: dt-bindings: dlg,da9121: Add dlg,no-gpio-control
      regulator: da9121: Allow caching BUCK registers

 .../devicetree/bindings/regulator/dlg,da9121.yaml  | 49 ++++++++++++++++++++++
 drivers/regulator/da9121-regulator.c               | 43 +++++++++++++++----
 2 files changed, 85 insertions(+), 7 deletions(-)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260309-no-gpio-control-9cc02b1e8994

Best regards,
-- 
André Svensson <andre.svensson@axis.com>

On Fri, 20 Mar 2026 08:33:23 +0100, André Svensson wrote:
> Allow caching of buck registers when no GPIO input control is configured
> 
> This series introduces a boolean DT property, dlg,no-gpio-control, for
> the DA91xx regulators. Use this property to indicate that GPIO control
> is not configured with the functions DVC/RELOAD/EN, allowing buck
> registers to be cached.
> 
> [...]

Applied to

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

Thanks!

[1/2] regulator: dt-bindings: dlg,da9121: Add dlg,no-gpio-control
      https://git.kernel.org/broonie/regulator/c/7795014962fa
[2/2] regulator: da9121: Allow caching BUCK registers
      https://git.kernel.org/broonie/regulator/c/6c2505e185b0

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