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/[email protected]/
Signed-off-by: Shengyu Qu <[email protected]>
---
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
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/[email protected]/
>
> Signed-off-by: Shengyu Qu <[email protected]>
> ---
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 [李琼斯]
On Wed, 26 Apr 2023 15:27:40 +0100
Lee Jones <[email protected]> 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/[email protected]/
> >
> > Signed-off-by: Shengyu Qu <[email protected]>
> > ---
>
> 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
On 03/05/2023 13:07, Andre Przywara wrote:
> On Wed, 26 Apr 2023 15:27:40 +0100
> Lee Jones <[email protected]> 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/[email protected]/
>>>
>>> Signed-off-by: Shengyu Qu <[email protected]>
>>> ---
>>
>> 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
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 <[email protected]> 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/[email protected]/
> > >>>
> > >>> Signed-off-by: Shengyu Qu <[email protected]>
> > >>> ---
> > >>
> > >> 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 [李琼斯]
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 <[email protected]> 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/[email protected]/
> >>>
> >>> Signed-off-by: Shengyu Qu <[email protected]>
> >>> ---
> >>
> >> 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 [李琼斯]
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 <[email protected]> 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/[email protected]/
>>>>>
>>>>> Signed-off-by: Shengyu Qu <[email protected]>
>>>>> ---
>>>> 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.
>
On Mon, 15 May 2023 11:52:29 +0100
Lee Jones <[email protected]> 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 <[email protected]> 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/[email protected]/
> > >>>
> > >>> Signed-off-by: Shengyu Qu <[email protected]>
> > >>> ---
> > >>
> > >> 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
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
On Mon, 15 May 2023, Andre Przywara wrote:
> On Mon, 15 May 2023 11:52:29 +0100
> Lee Jones <[email protected]> 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 <[email protected]> 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/[email protected]/
> > > >>>
> > > >>> Signed-off-by: Shengyu Qu <[email protected]>
> > > >>> ---
> > > >>
> > > >> 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 [李琼斯]
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 <[email protected]> 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 <[email protected]> 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/[email protected]/
>>>>>>>
>>>>>>> Signed-off-by: Shengyu Qu <[email protected]>
>>>>>>> ---
>>>>>> 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.
>
On Mon, 15 May 2023 23:44:03 +0800
Shengyu Qu <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/[email protected]/
> >>>>>>>
> >>>>>>> Signed-off-by: Shengyu Qu <[email protected]>
> >>>>>>> ---
> >>>>>> 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.
> >