linux-kernel - [PATCH AUTOSEL 6.16-6.6] mfd: axp20x: Set explicit ID for AXP313 regulator

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>] [day] [month] [year] [list]

Message-Id: <20250805130945.471732-1-sashal@kernel.org>
Date: Tue,  5 Aug 2025 09:08:36 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
	stable@...r.kernel.org
Cc: Chen-Yu Tsai <wens@...e.org>,
	Lee Jones <lee@...nel.org>,
	Sasha Levin <sashal@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: [PATCH AUTOSEL 6.16-6.6] mfd: axp20x: Set explicit ID for AXP313 regulator

From: Chen-Yu Tsai <wens@...e.org>

[ Upstream commit 88828c7e940dd45d139ad4a39d702b23840a37c5 ]

On newer boards featuring the A523 SoC, the AXP323 (related to the
AXP313) is paired with the AXP717 and serves as a secondary PMIC
providing additional regulator outputs. However the MFD cells are all
registered with PLATFORM_DEVID_NONE, which causes the regulator cells
to conflict with each other.

Commit e37ec3218870 ("mfd: axp20x: Allow multiple regulators") attempted
to fix this by switching to PLATFORM_DEVID_AUTO so that the device names
would all be different, however that broke IIO channel mapping, which is
also tied to the device names. As a result the change was later reverted.

Instead, here we attempt to make sure the AXP313/AXP323 regulator cell
does not conflict by explicitly giving it an ID number. This was
previously done for the AXP809+AXP806 pair used with the A80 SoC.

Signed-off-by: Chen-Yu Tsai <wens@...e.org>
Link: https://lore.kernel.org/r/20250619173207.3367126-1-wens@kernel.org
Signed-off-by: Lee Jones <lee@...nel.org>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis, here's my assessment:

**Backport Status: YES**

This commit is suitable for backporting to stable kernel trees for the
following reasons:

1. **Fixes a real bug**: The commit addresses a device naming conflict
   issue when using AXP313/AXP323 PMICs alongside AXP717 as a secondary
   PMIC. Without this fix, the kernel produces a sysfs duplicate
   filename error and fails to properly register the secondary regulator
   device.

2. **Small and contained change**: The fix is minimal - it only changes
   one line of code from `MFD_CELL_NAME("axp20x-regulator")` to
   `MFD_CELL_BASIC("axp20x-regulator", NULL, NULL, 0, 1)`, which
   explicitly sets an ID of 1 for the AXP313 regulator cell.

3. **Follows established pattern**: The commit follows an existing
   pattern already used in the same driver for the AXP806 PMIC (lines
   1173-1174 in axp806_cells), which also sets an explicit ID (2) to
   avoid conflicts when paired with AXP809.

4. **Minimal risk of regression**: The change only affects AXP313/AXP323
   devices and doesn't touch other PMIC configurations. The explicit ID
   assignment is a safe approach that doesn't break existing IIO channel
   mappings (which was the problem with the previous PLATFORM_DEVID_AUTO
   approach mentioned in the commit message).

5. **Clear problem and solution**: The commit message clearly explains
   the issue (sysfs duplicate filename error) and references the history
   of previous attempts to fix similar issues (commit e37ec3218870 and
   its revert). The solution is targeted and doesn't introduce
   architectural changes.

6. **Hardware enablement fix**: This fix enables proper functioning of
   boards with the A523 SoC that use dual PMIC configurations (AXP323 +
   AXP717), which would otherwise fail to initialize properly.

The commit meets the stable tree criteria of being an important bugfix
with minimal risk and contained scope. It fixes a specific hardware
configuration issue without introducing new features or making broad
architectural changes.

 drivers/mfd/axp20x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index e9914e8a29a3..25c639b348cd 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -1053,7 +1053,8 @@ static const struct mfd_cell axp152_cells[] = {
 };

 static struct mfd_cell axp313a_cells[] = {
-	MFD_CELL_NAME("axp20x-regulator"),
+	/* AXP323 is sometimes paired with AXP717 as sub-PMIC */
+	MFD_CELL_BASIC("axp20x-regulator", NULL, NULL, 0, 1),
 	MFD_CELL_RES("axp313a-pek", axp313a_pek_resources),
 };

-- 
2.39.5