[PATCH v3 1/3] dt-bindings: mfd: x-powers,axp152: Document the AXP15060 variant

[PATCH v3 1/3] dt-bindings: mfd: x-powers,axp152: Document the AXP15060 variant

[Shengyu Qu]

The X-Powers AXP15060 is a PMIC seen on Starfive Visionfive 2 board. Add
relative compatible item and CPUSLDO support and disables DC-DC
frequency setting for it.

---
Changes since v2:
 - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
 - Disables DC-DC frequency setting (Andre Przywara)

Changes since v1:
 - Move cpusldo before drivevbus (Krzysztof Kozlowski)

[1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/

Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
index 98dc0a1e9da3..f7f0f2c0421a 100644
--- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
+++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
@@ -77,7 +77,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: x-powers,axp313a
+            enum:
+              - x-powers,axp313a
+              - x-powers,axp15060
 
     then:
       properties:
@@ -97,6 +99,7 @@ properties:
           - x-powers,axp806
           - x-powers,axp809
           - x-powers,axp813
+          - x-powers,axp15060
       - items:
           - const: x-powers,axp228
           - const: x-powers,axp221
@@ -265,7 +268,7 @@ properties:
           Defines the work frequency of DC-DC in kHz.
 
     patternProperties:
-      "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|drivevbus|dc5ldo)$":
+      "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo)$":
         $ref: /schemas/regulator/regulator.yaml#
         type: object
         unevaluatedProperties: false
-- 
2.40.0

[PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Shengyu Qu]

The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
via an I2C bus.

Describe the regmap and the MFD bits, along with the registers exposed
via I2C. Eventually advertise the device using a new compatible string
and add support for power off the system.

The driver would disable PEK function if IRQ is not configured in device
tree, since some boards (For example, Starfive Visionfive 2) didn't
connect IRQ line of PMIC to SOC.

GPIO function isn't enabled in this commit, since its configuration
operation is different from any existing AXP PMICs and needs
logic modification on existing driver. GPIO support might come in later
patches.

---
Changes since v2:
 - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
 - Add axp_regulator_only_cells rather than directly using axp806_cells
   for cases that IRQ line isn't connected.

Changes since v1:
 - Nothing

[1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/

Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
---
 drivers/mfd/axp20x-i2c.c   |   2 +
 drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
 include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
 3 files changed, 194 insertions(+)

diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
index 03fb0840a4c0..a49e5e217554 100644
--- a/drivers/mfd/axp20x-i2c.c
+++ b/drivers/mfd/axp20x-i2c.c
@@ -66,6 +66,7 @@ static const struct of_device_id axp20x_i2c_of_match[] = {
 	{ .compatible = "x-powers,axp313a", .data = (void *)AXP313A_ID },
 	{ .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
 	{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
+	{ .compatible = "x-powers,axp15060", .data = (void *)AXP15060_ID },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
@@ -80,6 +81,7 @@ static const struct i2c_device_id axp20x_i2c_id[] = {
 	{ "axp313a", 0 },
 	{ "axp803", 0 },
 	{ "axp806", 0 },
+	{ "axp15060", 0 },
 	{ },
 };
 MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 95f74ba3149e..07a846ecbf18 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -44,6 +44,7 @@ static const char * const axp20x_model_names[] = {
 	"AXP806",
 	"AXP809",
 	"AXP813",
+	"AXP15060",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -189,6 +190,31 @@ static const struct regmap_access_table axp806_volatile_table = {
 	.n_yes_ranges	= ARRAY_SIZE(axp806_volatile_ranges),
 };
 
+static const struct regmap_range axp15060_writeable_ranges[] = {
+	regmap_reg_range(AXP15060_PWR_OUT_CTRL1, AXP15060_DCDC_MODE_CTRL2),
+	regmap_reg_range(AXP15060_OUTPUT_MONITOR_DISCHARGE, AXP15060_CPUSLDO_V_CTRL),
+	regmap_reg_range(AXP15060_PWR_WAKEUP_CTRL, AXP15060_PWR_DISABLE_DOWN_SEQ),
+	regmap_reg_range(AXP15060_PEK_KEY, AXP15060_PEK_KEY),
+	regmap_reg_range(AXP15060_IRQ1_EN, AXP15060_IRQ2_EN),
+	regmap_reg_range(AXP15060_IRQ1_STATE, AXP15060_IRQ2_STATE),
+};
+
+static const struct regmap_range axp15060_volatile_ranges[] = {
+	regmap_reg_range(AXP15060_STARTUP_SRC, AXP15060_STARTUP_SRC),
+	regmap_reg_range(AXP15060_PWR_WAKEUP_CTRL, AXP15060_PWR_DISABLE_DOWN_SEQ),
+	regmap_reg_range(AXP15060_IRQ1_STATE, AXP15060_IRQ2_STATE),
+};
+
+static const struct regmap_access_table axp15060_writeable_table = {
+	.yes_ranges	= axp15060_writeable_ranges,
+	.n_yes_ranges	= ARRAY_SIZE(axp15060_writeable_ranges),
+};
+
+static const struct regmap_access_table axp15060_volatile_table = {
+	.yes_ranges	= axp15060_volatile_ranges,
+	.n_yes_ranges	= ARRAY_SIZE(axp15060_volatile_ranges),
+};
+
 static const struct resource axp152_pek_resources[] = {
 	DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
 	DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
@@ -262,6 +288,11 @@ static const struct resource axp809_pek_resources[] = {
 	DEFINE_RES_IRQ_NAMED(AXP809_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
 };
 
+static const struct resource axp15060_pek_resources[] = {
+	DEFINE_RES_IRQ_NAMED(AXP15060_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
+	DEFINE_RES_IRQ_NAMED(AXP15060_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
+};
+
 static const struct regmap_config axp152_regmap_config = {
 	.reg_bits	= 8,
 	.val_bits	= 8,
@@ -316,6 +347,15 @@ static const struct regmap_config axp806_regmap_config = {
 	.cache_type	= REGCACHE_RBTREE,
 };
 
+static const struct regmap_config axp15060_regmap_config = {
+	.reg_bits	= 8,
+	.val_bits	= 8,
+	.wr_table	= &axp15060_writeable_table,
+	.volatile_table	= &axp15060_volatile_table,
+	.max_register	= AXP15060_IRQ2_STATE,
+	.cache_type	= REGCACHE_RBTREE,
+};
+
 #define INIT_REGMAP_IRQ(_variant, _irq, _off, _mask)			\
 	[_variant##_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
 
@@ -547,6 +587,23 @@ static const struct regmap_irq axp809_regmap_irqs[] = {
 	INIT_REGMAP_IRQ(AXP809, GPIO0_INPUT,		4, 0),
 };
 
+static const struct regmap_irq axp15060_regmap_irqs[] = {
+	INIT_REGMAP_IRQ(AXP15060, DIE_TEMP_HIGH_LV1,	0, 0),
+	INIT_REGMAP_IRQ(AXP15060, DIE_TEMP_HIGH_LV2,	0, 1),
+	INIT_REGMAP_IRQ(AXP15060, DCDC1_V_LOW,		0, 2),
+	INIT_REGMAP_IRQ(AXP15060, DCDC2_V_LOW,		0, 3),
+	INIT_REGMAP_IRQ(AXP15060, DCDC3_V_LOW,		0, 4),
+	INIT_REGMAP_IRQ(AXP15060, DCDC4_V_LOW,		0, 5),
+	INIT_REGMAP_IRQ(AXP15060, DCDC5_V_LOW,		0, 6),
+	INIT_REGMAP_IRQ(AXP15060, DCDC6_V_LOW,		0, 7),
+	INIT_REGMAP_IRQ(AXP15060, PEK_LONG,			1, 0),
+	INIT_REGMAP_IRQ(AXP15060, PEK_SHORT,			1, 1),
+	INIT_REGMAP_IRQ(AXP15060, GPIO1_INPUT,		1, 2),
+	INIT_REGMAP_IRQ(AXP15060, PEK_FAL_EDGE,			1, 3),
+	INIT_REGMAP_IRQ(AXP15060, PEK_RIS_EDGE,			1, 4),
+	INIT_REGMAP_IRQ(AXP15060, GPIO2_INPUT,		1, 5),
+};
+
 static const struct regmap_irq_chip axp152_regmap_irq_chip = {
 	.name			= "axp152_irq_chip",
 	.status_base		= AXP152_IRQ1_STATE,
@@ -637,6 +694,17 @@ static const struct regmap_irq_chip axp809_regmap_irq_chip = {
 	.num_regs		= 5,
 };
 
+static const struct regmap_irq_chip axp15060_regmap_irq_chip = {
+	.name			= "axp15060",
+	.status_base		= AXP15060_IRQ1_STATE,
+	.ack_base		= AXP15060_IRQ1_STATE,
+	.unmask_base		= AXP15060_IRQ1_EN,
+	.init_ack_masked	= true,
+	.irqs			= axp15060_regmap_irqs,
+	.num_irqs		= ARRAY_SIZE(axp15060_regmap_irqs),
+	.num_regs		= 2,
+};
+
 static const struct mfd_cell axp20x_cells[] = {
 	{
 		.name		= "axp20x-gpio",
@@ -886,6 +954,23 @@ static const struct mfd_cell axp813_cells[] = {
 	},
 };
 
+static const struct mfd_cell axp15060_cells[] = {
+	{
+		.name		= "axp221-pek",
+		.num_resources	= ARRAY_SIZE(axp15060_pek_resources),
+		.resources	= axp15060_pek_resources,
+	}, {
+		.name		= "axp20x-regulator",
+	},
+};
+
+/* For boards that don't have IRQ line connected to SOC. */
+static const struct mfd_cell axp_regulator_only_cells[] = {
+	{
+		.name		= "axp20x-regulator",
+	},
+};
+
 static int axp20x_power_off(struct sys_off_data *data)
 {
 	struct axp20x_dev *axp20x = data->cb_data;
@@ -1011,6 +1096,28 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 		 */
 		axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
 		break;
+	case AXP15060_ID:
+		/*
+		 * Don't register the power key part if there is no interrupt
+		 * line.
+		 *
+		 * Since most use cases of AXP PMICs are Allwinner SOCs, board
+		 * designers follow Allwinner's reference design and connects
+		 * IRQ line to SOC, there's no need for those variants to deal
+		 * with cases that IRQ isn't connected. However, AXP15660 is
+		 * used by some other vendors' SOCs that didn't connect IRQ
+		 * line, we need to deal with this case.
+		 */
+		if (axp20x->irq > 0) {
+			axp20x->nr_cells = ARRAY_SIZE(axp15060_cells);
+			axp20x->cells = axp15060_cells;
+		} else {
+			axp20x->nr_cells = ARRAY_SIZE(axp_regulator_only_cells);
+			axp20x->cells = axp_regulator_only_cells;
+		}
+		axp20x->regmap_cfg = &axp15060_regmap_config;
+		axp20x->regmap_irq_chip = &axp15060_regmap_irq_chip;
+		break;
 	default:
 		dev_err(dev, "unsupported AXP20X ID %lu\n", axp20x->variant);
 		return -EINVAL;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index edd7fdcc33f9..fff7fa6b7c5d 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -22,6 +22,7 @@ enum axp20x_variants {
 	AXP806_ID,
 	AXP809_ID,
 	AXP813_ID,
+	AXP15060_ID,
 	NR_AXP20X_VARIANTS,
 };
 
@@ -143,6 +144,39 @@ enum axp20x_variants {
 /* Other DCDC regulator control registers are the same as AXP803 */
 #define AXP813_DCDC7_V_OUT		0x26
 
+#define AXP15060_STARTUP_SRC		0x00
+#define AXP15060_PWR_OUT_CTRL1		0x10
+#define AXP15060_PWR_OUT_CTRL2		0x11
+#define AXP15060_PWR_OUT_CTRL3		0x12
+#define AXP15060_DCDC1_V_CTRL		0x13
+#define AXP15060_DCDC2_V_CTRL		0x14
+#define AXP15060_DCDC3_V_CTRL		0x15
+#define AXP15060_DCDC4_V_CTRL		0x16
+#define AXP15060_DCDC5_V_CTRL		0x17
+#define AXP15060_DCDC6_V_CTRL		0x18
+#define AXP15060_ALDO1_V_CTRL		0x19
+#define AXP15060_DCDC_MODE_CTRL1		0x1a
+#define AXP15060_DCDC_MODE_CTRL2		0x1b
+#define AXP15060_OUTPUT_MONITOR_DISCHARGE		0x1e
+#define AXP15060_IRQ_PWROK_VOFF		0x1f
+#define AXP15060_ALDO2_V_CTRL		0x20
+#define AXP15060_ALDO3_V_CTRL		0x21
+#define AXP15060_ALDO4_V_CTRL		0x22
+#define AXP15060_ALDO5_V_CTRL		0x23
+#define AXP15060_BLDO1_V_CTRL		0x24
+#define AXP15060_BLDO2_V_CTRL		0x25
+#define AXP15060_BLDO3_V_CTRL		0x26
+#define AXP15060_BLDO4_V_CTRL		0x27
+#define AXP15060_BLDO5_V_CTRL		0x28
+#define AXP15060_CLDO1_V_CTRL		0x29
+#define AXP15060_CLDO2_V_CTRL		0x2a
+#define AXP15060_CLDO3_V_CTRL		0x2b
+#define AXP15060_CLDO4_V_CTRL		0x2d
+#define AXP15060_CPUSLDO_V_CTRL		0x2e
+#define AXP15060_PWR_WAKEUP_CTRL		0x31
+#define AXP15060_PWR_DISABLE_DOWN_SEQ		0x32
+#define AXP15060_PEK_KEY		0x36
+
 /* Interrupt */
 #define AXP152_IRQ1_EN			0x40
 #define AXP152_IRQ2_EN			0x41
@@ -164,6 +198,11 @@ enum axp20x_variants {
 #define AXP20X_IRQ5_STATE		0x4c
 #define AXP20X_IRQ6_STATE		0x4d
 
+#define AXP15060_IRQ1_EN		0x40
+#define AXP15060_IRQ2_EN		0x41
+#define AXP15060_IRQ1_STATE		0x48
+#define AXP15060_IRQ2_STATE		0x49
+
 /* ADC */
 #define AXP20X_ACIN_V_ADC_H		0x56
 #define AXP20X_ACIN_V_ADC_L		0x57
@@ -234,6 +273,8 @@ enum axp20x_variants {
 #define AXP22X_GPIO_STATE		0x94
 #define AXP22X_GPIO_PULL_DOWN		0x95
 
+#define AXP15060_CLDO4_GPIO2_MODESET		0x2c
+
 /* Battery */
 #define AXP20X_CHRG_CC_31_24		0xb0
 #define AXP20X_CHRG_CC_23_16		0xb1
@@ -441,6 +482,33 @@ enum {
 	AXP813_REG_ID_MAX,
 };
 
+enum {
+	AXP15060_DCDC1 = 0,
+	AXP15060_DCDC2,
+	AXP15060_DCDC3,
+	AXP15060_DCDC4,
+	AXP15060_DCDC5,
+	AXP15060_DCDC6,
+	AXP15060_ALDO1,
+	AXP15060_ALDO2,
+	AXP15060_ALDO3,
+	AXP15060_ALDO4,
+	AXP15060_ALDO5,
+	AXP15060_BLDO1,
+	AXP15060_BLDO2,
+	AXP15060_BLDO3,
+	AXP15060_BLDO4,
+	AXP15060_BLDO5,
+	AXP15060_CLDO1,
+	AXP15060_CLDO2,
+	AXP15060_CLDO3,
+	AXP15060_CLDO4,
+	AXP15060_CPUSLDO,
+	AXP15060_SW,
+	AXP15060_RTC_LDO,
+	AXP15060_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
 	AXP152_IRQ_LDO0IN_CONNECT = 1,
@@ -669,6 +737,23 @@ enum axp809_irqs {
 	AXP809_IRQ_GPIO0_INPUT,
 };
 
+enum axp15060_irqs {
+	AXP15060_IRQ_DIE_TEMP_HIGH_LV1 = 1,
+	AXP15060_IRQ_DIE_TEMP_HIGH_LV2,
+	AXP15060_IRQ_DCDC1_V_LOW,
+	AXP15060_IRQ_DCDC2_V_LOW,
+	AXP15060_IRQ_DCDC3_V_LOW,
+	AXP15060_IRQ_DCDC4_V_LOW,
+	AXP15060_IRQ_DCDC5_V_LOW,
+	AXP15060_IRQ_DCDC6_V_LOW,
+	AXP15060_IRQ_PEK_LONG,
+	AXP15060_IRQ_PEK_SHORT,
+	AXP15060_IRQ_GPIO1_INPUT,
+	AXP15060_IRQ_PEK_FAL_EDGE,
+	AXP15060_IRQ_PEK_RIS_EDGE,
+	AXP15060_IRQ_GPIO2_INPUT,
+};
+
 struct axp20x_dev {
 	struct device			*dev;
 	int				irq;
-- 
2.40.0

[PATCH v3 3/3] regulator: axp20x: Add AXP15060 support

[Shengyu Qu]

The AXP15060 is a typical I2C-controlled PMIC, seen on multiple boards
with different default register value. Current driver is tested on
Starfive Visionfive 2.

The RTCLDO is fixed, and cannot even be turned on or off. On top of
that, its voltage is customisable (either 1.8V or 3.3V). We pretend it's
a fixed 1.8V regulator since other AXP driver also do like this. Also,
BSP code ignores this regulator and it's not used according to VF2
schematic.

Describe the AXP15060's voltage settings and switch registers, how the
voltages are encoded, and connect this to the MFD device via its
regulator ID.

---
Changes since v2:
 - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
 - Fix some whitespace (Andre Przywara)
 - Rename swout to sw to keep up with bindings (Andre Przywara)
 - Add check for setting DC-DC frequency (Andre Przywara)

Changes since v1:
 - Nothing

[1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/

Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
---
 drivers/regulator/axp20x-regulator.c | 232 +++++++++++++++++++++++++--
 1 file changed, 223 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index db77c72d39a0..810f90f3e2a1 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -275,6 +275,74 @@
 
 #define AXP813_PWR_OUT_DCDC7_MASK	BIT_MASK(6)
 
+#define AXP15060_DCDC1_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_DCDC2_V_CTRL_MASK		GENMASK(6, 0)
+#define AXP15060_DCDC3_V_CTRL_MASK		GENMASK(6, 0)
+#define AXP15060_DCDC4_V_CTRL_MASK		GENMASK(6, 0)
+#define AXP15060_DCDC5_V_CTRL_MASK		GENMASK(6, 0)
+#define AXP15060_DCDC6_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_ALDO1_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_ALDO2_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_ALDO3_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_ALDO4_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_ALDO5_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_BLDO1_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_BLDO2_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_BLDO3_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_BLDO4_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_BLDO5_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_CLDO1_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_CLDO2_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_CLDO3_V_CTRL_MASK		GENMASK(4, 0)
+#define AXP15060_CLDO4_V_CTRL_MASK		GENMASK(5, 0)
+#define AXP15060_CPUSLDO_V_CTRL_MASK		GENMASK(3, 0)
+
+#define AXP15060_PWR_OUT_DCDC1_MASK	BIT_MASK(0)
+#define AXP15060_PWR_OUT_DCDC2_MASK	BIT_MASK(1)
+#define AXP15060_PWR_OUT_DCDC3_MASK	BIT_MASK(2)
+#define AXP15060_PWR_OUT_DCDC4_MASK	BIT_MASK(3)
+#define AXP15060_PWR_OUT_DCDC5_MASK	BIT_MASK(4)
+#define AXP15060_PWR_OUT_DCDC6_MASK	BIT_MASK(5)
+#define AXP15060_PWR_OUT_ALDO1_MASK	BIT_MASK(0)
+#define AXP15060_PWR_OUT_ALDO2_MASK	BIT_MASK(1)
+#define AXP15060_PWR_OUT_ALDO3_MASK	BIT_MASK(2)
+#define AXP15060_PWR_OUT_ALDO4_MASK	BIT_MASK(3)
+#define AXP15060_PWR_OUT_ALDO5_MASK	BIT_MASK(4)
+#define AXP15060_PWR_OUT_BLDO1_MASK	BIT_MASK(5)
+#define AXP15060_PWR_OUT_BLDO2_MASK	BIT_MASK(6)
+#define AXP15060_PWR_OUT_BLDO3_MASK	BIT_MASK(7)
+#define AXP15060_PWR_OUT_BLDO4_MASK	BIT_MASK(0)
+#define AXP15060_PWR_OUT_BLDO5_MASK	BIT_MASK(1)
+#define AXP15060_PWR_OUT_CLDO1_MASK	BIT_MASK(2)
+#define AXP15060_PWR_OUT_CLDO2_MASK	BIT_MASK(3)
+#define AXP15060_PWR_OUT_CLDO3_MASK	BIT_MASK(4)
+#define AXP15060_PWR_OUT_CLDO4_MASK	BIT_MASK(5)
+#define AXP15060_PWR_OUT_CPUSLDO_MASK	BIT_MASK(6)
+#define AXP15060_PWR_OUT_SW_MASK		BIT_MASK(7)
+
+#define AXP15060_DCDC23_POLYPHASE_DUAL_MASK		BIT_MASK(6)
+#define AXP15060_DCDC46_POLYPHASE_DUAL_MASK		BIT_MASK(7)
+
+#define AXP15060_DCDC234_500mV_START	0x00
+#define AXP15060_DCDC234_500mV_STEPS	70
+#define AXP15060_DCDC234_500mV_END		\
+	(AXP15060_DCDC234_500mV_START + AXP15060_DCDC234_500mV_STEPS)
+#define AXP15060_DCDC234_1220mV_START	0x47
+#define AXP15060_DCDC234_1220mV_STEPS	16
+#define AXP15060_DCDC234_1220mV_END		\
+	(AXP15060_DCDC234_1220mV_START + AXP15060_DCDC234_1220mV_STEPS)
+#define AXP15060_DCDC234_NUM_VOLTAGES	88
+
+#define AXP15060_DCDC5_800mV_START	0x00
+#define AXP15060_DCDC5_800mV_STEPS	32
+#define AXP15060_DCDC5_800mV_END		\
+	(AXP15060_DCDC5_800mV_START + AXP15060_DCDC5_800mV_STEPS)
+#define AXP15060_DCDC5_1140mV_START	0x21
+#define AXP15060_DCDC5_1140mV_STEPS	35
+#define AXP15060_DCDC5_1140mV_END		\
+	(AXP15060_DCDC5_1140mV_START + AXP15060_DCDC5_1140mV_STEPS)
+#define AXP15060_DCDC5_NUM_VOLTAGES	69
+
 #define AXP_DESC_IO(_family, _id, _match, _supply, _min, _max, _step, _vreg,	\
 		    _vmask, _ereg, _emask, _enable_val, _disable_val)		\
 	[_family##_##_id] = {							\
@@ -1048,6 +1116,104 @@ static const struct regulator_desc axp813_regulators[] = {
 		    AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DC1SW_MASK),
 };
 
+static const struct linear_range axp15060_dcdc234_ranges[] = {
+	REGULATOR_LINEAR_RANGE(500000,
+			       AXP15060_DCDC234_500mV_START,
+			       AXP15060_DCDC234_500mV_END,
+			       10000),
+	REGULATOR_LINEAR_RANGE(1220000,
+			       AXP15060_DCDC234_1220mV_START,
+			       AXP15060_DCDC234_1220mV_END,
+			       20000),
+};
+
+static const struct linear_range axp15060_dcdc5_ranges[] = {
+	REGULATOR_LINEAR_RANGE(800000,
+			       AXP15060_DCDC5_800mV_START,
+			       AXP15060_DCDC5_800mV_END,
+			       10000),
+	REGULATOR_LINEAR_RANGE(1140000,
+			       AXP15060_DCDC5_1140mV_START,
+			       AXP15060_DCDC5_1140mV_END,
+			       20000),
+};
+
+static const struct regulator_desc axp15060_regulators[] = {
+	AXP_DESC(AXP15060, DCDC1, "dcdc1", "vin1", 1500, 3400, 100,
+		 AXP15060_DCDC1_V_CTRL, AXP15060_DCDC1_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL1, AXP15060_PWR_OUT_DCDC1_MASK),
+	AXP_DESC_RANGES(AXP15060, DCDC2, "dcdc2", "vin2",
+			axp15060_dcdc234_ranges, AXP15060_DCDC234_NUM_VOLTAGES,
+			AXP15060_DCDC2_V_CTRL, AXP15060_DCDC2_V_CTRL_MASK,
+			AXP15060_PWR_OUT_CTRL1, AXP15060_PWR_OUT_DCDC2_MASK),
+	AXP_DESC_RANGES(AXP15060, DCDC3, "dcdc3", "vin3",
+			axp15060_dcdc234_ranges, AXP15060_DCDC234_NUM_VOLTAGES,
+			AXP15060_DCDC3_V_CTRL, AXP15060_DCDC3_V_CTRL_MASK,
+			AXP15060_PWR_OUT_CTRL1, AXP15060_PWR_OUT_DCDC3_MASK),
+	AXP_DESC_RANGES(AXP15060, DCDC4, "dcdc4", "vin4",
+			axp15060_dcdc234_ranges, AXP15060_DCDC234_NUM_VOLTAGES,
+			AXP15060_DCDC4_V_CTRL, AXP15060_DCDC4_V_CTRL_MASK,
+			AXP15060_PWR_OUT_CTRL1, AXP15060_PWR_OUT_DCDC4_MASK),
+	AXP_DESC_RANGES(AXP15060, DCDC5, "dcdc5", "vin5",
+			axp15060_dcdc5_ranges, AXP15060_DCDC5_NUM_VOLTAGES,
+			AXP15060_DCDC5_V_CTRL, AXP15060_DCDC5_V_CTRL_MASK,
+			AXP15060_PWR_OUT_CTRL1, AXP15060_PWR_OUT_DCDC5_MASK),
+	AXP_DESC(AXP15060, DCDC6, "dcdc6", "vin6", 500, 3400, 100,
+		 AXP15060_DCDC6_V_CTRL, AXP15060_DCDC6_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL1, AXP15060_PWR_OUT_DCDC6_MASK),
+	AXP_DESC(AXP15060, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+		 AXP15060_ALDO1_V_CTRL, AXP15060_ALDO1_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_ALDO1_MASK),
+	AXP_DESC(AXP15060, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+		 AXP15060_ALDO2_V_CTRL, AXP15060_ALDO2_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_ALDO2_MASK),
+	AXP_DESC(AXP15060, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+		 AXP15060_ALDO3_V_CTRL, AXP15060_ALDO3_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_ALDO3_MASK),
+	AXP_DESC(AXP15060, ALDO4, "aldo4", "aldoin", 700, 3300, 100,
+		 AXP15060_ALDO4_V_CTRL, AXP15060_ALDO4_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_ALDO4_MASK),
+	AXP_DESC(AXP15060, ALDO5, "aldo5", "aldoin", 700, 3300, 100,
+		 AXP15060_ALDO5_V_CTRL, AXP15060_ALDO5_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_ALDO5_MASK),
+	AXP_DESC(AXP15060, BLDO1, "bldo1", "bldoin", 700, 3300, 100,
+		 AXP15060_BLDO1_V_CTRL, AXP15060_BLDO1_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_BLDO1_MASK),
+	AXP_DESC(AXP15060, BLDO2, "bldo2", "bldoin", 700, 3300, 100,
+		 AXP15060_BLDO2_V_CTRL, AXP15060_BLDO2_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_BLDO2_MASK),
+	AXP_DESC(AXP15060, BLDO3, "bldo3", "bldoin", 700, 3300, 100,
+		 AXP15060_BLDO3_V_CTRL, AXP15060_BLDO3_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL2, AXP15060_PWR_OUT_BLDO3_MASK),
+	AXP_DESC(AXP15060, BLDO4, "bldo4", "bldoin", 700, 3300, 100,
+		 AXP15060_BLDO4_V_CTRL, AXP15060_BLDO4_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_BLDO4_MASK),
+	AXP_DESC(AXP15060, BLDO5, "bldo5", "bldoin", 700, 3300, 100,
+		 AXP15060_BLDO5_V_CTRL, AXP15060_BLDO5_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_BLDO5_MASK),
+	AXP_DESC(AXP15060, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
+		 AXP15060_CLDO1_V_CTRL, AXP15060_CLDO1_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_CLDO1_MASK),
+	AXP_DESC(AXP15060, CLDO2, "cldo2", "cldoin", 700, 3300, 100,
+		 AXP15060_CLDO2_V_CTRL, AXP15060_CLDO2_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_CLDO2_MASK),
+	AXP_DESC(AXP15060, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
+		 AXP15060_CLDO3_V_CTRL, AXP15060_CLDO3_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_CLDO3_MASK),
+	AXP_DESC(AXP15060, CLDO4, "cldo4", "cldoin", 700, 4200, 100,
+		 AXP15060_CLDO4_V_CTRL, AXP15060_CLDO4_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_CLDO4_MASK),
+	/* Supply comes from DCDC5 */
+	AXP_DESC(AXP15060, CPUSLDO, "cpusldo", NULL, 700, 1400, 50,
+		 AXP15060_CPUSLDO_V_CTRL, AXP15060_CPUSLDO_V_CTRL_MASK,
+		 AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_CPUSLDO_MASK),
+	/* Supply comes from DCDC1 */
+	AXP_DESC_SW(AXP15060, SW, "sw", NULL,
+		    AXP15060_PWR_OUT_CTRL3, AXP15060_PWR_OUT_SW_MASK),
+	/* Supply comes from ALDO1 */
+	AXP_DESC_FIXED(AXP15060, RTC_LDO, "rtc-ldo", NULL, 1800),
+};
+
 static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 {
 	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
@@ -1088,10 +1254,11 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		step = 150;
 		break;
 	case AXP313A_ID:
+	case AXP15060_ID:
 		/* The DCDC PWM frequency seems to be fixed to 3 MHz. */
 		if (dcdcfreq != 0) {
 			dev_err(&pdev->dev,
-				"DCDC frequency on AXP313a is fixed to 3 MHz.\n");
+				"DCDC frequency on this PMIC is fixed to 3 MHz.\n");
 			return -EINVAL;
 		}
 
@@ -1201,6 +1368,15 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 		workmode <<= id - AXP813_DCDC1;
 		break;
 
+	case AXP15060_ID:
+		reg = AXP15060_DCDC_MODE_CTRL2;
+		if (id < AXP15060_DCDC1 || id > AXP15060_DCDC6)
+			return -EINVAL;
+
+		mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP15060_DCDC1);
+		workmode <<= id - AXP15060_DCDC1;
+		break;
+
 	default:
 		/* should not happen */
 		WARN_ON(1);
@@ -1220,7 +1396,7 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
 
 	/*
 	 * Currently in our supported AXP variants, only AXP803, AXP806,
-	 * and AXP813 have polyphase regulators.
+	 * AXP813 and AXP15060 have polyphase regulators.
 	 */
 	switch (axp20x->variant) {
 	case AXP803_ID:
@@ -1252,6 +1428,17 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
 		}
 		break;
 
+	case AXP15060_ID:
+		regmap_read(axp20x->regmap, AXP15060_DCDC_MODE_CTRL1, &reg);
+
+		switch (id) {
+		case AXP15060_DCDC3:
+			return !!(reg & AXP15060_DCDC23_POLYPHASE_DUAL_MASK);
+		case AXP15060_DCDC6:
+			return !!(reg & AXP15060_DCDC46_POLYPHASE_DUAL_MASK);
+		}
+		break;
+
 	default:
 		return false;
 	}
@@ -1273,6 +1460,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 	u32 workmode;
 	const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
 	const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
+	const char *aldo1_name = axp15060_regulators[AXP15060_ALDO1].name;
 	bool drivevbus = false;
 
 	switch (axp20x->variant) {
@@ -1312,6 +1500,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
 						  "x-powers,drive-vbus-en");
 		break;
+	case AXP15060_ID:
+		regulators = axp15060_regulators;
+		nregulators = AXP15060_REG_ID_MAX;
+		break;
 	default:
 		dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
 			axp20x->variant);
@@ -1338,8 +1530,9 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 			continue;
 
 		/*
-		 * Regulators DC1SW and DC5LDO are connected internally,
-		 * so we have to handle their supply names separately.
+		 * Regulators DC1SW, DC5LDO and RTCLDO on AXP15060 are
+		 * connected internally, so we have to handle their supply
+		 * names separately.
 		 *
 		 * We always register the regulators in proper sequence,
 		 * so the supply names are correctly read. See the last
@@ -1348,7 +1541,8 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		 */
 		if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
 		    (regulators == axp803_regulators && i == AXP803_DC1SW) ||
-		    (regulators == axp809_regulators && i == AXP809_DC1SW)) {
+		    (regulators == axp809_regulators && i == AXP809_DC1SW) ||
+		    (regulators == axp15060_regulators && i == AXP15060_SW)) {
 			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
 						GFP_KERNEL);
 			if (!new_desc)
@@ -1360,7 +1554,8 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		}
 
 		if ((regulators == axp22x_regulators && i == AXP22X_DC5LDO) ||
-		    (regulators == axp809_regulators && i == AXP809_DC5LDO)) {
+		    (regulators == axp809_regulators && i == AXP809_DC5LDO) ||
+		    (regulators == axp15060_regulators && i == AXP15060_CPUSLDO)) {
 			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
 						GFP_KERNEL);
 			if (!new_desc)
@@ -1371,6 +1566,18 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 			desc = new_desc;
 		}
 
+
+		if (regulators == axp15060_regulators && i == AXP15060_RTC_LDO) {
+			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+						GFP_KERNEL);
+			if (!new_desc)
+				return -ENOMEM;
+
+			*new_desc = regulators[i];
+			new_desc->supply_name = aldo1_name;
+			desc = new_desc;
+		}
+
 		rdev = devm_regulator_register(&pdev->dev, desc, &config);
 		if (IS_ERR(rdev)) {
 			dev_err(&pdev->dev, "Failed to register %s\n",
@@ -1389,19 +1596,26 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		}
 
 		/*
-		 * Save AXP22X DCDC1 / DCDC5 regulator names for later.
+		 * Save AXP22X DCDC1 / DCDC5 / AXP15060 ALDO1 regulator names for later.
 		 */
 		if ((regulators == axp22x_regulators && i == AXP22X_DCDC1) ||
-		    (regulators == axp809_regulators && i == AXP809_DCDC1))
+		    (regulators == axp809_regulators && i == AXP809_DCDC1) ||
+		    (regulators == axp15060_regulators && i == AXP15060_DCDC1))
 			of_property_read_string(rdev->dev.of_node,
 						"regulator-name",
 						&dcdc1_name);
 
 		if ((regulators == axp22x_regulators && i == AXP22X_DCDC5) ||
-		    (regulators == axp809_regulators && i == AXP809_DCDC5))
+		    (regulators == axp809_regulators && i == AXP809_DCDC5) ||
+		    (regulators == axp15060_regulators && i == AXP15060_DCDC5))
 			of_property_read_string(rdev->dev.of_node,
 						"regulator-name",
 						&dcdc5_name);
+
+		if (regulators == axp15060_regulators && i == AXP15060_ALDO1)
+			of_property_read_string(rdev->dev.of_node,
+						"regulator-name",
+						&aldo1_name);
 	}
 
 	if (drivevbus) {
-- 
2.40.0

Re: [PATCH v3 3/3] regulator: axp20x: Add AXP15060 support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

On Fri, Apr 21, 2023 at 11:08:16PM +0800, Shengyu Qu wrote:
> The AXP15060 is a typical I2C-controlled PMIC, seen on multiple boards
> with different default register value. Current driver is tested on
> Starfive Visionfive 2.

Reviewed-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Lee Jones]

On Fri, 21 Apr 2023, Shengyu Qu wrote:

> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> via an I2C bus.
> 
> Describe the regmap and the MFD bits, along with the registers exposed
> via I2C. Eventually advertise the device using a new compatible string
> and add support for power off the system.
> 
> The driver would disable PEK function if IRQ is not configured in device
> tree, since some boards (For example, Starfive Visionfive 2) didn't
> connect IRQ line of PMIC to SOC.
> 
> GPIO function isn't enabled in this commit, since its configuration
> operation is different from any existing AXP PMICs and needs
> logic modification on existing driver. GPIO support might come in later
> patches.
> 
> ---

You must not use these above the tags or Git will drop them.

> Changes since v2:
>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
>  - Add axp_regulator_only_cells rather than directly using axp806_cells
>    for cases that IRQ line isn't connected.
> 
> Changes since v1:
>  - Nothing
> 
> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> 
> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> ---

Put change-logs here instead.

>  drivers/mfd/axp20x-i2c.c   |   2 +
>  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
>  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
>  3 files changed, 194 insertions(+)

I manually added the missing tags for this and the DT patch and applied.

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 1/3] dt-bindings: mfd: x-powers,axp152: Document the AXP15060 variant

[Lee Jones]

On Fri, 21 Apr 2023, Shengyu Qu wrote:

> The X-Powers AXP15060 is a PMIC seen on Starfive Visionfive 2 board. Add
> relative compatible item and CPUSLDO support and disables DC-DC
> frequency setting for it.
> 
> ---
> Changes since v2:
>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
>  - Disables DC-DC frequency setting (Andre Przywara)
> 
> Changes since v1:
>  - Move cpusldo before drivevbus (Krzysztof Kozlowski)
> 
> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> 
> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>  Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

(not sure if I've sent this before or not, but just to make sure):

Applied, thanks

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Andre Przywara]

On Wed, 26 Apr 2023 15:27:40 +0100
Lee Jones <lee@kernel.org> wrote:

Hi Lee,

I see this patch in Linus' tree, but something must have gone wrong here,
can you please check? See below ...

> On Fri, 21 Apr 2023, Shengyu Qu wrote:
> 
> > The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> > via an I2C bus.
> > 
> > Describe the regmap and the MFD bits, along with the registers exposed
> > via I2C. Eventually advertise the device using a new compatible string
> > and add support for power off the system.
> > 
> > The driver would disable PEK function if IRQ is not configured in device
> > tree, since some boards (For example, Starfive Visionfive 2) didn't
> > connect IRQ line of PMIC to SOC.
> > 
> > GPIO function isn't enabled in this commit, since its configuration
> > operation is different from any existing AXP PMICs and needs
> > logic modification on existing driver. GPIO support might come in later
> > patches.
> > 
> > ---  
> 
> You must not use these above the tags or Git will drop them.
> 
> > Changes since v2:
> >  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch

So this patch was based on the AXP313a series, but I don't see that in
Linus' tree (or in any of your trees, if I have checked correctly).
There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
the axp313a entry in the context lines.

> >  - Add axp_regulator_only_cells rather than directly using axp806_cells
> >    for cases that IRQ line isn't connected.
> > 
> > Changes since v1:
> >  - Nothing
> > 
> > [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> > 
> > Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> > ---  
> 
> Put change-logs here instead.
> 
> >  drivers/mfd/axp20x-i2c.c   |   2 +
> >  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
> >  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
> >  3 files changed, 194 insertions(+)  
> 
> I manually added the missing tags for this and the DT patch and applied.

So this patch doesn't list any tags aside from Shengyu's
Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
Krzysztof, which I don't see anywhere in the thread, he just reviewed the
binding patch, AFAICT. I see your tentative R-b: on v2, but with the
request to rebase and resend, which he did with v3. The applied patch
looks like v3, but not on the base commit this was send against.

So I am slightly confused, and am also wondering what happened to the
AXP313a patches? I see the binding patch merged, but not the MFD part,
even though you replied saying so.

Cheers,
Andre

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Krzysztof Kozlowski]

On 03/05/2023 13:07, Andre Przywara wrote:
> On Wed, 26 Apr 2023 15:27:40 +0100
> Lee Jones <lee@kernel.org> wrote:
> 
> Hi Lee,
> 
> I see this patch in Linus' tree, but something must have gone wrong here,
> can you please check? See below ...
> 
>> On Fri, 21 Apr 2023, Shengyu Qu wrote:
>>
>>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
>>> via an I2C bus.
>>>
>>> Describe the regmap and the MFD bits, along with the registers exposed
>>> via I2C. Eventually advertise the device using a new compatible string
>>> and add support for power off the system.
>>>
>>> The driver would disable PEK function if IRQ is not configured in device
>>> tree, since some boards (For example, Starfive Visionfive 2) didn't
>>> connect IRQ line of PMIC to SOC.
>>>
>>> GPIO function isn't enabled in this commit, since its configuration
>>> operation is different from any existing AXP PMICs and needs
>>> logic modification on existing driver. GPIO support might come in later
>>> patches.
>>>
>>> ---  
>>
>> You must not use these above the tags or Git will drop them.
>>
>>> Changes since v2:
>>>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
> 
> So this patch was based on the AXP313a series, but I don't see that in
> Linus' tree (or in any of your trees, if I have checked correctly).
> There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
> the axp313a entry in the context lines.
> 
>>>  - Add axp_regulator_only_cells rather than directly using axp806_cells
>>>    for cases that IRQ line isn't connected.
>>>
>>> Changes since v1:
>>>  - Nothing
>>>
>>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
>>>
>>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
>>> ---  
>>
>> Put change-logs here instead.
>>
>>>  drivers/mfd/axp20x-i2c.c   |   2 +
>>>  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
>>>  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
>>>  3 files changed, 194 insertions(+)  
>>
>> I manually added the missing tags for this and the DT patch and applied.
> 
> So this patch doesn't list any tags aside from Shengyu's
> Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
> Krzysztof, which I don't see anywhere in the thread, he just reviewed the
> binding patch, AFAICT. 

Yep, I never reviewed this.

> I see your tentative R-b: on v2, but with the
> request to rebase and resend, which he did with v3. The applied patch
> looks like v3, but not on the base commit this was send against.
> 
> So I am slightly confused, and am also wondering what happened to the
> AXP313a patches? I see the binding patch merged, but not the MFD part,
> even though you replied saying so.

Because the patch #1 was broken, see:
https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/

The SoB and Reviewed-by were after --- and apparently b4 understood it
as cover letter and applied everywhere.

Lee,
Do you have the latest b4? If yes, this should be reported as b4 bug,
assuming you used it.

Best regards,
Krzysztof

Re: [PATCH v3 3/3] regulator: axp20x: Add AXP15060 support

[Krzysztof Kozlowski]

On 21/04/2023 17:08, Shengyu Qu wrote:
> The AXP15060 is a typical I2C-controlled PMIC, seen on multiple boards
> with different default register value. Current driver is tested on
> Starfive Visionfive 2.
> 
> The RTCLDO is fixed, and cannot even be turned on or off. On top of
> that, its voltage is customisable (either 1.8V or 3.3V). We pretend it's
> a fixed 1.8V regulator since other AXP driver also do like this. Also,
> BSP code ignores this regulator and it's not used according to VF2
> schematic.
> 
> Describe the AXP15060's voltage settings and switch registers, how the
> voltages are encoded, and connect this to the MFD device via its
> regulator ID.
> 
> ---
> Changes since v2:
>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
>  - Fix some whitespace (Andre Przywara)
>  - Rename swout to sw to keep up with bindings (Andre Przywara)
>  - Add check for setting DC-DC frequency (Andre Przywara)
> 
> Changes since v1:
>  - Nothing
> 
> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> 
> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>

This was not applied, so you can still fix it.

Broken patch trailer / SoB.

Best regards,
Krzysztof

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Lee Jones]

On Thu, 04 May 2023, Krzysztof Kozlowski wrote:

> On 03/05/2023 13:07, Andre Przywara wrote:
> > On Wed, 26 Apr 2023 15:27:40 +0100
> > Lee Jones <lee@kernel.org> wrote:
> > 
> > Hi Lee,
> > 
> > I see this patch in Linus' tree, but something must have gone wrong here,
> > can you please check? See below ...
> > 
> >> On Fri, 21 Apr 2023, Shengyu Qu wrote:
> >>
> >>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> >>> via an I2C bus.
> >>>
> >>> Describe the regmap and the MFD bits, along with the registers exposed
> >>> via I2C. Eventually advertise the device using a new compatible string
> >>> and add support for power off the system.
> >>>
> >>> The driver would disable PEK function if IRQ is not configured in device
> >>> tree, since some boards (For example, Starfive Visionfive 2) didn't
> >>> connect IRQ line of PMIC to SOC.
> >>>
> >>> GPIO function isn't enabled in this commit, since its configuration
> >>> operation is different from any existing AXP PMICs and needs
> >>> logic modification on existing driver. GPIO support might come in later
> >>> patches.
> >>>
> >>> ---  
> >>
> >> You must not use these above the tags or Git will drop them.
> >>
> >>> Changes since v2:
> >>>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
> > 
> > So this patch was based on the AXP313a series, but I don't see that in
> > Linus' tree (or in any of your trees, if I have checked correctly).
> > There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
> > the axp313a entry in the context lines.
> > 
> >>>  - Add axp_regulator_only_cells rather than directly using axp806_cells
> >>>    for cases that IRQ line isn't connected.
> >>>
> >>> Changes since v1:
> >>>  - Nothing
> >>>
> >>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> >>>
> >>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> >>> ---  
> >>
> >> Put change-logs here instead.
> >>
> >>>  drivers/mfd/axp20x-i2c.c   |   2 +
> >>>  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
> >>>  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
> >>>  3 files changed, 194 insertions(+)  
> >>
> >> I manually added the missing tags for this and the DT patch and applied.
> > 
> > So this patch doesn't list any tags aside from Shengyu's
> > Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
> > Krzysztof, which I don't see anywhere in the thread, he just reviewed the
> > binding patch, AFAICT. 
> 
> Yep, I never reviewed this.
> 
> > I see your tentative R-b: on v2, but with the
> > request to rebase and resend, which he did with v3. The applied patch
> > looks like v3, but not on the base commit this was send against.
> > 
> > So I am slightly confused, and am also wondering what happened to the
> > AXP313a patches? I see the binding patch merged, but not the MFD part,
> > even though you replied saying so.
> 
> Because the patch #1 was broken, see:
> https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
> 
> The SoB and Reviewed-by were after --- and apparently b4 understood it
> as cover letter and applied everywhere.
> 
> Lee,
> Do you have the latest b4? If yes, this should be reported as b4 bug,
> assuming you used it.

I am using b4, although the version I'm using is quite old (0.9.0).

Also, this was quite some time ago - I have slept since applying this
and do not distinctly remember doing so.  Thus, the application of your
R-b may well have been a mistake on my part.  I'll keep an eye for such
things in the future and if I see (and remember) an issue, I'll report
it.

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Lee Jones]

On Mon, 15 May 2023, Lee Jones wrote:

> On Thu, 04 May 2023, Krzysztof Kozlowski wrote:
> 
> > On 03/05/2023 13:07, Andre Przywara wrote:
> > > On Wed, 26 Apr 2023 15:27:40 +0100
> > > Lee Jones <lee@kernel.org> wrote:
> > > 
> > > Hi Lee,
> > > 
> > > I see this patch in Linus' tree, but something must have gone wrong here,
> > > can you please check? See below ...
> > > 
> > >> On Fri, 21 Apr 2023, Shengyu Qu wrote:
> > >>
> > >>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> > >>> via an I2C bus.
> > >>>
> > >>> Describe the regmap and the MFD bits, along with the registers exposed
> > >>> via I2C. Eventually advertise the device using a new compatible string
> > >>> and add support for power off the system.
> > >>>
> > >>> The driver would disable PEK function if IRQ is not configured in device
> > >>> tree, since some boards (For example, Starfive Visionfive 2) didn't
> > >>> connect IRQ line of PMIC to SOC.
> > >>>
> > >>> GPIO function isn't enabled in this commit, since its configuration
> > >>> operation is different from any existing AXP PMICs and needs
> > >>> logic modification on existing driver. GPIO support might come in later
> > >>> patches.
> > >>>
> > >>> ---  
> > >>
> > >> You must not use these above the tags or Git will drop them.
> > >>
> > >>> Changes since v2:
> > >>>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
> > > 
> > > So this patch was based on the AXP313a series, but I don't see that in
> > > Linus' tree (or in any of your trees, if I have checked correctly).
> > > There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
> > > the axp313a entry in the context lines.
> > > 
> > >>>  - Add axp_regulator_only_cells rather than directly using axp806_cells
> > >>>    for cases that IRQ line isn't connected.
> > >>>
> > >>> Changes since v1:
> > >>>  - Nothing
> > >>>
> > >>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> > >>>
> > >>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> > >>> ---  
> > >>
> > >> Put change-logs here instead.
> > >>
> > >>>  drivers/mfd/axp20x-i2c.c   |   2 +
> > >>>  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
> > >>>  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
> > >>>  3 files changed, 194 insertions(+)  
> > >>
> > >> I manually added the missing tags for this and the DT patch and applied.
> > > 
> > > So this patch doesn't list any tags aside from Shengyu's
> > > Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
> > > Krzysztof, which I don't see anywhere in the thread, he just reviewed the
> > > binding patch, AFAICT. 
> > 
> > Yep, I never reviewed this.
> > 
> > > I see your tentative R-b: on v2, but with the
> > > request to rebase and resend, which he did with v3. The applied patch
> > > looks like v3, but not on the base commit this was send against.
> > > 
> > > So I am slightly confused, and am also wondering what happened to the
> > > AXP313a patches? I see the binding patch merged, but not the MFD part,
> > > even though you replied saying so.
> > 
> > Because the patch #1 was broken, see:
> > https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
> > 
> > The SoB and Reviewed-by were after --- and apparently b4 understood it
> > as cover letter and applied everywhere.
> > 
> > Lee,
> > Do you have the latest b4? If yes, this should be reported as b4 bug,
> > assuming you used it.
> 
> I am using b4, although the version I'm using is quite old (0.9.0).
> 
> Also, this was quite some time ago - I have slept since applying this
> and do not distinctly remember doing so.  Thus, the application of your
> R-b may well have been a mistake on my part.  I'll keep an eye for such
> things in the future and if I see (and remember) an issue, I'll report
> it.

FYI, I just upgraded to 0.12.2.

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Shengyu Qu]

[-- Attachment #1.1.1: Type: text/plain, Size: 3966 bytes --]

Hi Lee,

Why there's no news about patch 3 for my series and axp313a series?

It can't work without patch 3. And could we see the fix for patch1/2 in

next RC?

Best regards,

Shengyu

> On Thu, 04 May 2023, Krzysztof Kozlowski wrote:
>
>> On 03/05/2023 13:07, Andre Przywara wrote:
>>> On Wed, 26 Apr 2023 15:27:40 +0100
>>> Lee Jones <lee@kernel.org> wrote:
>>>
>>> Hi Lee,
>>>
>>> I see this patch in Linus' tree, but something must have gone wrong here,
>>> can you please check? See below ...
>>>
>>>> On Fri, 21 Apr 2023, Shengyu Qu wrote:
>>>>
>>>>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
>>>>> via an I2C bus.
>>>>>
>>>>> Describe the regmap and the MFD bits, along with the registers exposed
>>>>> via I2C. Eventually advertise the device using a new compatible string
>>>>> and add support for power off the system.
>>>>>
>>>>> The driver would disable PEK function if IRQ is not configured in device
>>>>> tree, since some boards (For example, Starfive Visionfive 2) didn't
>>>>> connect IRQ line of PMIC to SOC.
>>>>>
>>>>> GPIO function isn't enabled in this commit, since its configuration
>>>>> operation is different from any existing AXP PMICs and needs
>>>>> logic modification on existing driver. GPIO support might come in later
>>>>> patches.
>>>>>
>>>>> ---
>>>> You must not use these above the tags or Git will drop them.
>>>>
>>>>> Changes since v2:
>>>>>   - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
>>> So this patch was based on the AXP313a series, but I don't see that in
>>> Linus' tree (or in any of your trees, if I have checked correctly).
>>> There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
>>> the axp313a entry in the context lines.
>>>
>>>>>   - Add axp_regulator_only_cells rather than directly using axp806_cells
>>>>>     for cases that IRQ line isn't connected.
>>>>>
>>>>> Changes since v1:
>>>>>   - Nothing
>>>>>
>>>>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
>>>>>
>>>>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
>>>>> ---
>>>> Put change-logs here instead.
>>>>
>>>>>   drivers/mfd/axp20x-i2c.c   |   2 +
>>>>>   drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
>>>>>   include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
>>>>>   3 files changed, 194 insertions(+)
>>>> I manually added the missing tags for this and the DT patch and applied.
>>> So this patch doesn't list any tags aside from Shengyu's
>>> Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
>>> Krzysztof, which I don't see anywhere in the thread, he just reviewed the
>>> binding patch, AFAICT.
>> Yep, I never reviewed this.
>>
>>> I see your tentative R-b: on v2, but with the
>>> request to rebase and resend, which he did with v3. The applied patch
>>> looks like v3, but not on the base commit this was send against.
>>>
>>> So I am slightly confused, and am also wondering what happened to the
>>> AXP313a patches? I see the binding patch merged, but not the MFD part,
>>> even though you replied saying so.
>> Because the patch #1 was broken, see:
>> https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
>>
>> The SoB and Reviewed-by were after --- and apparently b4 understood it
>> as cover letter and applied everywhere.
>>
>> Lee,
>> Do you have the latest b4? If yes, this should be reported as b4 bug,
>> assuming you used it.
> I am using b4, although the version I'm using is quite old (0.9.0).
>
> Also, this was quite some time ago - I have slept since applying this
> and do not distinctly remember doing so.  Thus, the application of your
> R-b may well have been a mistake on my part.  I'll keep an eye for such
> things in the future and if I see (and remember) an issue, I'll report
> it.
>

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Krzysztof Kozlowski]

On 15/05/2023 16:19, Shengyu Qu wrote:
> Hi Lee,
> 
> Why there's no news about patch 3 for my series and axp313a series?
> 
> It can't work without patch 3. And could we see the fix for patch1/2 in

You got feedback, didn't you? Patch is broken. Don't ping to apply
broken patch, but fix the patch and send a new version.

Best regards,
Krzysztof

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Andre Przywara]

On Mon, 15 May 2023 11:52:29 +0100
Lee Jones <lee@kernel.org> wrote:

> On Thu, 04 May 2023, Krzysztof Kozlowski wrote:
> 
> > On 03/05/2023 13:07, Andre Przywara wrote:  
> > > On Wed, 26 Apr 2023 15:27:40 +0100
> > > Lee Jones <lee@kernel.org> wrote:
> > > 
> > > Hi Lee,
> > > 
> > > I see this patch in Linus' tree, but something must have gone wrong here,
> > > can you please check? See below ...
> > >   
> > >> On Fri, 21 Apr 2023, Shengyu Qu wrote:
> > >>  
> > >>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> > >>> via an I2C bus.
> > >>>
> > >>> Describe the regmap and the MFD bits, along with the registers exposed
> > >>> via I2C. Eventually advertise the device using a new compatible string
> > >>> and add support for power off the system.
> > >>>
> > >>> The driver would disable PEK function if IRQ is not configured in device
> > >>> tree, since some boards (For example, Starfive Visionfive 2) didn't
> > >>> connect IRQ line of PMIC to SOC.
> > >>>
> > >>> GPIO function isn't enabled in this commit, since its configuration
> > >>> operation is different from any existing AXP PMICs and needs
> > >>> logic modification on existing driver. GPIO support might come in later
> > >>> patches.
> > >>>
> > >>> ---    
> > >>
> > >> You must not use these above the tags or Git will drop them.
> > >>  
> > >>> Changes since v2:
> > >>>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch  
> > > 
> > > So this patch was based on the AXP313a series, but I don't see that in
> > > Linus' tree (or in any of your trees, if I have checked correctly).
> > > There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
> > > the axp313a entry in the context lines.
> > >   
> > >>>  - Add axp_regulator_only_cells rather than directly using axp806_cells
> > >>>    for cases that IRQ line isn't connected.
> > >>>
> > >>> Changes since v1:
> > >>>  - Nothing
> > >>>
> > >>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> > >>>
> > >>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> > >>> ---    
> > >>
> > >> Put change-logs here instead.
> > >>  
> > >>>  drivers/mfd/axp20x-i2c.c   |   2 +
> > >>>  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
> > >>>  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
> > >>>  3 files changed, 194 insertions(+)    
> > >>
> > >> I manually added the missing tags for this and the DT patch and applied.  
> > > 
> > > So this patch doesn't list any tags aside from Shengyu's
> > > Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
> > > Krzysztof, which I don't see anywhere in the thread, he just reviewed the
> > > binding patch, AFAICT.   
> > 
> > Yep, I never reviewed this.
> >   
> > > I see your tentative R-b: on v2, but with the
> > > request to rebase and resend, which he did with v3. The applied patch
> > > looks like v3, but not on the base commit this was send against.
> > > 
> > > So I am slightly confused, and am also wondering what happened to the
> > > AXP313a patches? I see the binding patch merged, but not the MFD part,
> > > even though you replied saying so.  
> > 
> > Because the patch #1 was broken, see:
> > https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
> > 
> > The SoB and Reviewed-by were after --- and apparently b4 understood it
> > as cover letter and applied everywhere.
> > 
> > Lee,
> > Do you have the latest b4? If yes, this should be reported as b4 bug,
> > assuming you used it.  
> 
> I am using b4, although the version I'm using is quite old (0.9.0).
> 
> Also, this was quite some time ago - I have slept since applying this
> and do not distinctly remember doing so.  Thus, the application of your
> R-b may well have been a mistake on my part.  I'll keep an eye for such
> things in the future and if I see (and remember) an issue, I'll report
> it.

So what are we going to do about the two series now? I guess it's not
worthwhile to revert Shengyu's patch, just for the wrong R-b: tag?
So does this mean both series should be rebased on top of that and re-sent?

Cheers,
Andre

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Lee Jones]

On Mon, 15 May 2023, Andre Przywara wrote:

> On Mon, 15 May 2023 11:52:29 +0100
> Lee Jones <lee@kernel.org> wrote:
> 
> > On Thu, 04 May 2023, Krzysztof Kozlowski wrote:
> > 
> > > On 03/05/2023 13:07, Andre Przywara wrote:  
> > > > On Wed, 26 Apr 2023 15:27:40 +0100
> > > > Lee Jones <lee@kernel.org> wrote:
> > > > 
> > > > Hi Lee,
> > > > 
> > > > I see this patch in Linus' tree, but something must have gone wrong here,
> > > > can you please check? See below ...
> > > >   
> > > >> On Fri, 21 Apr 2023, Shengyu Qu wrote:
> > > >>  
> > > >>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> > > >>> via an I2C bus.
> > > >>>
> > > >>> Describe the regmap and the MFD bits, along with the registers exposed
> > > >>> via I2C. Eventually advertise the device using a new compatible string
> > > >>> and add support for power off the system.
> > > >>>
> > > >>> The driver would disable PEK function if IRQ is not configured in device
> > > >>> tree, since some boards (For example, Starfive Visionfive 2) didn't
> > > >>> connect IRQ line of PMIC to SOC.
> > > >>>
> > > >>> GPIO function isn't enabled in this commit, since its configuration
> > > >>> operation is different from any existing AXP PMICs and needs
> > > >>> logic modification on existing driver. GPIO support might come in later
> > > >>> patches.
> > > >>>
> > > >>> ---    
> > > >>
> > > >> You must not use these above the tags or Git will drop them.
> > > >>  
> > > >>> Changes since v2:
> > > >>>  - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch  
> > > > 
> > > > So this patch was based on the AXP313a series, but I don't see that in
> > > > Linus' tree (or in any of your trees, if I have checked correctly).
> > > > There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
> > > > the axp313a entry in the context lines.
> > > >   
> > > >>>  - Add axp_regulator_only_cells rather than directly using axp806_cells
> > > >>>    for cases that IRQ line isn't connected.
> > > >>>
> > > >>> Changes since v1:
> > > >>>  - Nothing
> > > >>>
> > > >>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> > > >>>
> > > >>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> > > >>> ---    
> > > >>
> > > >> Put change-logs here instead.
> > > >>  
> > > >>>  drivers/mfd/axp20x-i2c.c   |   2 +
> > > >>>  drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
> > > >>>  include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
> > > >>>  3 files changed, 194 insertions(+)    
> > > >>
> > > >> I manually added the missing tags for this and the DT patch and applied.  
> > > > 
> > > > So this patch doesn't list any tags aside from Shengyu's
> > > > Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
> > > > Krzysztof, which I don't see anywhere in the thread, he just reviewed the
> > > > binding patch, AFAICT.   
> > > 
> > > Yep, I never reviewed this.
> > >   
> > > > I see your tentative R-b: on v2, but with the
> > > > request to rebase and resend, which he did with v3. The applied patch
> > > > looks like v3, but not on the base commit this was send against.
> > > > 
> > > > So I am slightly confused, and am also wondering what happened to the
> > > > AXP313a patches? I see the binding patch merged, but not the MFD part,
> > > > even though you replied saying so.  
> > > 
> > > Because the patch #1 was broken, see:
> > > https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
> > > 
> > > The SoB and Reviewed-by were after --- and apparently b4 understood it
> > > as cover letter and applied everywhere.
> > > 
> > > Lee,
> > > Do you have the latest b4? If yes, this should be reported as b4 bug,
> > > assuming you used it.  
> > 
> > I am using b4, although the version I'm using is quite old (0.9.0).
> > 
> > Also, this was quite some time ago - I have slept since applying this
> > and do not distinctly remember doing so.  Thus, the application of your
> > R-b may well have been a mistake on my part.  I'll keep an eye for such
> > things in the future and if I see (and remember) an issue, I'll report
> > it.
> 
> So what are we going to do about the two series now? I guess it's not
> worthwhile to revert Shengyu's patch, just for the wrong R-b: tag?

No, I won't be reverting any patches.

> So does this mean both series should be rebased on top of that and re-sent?

Yes please.

-- 
Lee Jones [李琼斯]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Shengyu Qu]

[-- Attachment #1.1.1: Type: text/plain, Size: 4524 bytes --]

Hi Andre,

Please ping me if your new version of axp313a series is sent, I would update

mine as soon as possible.

Best regards,

Shengyu

> On Mon, 15 May 2023, Andre Przywara wrote:
>
>> On Mon, 15 May 2023 11:52:29 +0100
>> Lee Jones <lee@kernel.org> wrote:
>>
>>> On Thu, 04 May 2023, Krzysztof Kozlowski wrote:
>>>
>>>> On 03/05/2023 13:07, Andre Przywara wrote:
>>>>> On Wed, 26 Apr 2023 15:27:40 +0100
>>>>> Lee Jones <lee@kernel.org> wrote:
>>>>>
>>>>> Hi Lee,
>>>>>
>>>>> I see this patch in Linus' tree, but something must have gone wrong here,
>>>>> can you please check? See below ...
>>>>>    
>>>>>> On Fri, 21 Apr 2023, Shengyu Qu wrote:
>>>>>>   
>>>>>>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
>>>>>>> via an I2C bus.
>>>>>>>
>>>>>>> Describe the regmap and the MFD bits, along with the registers exposed
>>>>>>> via I2C. Eventually advertise the device using a new compatible string
>>>>>>> and add support for power off the system.
>>>>>>>
>>>>>>> The driver would disable PEK function if IRQ is not configured in device
>>>>>>> tree, since some boards (For example, Starfive Visionfive 2) didn't
>>>>>>> connect IRQ line of PMIC to SOC.
>>>>>>>
>>>>>>> GPIO function isn't enabled in this commit, since its configuration
>>>>>>> operation is different from any existing AXP PMICs and needs
>>>>>>> logic modification on existing driver. GPIO support might come in later
>>>>>>> patches.
>>>>>>>
>>>>>>> ---
>>>>>> You must not use these above the tags or Git will drop them.
>>>>>>   
>>>>>>> Changes since v2:
>>>>>>>   - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch
>>>>> So this patch was based on the AXP313a series, but I don't see that in
>>>>> Linus' tree (or in any of your trees, if I have checked correctly).
>>>>> There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
>>>>> the axp313a entry in the context lines.
>>>>>    
>>>>>>>   - Add axp_regulator_only_cells rather than directly using axp806_cells
>>>>>>>     for cases that IRQ line isn't connected.
>>>>>>>
>>>>>>> Changes since v1:
>>>>>>>   - Nothing
>>>>>>>
>>>>>>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
>>>>>>>
>>>>>>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
>>>>>>> ---
>>>>>> Put change-logs here instead.
>>>>>>   
>>>>>>>   drivers/mfd/axp20x-i2c.c   |   2 +
>>>>>>>   drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
>>>>>>>   include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
>>>>>>>   3 files changed, 194 insertions(+)
>>>>>> I manually added the missing tags for this and the DT patch and applied.
>>>>> So this patch doesn't list any tags aside from Shengyu's
>>>>> Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
>>>>> Krzysztof, which I don't see anywhere in the thread, he just reviewed the
>>>>> binding patch, AFAICT.
>>>> Yep, I never reviewed this.
>>>>    
>>>>> I see your tentative R-b: on v2, but with the
>>>>> request to rebase and resend, which he did with v3. The applied patch
>>>>> looks like v3, but not on the base commit this was send against.
>>>>>
>>>>> So I am slightly confused, and am also wondering what happened to the
>>>>> AXP313a patches? I see the binding patch merged, but not the MFD part,
>>>>> even though you replied saying so.
>>>> Because the patch #1 was broken, see:
>>>> https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
>>>>
>>>> The SoB and Reviewed-by were after --- and apparently b4 understood it
>>>> as cover letter and applied everywhere.
>>>>
>>>> Lee,
>>>> Do you have the latest b4? If yes, this should be reported as b4 bug,
>>>> assuming you used it.
>>> I am using b4, although the version I'm using is quite old (0.9.0).
>>>
>>> Also, this was quite some time ago - I have slept since applying this
>>> and do not distinctly remember doing so.  Thus, the application of your
>>> R-b may well have been a mistake on my part.  I'll keep an eye for such
>>> things in the future and if I see (and remember) an issue, I'll report
>>> it.
>> So what are we going to do about the two series now? I guess it's not
>> worthwhile to revert Shengyu's patch, just for the wrong R-b: tag?
> No, I won't be reverting any patches.
>
>> So does this mean both series should be rebased on top of that and re-sent?
> Yes please.
>

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 2/3] mfd: axp20x: Add support for AXP15060 PMIC

[Andre Przywara]

On Mon, 15 May 2023 23:44:03 +0800
Shengyu Qu <wiagn233@outlook.com> wrote:

Hi Shengyu,

> Please ping me if your new version of axp313a series is sent, I would update
> mine as soon as possible.

as you have probably seen, I have just sent out a new version, and
included the one remaining patch from your series. So there is no
need from your side for any further post. I'd just be grateful if you
could test the final result.

Cheers,
Andre

> > On Mon, 15 May 2023, Andre Przywara wrote:
> >  
> >> On Mon, 15 May 2023 11:52:29 +0100
> >> Lee Jones <lee@kernel.org> wrote:
> >>  
> >>> On Thu, 04 May 2023, Krzysztof Kozlowski wrote:
> >>>  
> >>>> On 03/05/2023 13:07, Andre Przywara wrote:  
> >>>>> On Wed, 26 Apr 2023 15:27:40 +0100
> >>>>> Lee Jones <lee@kernel.org> wrote:
> >>>>>
> >>>>> Hi Lee,
> >>>>>
> >>>>> I see this patch in Linus' tree, but something must have gone wrong here,
> >>>>> can you please check? See below ...
> >>>>>      
> >>>>>> On Fri, 21 Apr 2023, Shengyu Qu wrote:
> >>>>>>     
> >>>>>>> The AXP15060 is a PMIC chip produced by X-Powers, and could be connected
> >>>>>>> via an I2C bus.
> >>>>>>>
> >>>>>>> Describe the regmap and the MFD bits, along with the registers exposed
> >>>>>>> via I2C. Eventually advertise the device using a new compatible string
> >>>>>>> and add support for power off the system.
> >>>>>>>
> >>>>>>> The driver would disable PEK function if IRQ is not configured in device
> >>>>>>> tree, since some boards (For example, Starfive Visionfive 2) didn't
> >>>>>>> connect IRQ line of PMIC to SOC.
> >>>>>>>
> >>>>>>> GPIO function isn't enabled in this commit, since its configuration
> >>>>>>> operation is different from any existing AXP PMICs and needs
> >>>>>>> logic modification on existing driver. GPIO support might come in later
> >>>>>>> patches.
> >>>>>>>
> >>>>>>> ---  
> >>>>>> You must not use these above the tags or Git will drop them.
> >>>>>>     
> >>>>>>> Changes since v2:
> >>>>>>>   - Rebase to AXP313a series v10 [1] + newest (20230420) -next branch  
> >>>>> So this patch was based on the AXP313a series, but I don't see that in
> >>>>> Linus' tree (or in any of your trees, if I have checked correctly).
> >>>>> There must have been a conflict, as this [PATCH v3 2/3] diff actually lists
> >>>>> the axp313a entry in the context lines.
> >>>>>      
> >>>>>>>   - Add axp_regulator_only_cells rather than directly using axp806_cells
> >>>>>>>     for cases that IRQ line isn't connected.
> >>>>>>>
> >>>>>>> Changes since v1:
> >>>>>>>   - Nothing
> >>>>>>>
> >>>>>>> [1] https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/
> >>>>>>>
> >>>>>>> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> >>>>>>> ---  
> >>>>>> Put change-logs here instead.
> >>>>>>     
> >>>>>>>   drivers/mfd/axp20x-i2c.c   |   2 +
> >>>>>>>   drivers/mfd/axp20x.c       | 107 +++++++++++++++++++++++++++++++++++++
> >>>>>>>   include/linux/mfd/axp20x.h |  85 +++++++++++++++++++++++++++++
> >>>>>>>   3 files changed, 194 insertions(+)  
> >>>>>> I manually added the missing tags for this and the DT patch and applied.  
> >>>>> So this patch doesn't list any tags aside from Shengyu's
> >>>>> Signed-off-by. The patch in Linus' tree list a Reviewed-by: from
> >>>>> Krzysztof, which I don't see anywhere in the thread, he just reviewed the
> >>>>> binding patch, AFAICT.  
> >>>> Yep, I never reviewed this.
> >>>>      
> >>>>> I see your tentative R-b: on v2, but with the
> >>>>> request to rebase and resend, which he did with v3. The applied patch
> >>>>> looks like v3, but not on the base commit this was send against.
> >>>>>
> >>>>> So I am slightly confused, and am also wondering what happened to the
> >>>>> AXP313a patches? I see the binding patch merged, but not the MFD part,
> >>>>> even though you replied saying so.  
> >>>> Because the patch #1 was broken, see:
> >>>> https://lore.kernel.org/all/TY3P286MB261177CF7AA2959BD9517DA998609@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM/
> >>>>
> >>>> The SoB and Reviewed-by were after --- and apparently b4 understood it
> >>>> as cover letter and applied everywhere.
> >>>>
> >>>> Lee,
> >>>> Do you have the latest b4? If yes, this should be reported as b4 bug,
> >>>> assuming you used it.  
> >>> I am using b4, although the version I'm using is quite old (0.9.0).
> >>>
> >>> Also, this was quite some time ago - I have slept since applying this
> >>> and do not distinctly remember doing so.  Thus, the application of your
> >>> R-b may well have been a mistake on my part.  I'll keep an eye for such
> >>> things in the future and if I see (and remember) an issue, I'll report
> >>> it.  
> >> So what are we going to do about the two series now? I guess it's not
> >> worthwhile to revert Shengyu's patch, just for the wrong R-b: tag?  
> > No, I won't be reverting any patches.
> >  
> >> So does this mean both series should be rebased on top of that and re-sent?  
> > Yes please.
> >