linux-kernel - [PATCH v2 0/5] regulator: add X-Powers AXP323 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241007001408.27249-1-andre.przywara@arm.com>
Date: Mon,  7 Oct 2024 01:14:03 +0100
From: Andre Przywara <andre.przywara@....com>
To: Lee Jones <lee@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Chen-Yu Tsai <wens@...e.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>
Cc: devicetree@...r.kernel.org,
	linux-sunxi@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Martin Botka <martin.botka@...ainline.org>,
	Chris Morgan <macromorgan@...mail.com>
Subject: [PATCH v2 0/5] regulator: add X-Powers AXP323 support

A small update of version, just changing the regmap cache type to maple
tree, and adding the accrued tags (thanks to the reviewers!).
================================
The X-Powers AXP323 is a close sibling to the AXP313a PMIC, only that it
allows to dual-phase the first two DC/DC converters. This is controlled
via a new register. On the first glance that would sound like a
compatible extension, but any random AXP313a driver would not know about
the potential dual-phase nature of the second DCDC rail, so might want
to turn that off, spoiling the whole setup. So this patchset introduces
a new compatible string, without any fallbacks.

Patch 1 adds the DT binding documentation, patch 2 fixes some fragile
connection between PMIC IDs and an array. Patch 3 allows multiple AXP
chips, since the AXP323 seems to be often paired with the AXP717, and
there is some sysfs naming clash with the current code.
Patch 4 then adds the MFD bits, to introduce the new device type and that
extra register, while patch 4 eventually adds the new regulator device,
and takes care about the proper poly-phase detection.

One note: so far the poly-phased AXP PMICs had that setting already
enabled at reset time, so we just detected it and were good. However the
AXP323 on my board does not, so it requires enabling the dual-phase bit at
boot time. The BSP kernel does that in their boot0 (SPL) early boot code,
and the plan would be to do this either in U-Boot or TF-A for mainline.
But should we actually expose this in the DT, as some new property, to
give kernels a chance to set it? The rails in question power the secondary
cluster, so it's not strictly required at boot time, but it's probably too
late for the kernel anyway, given that SMP bringup is much earlier than
drivers? I would appreciate any thoughts here.

Thanks,
Andre

Changelog:
v1 ... v2:
- change regmap cache type to maple tree (as all the others use)
- add R-b: and ACK tags

Andre Przywara (5):
  dt-bindings: mfd: x-powers,axp152: Document AXP323
  mfd: axp20x: ensure relationship between IDs and model names
  mfd: axp20x: Allow multiple regulators
  mfd: axp20x: Add support for AXP323
  regulator: axp20x: add support for the AXP323

 .../bindings/mfd/x-powers,axp152.yaml         |  3 +
 drivers/mfd/axp20x-i2c.c                      |  1 +
 drivers/mfd/axp20x.c                          | 58 ++++++++++++++-----
 drivers/regulator/axp20x-regulator.c          | 13 ++++-
 include/linux/mfd/axp20x.h                    |  4 +-
 5 files changed, 61 insertions(+), 18 deletions(-)

-- 
2.46.2