* [PATCH v3 15/16] power: supply: bd71828-power: Support ROHM BD72720
From: Matti Vaittinen @ 2025-11-05 7:39 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Matti Vaittinen, Linus Walleij,
Bartosz Golaszewski, Alexandre Belloni, linux-leds, devicetree,
linux-kernel, linux-pm, linux-clk, linux-gpio, linux-rtc,
Andreas Kemnade
In-Reply-To: <cover.1762327887.git.mazziesaccount@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11744 bytes --]
From: Matti Vaittinen <mazziesaccount@gmail.com>
The ROHM BD72720 is a power management IC with a charger and coulomb
counter block which is closely related to the charger / coulomb counter
found from the BD71815, BD71828, BD71879 which are all supported by the
bd71828-power driver. Due to the similarities it makes sense to support
also the BD72720 with the same driver.
Add basic support for the charger logic on ROHM BD72720.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
v2 => :
- No changes
RFCv1 => v2:
- Support using 9-bit register addresses (offset of 0x100) with the
BD72720
- Simplify probe and IC data as we don't need two regmaps
- Drop two BD72720 specific functions as we no longer need different
regmap for it.
Note: This patch depends on the series: "power: supply: add charger for
BD71828" by Andreas:
https://lore.kernel.org/all/20250918-bd71828-charger-v5-0-851164839c28@kemnade.info/
NOTE: Fuel-gauging is not supported. You can find an unmaintained
downstream reference-driver with a fuel-gauge example from:
https://github.com/RohmSemiconductor/Linux-Kernel-PMIC-Drivers/releases/tag/bd72720-reference-driver-v1
---
drivers/power/supply/bd71828-power.c | 134 +++++++++++++++++++++++----
1 file changed, 116 insertions(+), 18 deletions(-)
diff --git a/drivers/power/supply/bd71828-power.c b/drivers/power/supply/bd71828-power.c
index ce73c0f48397..438e220a9cb7 100644
--- a/drivers/power/supply/bd71828-power.c
+++ b/drivers/power/supply/bd71828-power.c
@@ -5,6 +5,7 @@
#include <linux/kernel.h>
#include <linux/mfd/rohm-bd71815.h>
#include <linux/mfd/rohm-bd71828.h>
+#include <linux/mfd/rohm-bd72720.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
#include <linux/platform_device.h>
@@ -51,12 +52,14 @@ struct pwr_regs {
unsigned int chg_state;
unsigned int bat_temp;
unsigned int dcin_stat;
+ unsigned int dcin_online_mask;
unsigned int dcin_collapse_limit;
unsigned int chg_set1;
unsigned int chg_en;
unsigned int vbat_alm_limit_u;
unsigned int conf;
unsigned int vdcin;
+ unsigned int vdcin_himask;
};
static const struct pwr_regs pwr_regs_bd71828 = {
@@ -67,12 +70,14 @@ static const struct pwr_regs pwr_regs_bd71828 = {
.chg_state = BD71828_REG_CHG_STATE,
.bat_temp = BD71828_REG_BAT_TEMP,
.dcin_stat = BD71828_REG_DCIN_STAT,
+ .dcin_online_mask = BD7182x_MASK_DCIN_DET,
.dcin_collapse_limit = BD71828_REG_DCIN_CLPS,
.chg_set1 = BD71828_REG_CHG_SET1,
.chg_en = BD71828_REG_CHG_EN,
.vbat_alm_limit_u = BD71828_REG_ALM_VBAT_LIMIT_U,
.conf = BD71828_REG_CONF,
.vdcin = BD71828_REG_VDCIN_U,
+ .vdcin_himask = BD7182x_MASK_VDCIN_U,
};
static const struct pwr_regs pwr_regs_bd71815 = {
@@ -85,6 +90,7 @@ static const struct pwr_regs pwr_regs_bd71815 = {
.chg_state = BD71815_REG_CHG_STATE,
.bat_temp = BD71815_REG_BAT_TEMP,
.dcin_stat = BD71815_REG_DCIN_STAT,
+ .dcin_online_mask = BD7182x_MASK_DCIN_DET,
.dcin_collapse_limit = BD71815_REG_DCIN_CLPS,
.chg_set1 = BD71815_REG_CHG_SET1,
.chg_en = BD71815_REG_CHG_SET1,
@@ -92,6 +98,31 @@ static const struct pwr_regs pwr_regs_bd71815 = {
.conf = BD71815_REG_CONF,
.vdcin = BD71815_REG_VM_DCIN_U,
+ .vdcin_himask = BD7182x_MASK_VDCIN_U,
+};
+
+static struct pwr_regs pwr_regs_bd72720 = {
+ .vbat_avg = BD72720_REG_VM_SA_VBAT_U,
+ .ibat = BD72720_REG_CC_CURCD_U,
+ .ibat_avg = BD72720_REG_CC_SA_CURCD_U,
+ .btemp_vth = BD72720_REG_VM_BTMP_U,
+ /*
+ * Note, state 0x40 IMP_CHK. not documented
+ * on other variants but was still handled in
+ * existing code. No memory traces as to why.
+ */
+ .chg_state = BD72720_REG_CHG_STATE,
+ .bat_temp = BD72720_REG_CHG_BAT_TEMP_STAT,
+ .dcin_stat = BD72720_REG_INT_VBUS_SRC,
+ .dcin_online_mask = BD72720_MASK_DCIN_DET,
+ .dcin_collapse_limit = -1, /* Automatic. Setting not supported */
+ .chg_set1 = BD72720_REG_CHG_SET_1,
+ .chg_en = BD72720_REG_CHG_EN,
+ /* 15mV note in data-sheet */
+ .vbat_alm_limit_u = BD72720_REG_ALM_VBAT_TH_U,
+ .conf = BD72720_REG_CONF, /* o XSTB, only PON. Seprate slave addr */
+ .vdcin = BD72720_REG_VM_VBUS_U, /* 10 bits not 11 as with other ICs */
+ .vdcin_himask = BD72720_MASK_VDCIN_U,
};
struct bd71828_power {
@@ -298,7 +329,7 @@ static int get_chg_online(struct bd71828_power *pwr, int *chg_online)
dev_err(pwr->dev, "Failed to read DCIN status\n");
return ret;
}
- *chg_online = ((r & BD7182x_MASK_DCIN_DET) != 0);
+ *chg_online = ((r & pwr->regs->dcin_online_mask) != 0);
return 0;
}
@@ -329,8 +360,8 @@ static int bd71828_bat_inserted(struct bd71828_power *pwr)
ret = val & BD7182x_MASK_CONF_PON;
if (ret)
- regmap_update_bits(pwr->regmap, pwr->regs->conf,
- BD7182x_MASK_CONF_PON, 0);
+ if (regmap_update_bits(pwr->regmap, pwr->regs->conf, BD7182x_MASK_CONF_PON, 0))
+ dev_err(pwr->dev, "Failed to write CONF register\n");
return ret;
}
@@ -358,11 +389,13 @@ static int bd71828_init_hardware(struct bd71828_power *pwr)
int ret;
/* TODO: Collapse limit should come from device-tree ? */
- ret = regmap_write(pwr->regmap, pwr->regs->dcin_collapse_limit,
- BD7182x_DCIN_COLLAPSE_DEFAULT);
- if (ret) {
- dev_err(pwr->dev, "Failed to write DCIN collapse limit\n");
- return ret;
+ if (pwr->regs->dcin_collapse_limit != (unsigned int)-1) {
+ ret = regmap_write(pwr->regmap, pwr->regs->dcin_collapse_limit,
+ BD7182x_DCIN_COLLAPSE_DEFAULT);
+ if (ret) {
+ dev_err(pwr->dev, "Failed to write DCIN collapse limit\n");
+ return ret;
+ }
}
ret = pwr->bat_inserted(pwr);
@@ -419,7 +452,7 @@ static int bd71828_charger_get_property(struct power_supply *psy,
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
ret = bd7182x_read16_himask(pwr, pwr->regs->vdcin,
- BD7182x_MASK_VDCIN_U, &tmp);
+ pwr->regs->vdcin_himask, &tmp);
if (ret)
return ret;
@@ -630,6 +663,9 @@ BD_ISR_AC(dcin_ovp_det, "DCIN OVER VOLTAGE", true)
BD_ISR_DUMMY(dcin_mon_det, "DCIN voltage below threshold")
BD_ISR_DUMMY(dcin_mon_res, "DCIN voltage above threshold")
+BD_ISR_DUMMY(vbus_curr_limit, "VBUS current limited")
+BD_ISR_DUMMY(vsys_ov_res, "VSYS over-voltage cleared")
+BD_ISR_DUMMY(vsys_ov_det, "VSYS over-voltage")
BD_ISR_DUMMY(vsys_uv_res, "VSYS under-voltage cleared")
BD_ISR_DUMMY(vsys_uv_det, "VSYS under-voltage")
BD_ISR_DUMMY(vsys_low_res, "'VSYS low' cleared")
@@ -878,6 +914,51 @@ static int bd7182x_get_irqs(struct platform_device *pdev,
BDIRQ("bd71828-temp-125-over", bd71828_temp_vf125_det),
BDIRQ("bd71828-temp-125-under", bd71828_temp_vf125_res),
};
+ static const struct bd7182x_irq_res bd72720_irqs[] = {
+ BDIRQ("bd72720_int_vbus_rmv", BD_ISR_NAME(dcin_removed)),
+ BDIRQ("bd72720_int_vbus_det", bd7182x_dcin_detected),
+ BDIRQ("bd72720_int_vbus_mon_res", BD_ISR_NAME(dcin_mon_res)),
+ BDIRQ("bd72720_int_vbus_mon_det", BD_ISR_NAME(dcin_mon_det)),
+ BDIRQ("bd72720_int_vsys_mon_res", BD_ISR_NAME(vsys_mon_res)),
+ BDIRQ("bd72720_int_vsys_mon_det", BD_ISR_NAME(vsys_mon_det)),
+ BDIRQ("bd72720_int_vsys_uv_res", BD_ISR_NAME(vsys_uv_res)),
+ BDIRQ("bd72720_int_vsys_uv_det", BD_ISR_NAME(vsys_uv_det)),
+ BDIRQ("bd72720_int_vsys_lo_res", BD_ISR_NAME(vsys_low_res)),
+ BDIRQ("bd72720_int_vsys_lo_det", BD_ISR_NAME(vsys_low_det)),
+ BDIRQ("bd72720_int_vsys_ov_res", BD_ISR_NAME(vsys_ov_res)),
+ BDIRQ("bd72720_int_vsys_ov_det", BD_ISR_NAME(vsys_ov_det)),
+ BDIRQ("bd72720_int_bat_ilim", BD_ISR_NAME(vbus_curr_limit)),
+ BDIRQ("bd72720_int_chg_done", bd718x7_chg_done),
+ BDIRQ("bd72720_int_extemp_tout", BD_ISR_NAME(chg_wdg_temp)),
+ BDIRQ("bd72720_int_chg_wdt_exp", BD_ISR_NAME(chg_wdg)),
+ BDIRQ("bd72720_int_bat_mnt_out", BD_ISR_NAME(rechg_res)),
+ BDIRQ("bd72720_int_bat_mnt_in", BD_ISR_NAME(rechg_det)),
+ BDIRQ("bd72720_int_chg_trns", BD_ISR_NAME(chg_state_changed)),
+
+ BDIRQ("bd72720_int_vbat_mon_res", BD_ISR_NAME(bat_mon_res)),
+ BDIRQ("bd72720_int_vbat_mon_det", BD_ISR_NAME(bat_mon)),
+ BDIRQ("bd72720_int_vbat_sht_res", BD_ISR_NAME(bat_short_res)),
+ BDIRQ("bd72720_int_vbat_sht_det", BD_ISR_NAME(bat_short)),
+ BDIRQ("bd72720_int_vbat_lo_res", BD_ISR_NAME(bat_low_res)),
+ BDIRQ("bd72720_int_vbat_lo_det", BD_ISR_NAME(bat_low)),
+ BDIRQ("bd72720_int_vbat_ov_res", BD_ISR_NAME(bat_ov_res)),
+ BDIRQ("bd72720_int_vbat_ov_det", BD_ISR_NAME(bat_ov)),
+ BDIRQ("bd72720_int_bat_rmv", BD_ISR_NAME(bat_removed)),
+ BDIRQ("bd72720_int_bat_det", BD_ISR_NAME(bat_det)),
+ BDIRQ("bd72720_int_dbat_det", BD_ISR_NAME(bat_dead)),
+ BDIRQ("bd72720_int_bat_temp_trns", BD_ISR_NAME(temp_transit)),
+ BDIRQ("bd72720_int_lobtmp_res", BD_ISR_NAME(temp_bat_low_res)),
+ BDIRQ("bd72720_int_lobtmp_det", BD_ISR_NAME(temp_bat_low)),
+ BDIRQ("bd72720_int_ovbtmp_res", BD_ISR_NAME(temp_bat_hi_res)),
+ BDIRQ("bd72720_int_ovbtmp_det", BD_ISR_NAME(temp_bat_hi)),
+ BDIRQ("bd72720_int_ocur1_res", BD_ISR_NAME(bat_oc1_res)),
+ BDIRQ("bd72720_int_ocur1_det", BD_ISR_NAME(bat_oc1)),
+ BDIRQ("bd72720_int_ocur2_res", BD_ISR_NAME(bat_oc2_res)),
+ BDIRQ("bd72720_int_ocur2_det", BD_ISR_NAME(bat_oc2)),
+ BDIRQ("bd72720_int_ocur3_res", BD_ISR_NAME(bat_oc3_res)),
+ BDIRQ("bd72720_int_ocur3_det", BD_ISR_NAME(bat_oc3)),
+ BDIRQ("bd72720_int_cc_mon2_det", BD_ISR_NAME(bat_cc_mon)),
+ };
int num_irqs;
const struct bd7182x_irq_res *irqs;
@@ -890,6 +971,10 @@ static int bd7182x_get_irqs(struct platform_device *pdev,
irqs = &bd71815_irqs[0];
num_irqs = ARRAY_SIZE(bd71815_irqs);
break;
+ case ROHM_CHIP_TYPE_BD72720:
+ irqs = &bd72720_irqs[0];
+ num_irqs = ARRAY_SIZE(bd72720_irqs);
+ break;
default:
return -EINVAL;
}
@@ -958,21 +1043,27 @@ static int bd71828_power_probe(struct platform_device *pdev)
struct power_supply_config ac_cfg = {};
struct power_supply_config bat_cfg = {};
int ret;
- struct regmap *regmap;
-
- regmap = dev_get_regmap(pdev->dev.parent, NULL);
- if (!regmap) {
- dev_err(&pdev->dev, "No parent regmap\n");
- return -EINVAL;
- }
pwr = devm_kzalloc(&pdev->dev, sizeof(*pwr), GFP_KERNEL);
if (!pwr)
return -ENOMEM;
- pwr->regmap = regmap;
- pwr->dev = &pdev->dev;
+ /*
+ * The BD72720 MFD device registers two regmaps. Power-supply driver
+ * uses the "wrap-map", which provides access to both of the I2C slave
+ * addresses used by the BD72720
+ */
pwr->chip_type = platform_get_device_id(pdev)->driver_data;
+ if (pwr->chip_type != ROHM_CHIP_TYPE_BD72720)
+ pwr->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ else
+ pwr->regmap = dev_get_regmap(pdev->dev.parent, "wrap-map");
+ if (!pwr->regmap) {
+ dev_err(&pdev->dev, "No parent regmap\n");
+ return -EINVAL;
+ }
+
+ pwr->dev = &pdev->dev;
switch (pwr->chip_type) {
case ROHM_CHIP_TYPE_BD71828:
@@ -985,6 +1076,12 @@ static int bd71828_power_probe(struct platform_device *pdev)
pwr->get_temp = bd71815_get_temp;
pwr->regs = &pwr_regs_bd71815;
break;
+ case ROHM_CHIP_TYPE_BD72720:
+ pwr->bat_inserted = bd71828_bat_inserted;
+ pwr->regs = &pwr_regs_bd72720;
+ pwr->get_temp = bd71828_get_temp;
+ dev_dbg(pwr->dev, "Found ROHM BD72720\n");
+ break;
default:
dev_err(pwr->dev, "Unknown PMIC\n");
return -EINVAL;
@@ -1030,6 +1127,7 @@ static int bd71828_power_probe(struct platform_device *pdev)
static const struct platform_device_id bd71828_charger_id[] = {
{ "bd71815-power", ROHM_CHIP_TYPE_BD71815 },
{ "bd71828-power", ROHM_CHIP_TYPE_BD71828 },
+ { "bd72720-power", ROHM_CHIP_TYPE_BD72720 },
{ },
};
MODULE_DEVICE_TABLE(platform, bd71828_charger_id);
--
2.51.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH v3 16/16] MAINTAINERS: Add ROHM BD72720 PMIC
From: Matti Vaittinen @ 2025-11-05 7:40 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Matti Vaittinen, Linus Walleij,
Bartosz Golaszewski, Alexandre Belloni, linux-leds, devicetree,
linux-kernel, linux-pm, linux-clk, linux-gpio, linux-rtc,
Andreas Kemnade
In-Reply-To: <cover.1762327887.git.mazziesaccount@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
From: Matti Vaittinen <mazziesaccount@gmail.com>
Add the ROHM BD72720 PMIC driver files to be maintained by undersigned.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
Revision history:
RFCv1 =>:
- No changes
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index fe01aa31c58b..7e3c1eac7cda 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22353,6 +22353,7 @@ S: Supported
F: drivers/clk/clk-bd718x7.c
F: drivers/gpio/gpio-bd71815.c
F: drivers/gpio/gpio-bd71828.c
+F: drivers/gpio/gpio-bd72720.c
F: drivers/mfd/rohm-bd71828.c
F: drivers/mfd/rohm-bd718x7.c
F: drivers/mfd/rohm-bd9576.c
@@ -22369,6 +22370,7 @@ F: drivers/watchdog/bd96801_wdt.c
F: include/linux/mfd/rohm-bd71815.h
F: include/linux/mfd/rohm-bd71828.h
F: include/linux/mfd/rohm-bd718x7.h
+F: include/linux/mfd/rohm-bd72720.h
F: include/linux/mfd/rohm-bd957x.h
F: include/linux/mfd/rohm-bd96801.h
F: include/linux/mfd/rohm-bd96802.h
--
2.51.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH v3 01/16] dt-bindings: regulator: ROHM BD72720
From: Rob Herring (Arm) @ 2025-11-05 9:00 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Conor Dooley, linux-kernel, Lee Jones, devicetree, Linus Walleij,
Sebastian Reichel, Andreas Kemnade, Bartosz Golaszewski,
Alexandre Belloni, Matti Vaittinen, Stephen Boyd, Pavel Machek,
Krzysztof Kozlowski, linux-gpio, linux-clk, linux-pm, linux-leds,
Matti Vaittinen, Michael Turquette, linux-rtc, Liam Girdwood,
Mark Brown
In-Reply-To: <48fe6e2642db4484640b173cd71be1b245929122.1762327887.git.mazziesaccount@gmail.com>
On Wed, 05 Nov 2025 09:35:59 +0200, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> The ROHM BD72720 is a new PMIC with 10 BUCk and 11 LDO regulators.
>
> The BD72720 is designed to support using the BUCK10 as a supply for
> the LDOs 1 to 4. When the BUCK10 is used for this, it can be set to a
> LDON_HEAD mode. In this mode, the BUCK10 voltage can't be controlled by
> software, but the voltage is adjusted by PMIC to match the LDO1 .. LDO4
> voltages with a given offset. Offset can be 50mV .. 300mV and is
> changeable at 50mV steps.
>
> Add 'ldon-head-microvolt' property to denote a board which is designed
> to utilize the LDON_HEAD mode.
>
> All other properties are already existing.
>
> Add dt-binding doc for ROHM BD72720 regulators to make it usable.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>
> ---
> Revision history:
> v2 => v3:
> - drop unnecessary descriptions
> - use microvolts for the 'ldon-head' dt-property
>
> RFCv1 => v2:
> - No changes
> ---
> .../regulator/rohm,bd72720-regulator.yaml | 149 ++++++++++++++++++
> 1 file changed, 149 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml: patternProperties:^buck[1-10]$:properties:rohm,ldon-head-microvolt: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref
from schema $id: http://devicetree.org/meta-schemas/core.yaml
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml: Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/48fe6e2642db4484640b173cd71be1b245929122.1762327887.git.mazziesaccount@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 04/16] dt-bindings: power: supply: BD72720 managed battery
From: Rob Herring (Arm) @ 2025-11-05 9:00 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Linus Walleij, Alexandre Belloni, linux-rtc, Stephen Boyd,
Matti Vaittinen, Liam Girdwood, linux-pm, linux-kernel,
Bartosz Golaszewski, Pavel Machek, linux-leds, Sebastian Reichel,
Conor Dooley, Michael Turquette, devicetree, linux-gpio,
Matti Vaittinen, Mark Brown, Andreas Kemnade, Lee Jones,
linux-clk, Krzysztof Kozlowski
In-Reply-To: <a45e7230ecd08eed2081cbe7e7b4719d1fc8a581.1762327887.git.mazziesaccount@gmail.com>
On Wed, 05 Nov 2025 09:36:49 +0200, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> The BD72720 PMIC has a battery charger + coulomb counter block. These
> can be used to manage charging of a lithium-ion battery and to do fuel
> gauging.
>
> ROHM has developed a so called "zero-correction" -algorithm to improve
> the fuel-gauging accuracy close to the point where battery is depleted.
> This relies on battery specific "VDR" tables, which are measured from
> the battery, and which describe the voltage drop rate. More thorough
> explanation about the "zero correction" and "VDR" parameters is here:
> https://lore.kernel.org/all/676253b9-ff69-7891-1f26-a8b5bb5a421b@fi.rohmeurope.com/
>
> Document the VDR zero-correction specific battery properties used by the
> BD72720 and some other ROHM chargers.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> ---
> NOTE:
> Linus' rb-tag holds only if there's no further comments from Rob.
>
> Revision history:
> v2 => v3:
> - Constrain VDR threshold voltage to 48V
> - Use standard '-bp' -suffix for the rohm,volt-drop-soc
>
> RFCv1 => v2:
> - Add units to rohm,volt-drop-soc (tenths of %)
> - Give real temperatures matching the VDR tables, instead of vague
> 'high', 'normal', 'low', 'very low'. (Add table of temperatures and
> use number matching the right temperature index in the VDR table name).
> - Fix typoed 'algorithm' in commit message.
>
> The parameters are describing the battery voltage drop rates - so they
> are properties of the battery, not the charger. Thus they do not belong
> in the charger node.
>
> The right place for them is the battery node, which is described by the
> generic "battery.yaml". I was not comfortable with adding these
> properties to the generic battery.yaml because they are:
> - Meaningful only for those charger drivers which have the VDR
> algorithm implemented. (And even though the algorithm is not charger
> specific, AFAICS, it is currently only used by some ROHM PMIC
> drivers).
> - Technique of measuring the VDR tables for a battery is not widely
> known. AFAICS, only folks at ROHM are measuring those for some
> customer products. We do have those tables available for some of the
> products though (Kobo?).
> ---
> .../power/supply/rohm,vdr-battery.yaml | 80 +++++++++++++++++++
> 1 file changed, 80 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.example.dtb: battery (simple-battery): 'degrade-cycle-microamp-hours', 'rohm,volt-drop-0-microvolt', 'rohm,volt-drop-1-microvolt', 'rohm,volt-drop-2-microvolt', 'rohm,volt-drop-3-temp-microvolt', 'rohm,volt-drop-soc-bp', 'rohm,volt-drop-temperatures-millicelsius', 'rohm,voltage-vdr-thresh-microvolt' do not match any of the regexes: '^ocv-capacity-table-[0-9]+$', '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/power/supply/battery.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/a45e7230ecd08eed2081cbe7e7b4719d1fc8a581.1762327887.git.mazziesaccount@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 05/16] dt-bindings: mfd: ROHM BD72720
From: Rob Herring (Arm) @ 2025-11-05 9:00 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Stephen Boyd, linux-pm, Alexandre Belloni, linux-clk,
Matti Vaittinen, Conor Dooley, Sebastian Reichel, Lee Jones,
Linus Walleij, linux-rtc, linux-gpio, Michael Turquette,
devicetree, Matti Vaittinen, Liam Girdwood, Pavel Machek,
Bartosz Golaszewski, Mark Brown, Andreas Kemnade, linux-kernel,
linux-leds, Krzysztof Kozlowski
In-Reply-To: <4c7ea0c83f4bb4af65439a9b8951d50ee705d22c.1762327887.git.mazziesaccount@gmail.com>
On Wed, 05 Nov 2025 09:37:05 +0200, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> The ROHM BD72720 is a power management IC integrating regulators, GPIOs,
> charger, LEDs, RTC and a clock gate.
>
> Add dt-binding doc for ROHM BD72720.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>
> ---
> Revision history:
> v2 => v3:
> - Styling
> - Document all pin functions
> - use pattern-properties
> - re-use existing Rsense binding
> - correct the example
>
> RFCv1 => v2:
> - Typofixes
> ---
> .../bindings/mfd/rohm,bd72720-pmic.yaml | 273 ++++++++++++++++++
> 1 file changed, 273 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml: Unresolvable reference: /schemas/regulator/rohm,bd77270-regulator.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.example.dtb: pmic@4b (rohm,bd71828): 'rohm,pin-dvs0', 'rohm,pin-dvs1', 'rohm,pin-exten0', 'rohm,pin-exten1', 'rohm,pin-fault_b' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/mfd/rohm,bd71828-pmic.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/4c7ea0c83f4bb4af65439a9b8951d50ee705d22c.1762327887.git.mazziesaccount@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 01/16] dt-bindings: regulator: ROHM BD72720
From: Matti Vaittinen @ 2025-11-05 11:22 UTC (permalink / raw)
To: Rob Herring (Arm), Matti Vaittinen
Cc: Conor Dooley, linux-kernel, Lee Jones, devicetree, Linus Walleij,
Sebastian Reichel, Andreas Kemnade, Bartosz Golaszewski,
Alexandre Belloni, Stephen Boyd, Pavel Machek,
Krzysztof Kozlowski, linux-gpio, linux-clk, linux-pm, linux-leds,
Matti Vaittinen, Michael Turquette, linux-rtc, Liam Girdwood,
Mark Brown
In-Reply-To: <176233320981.143013.4115240062372455834.robh@kernel.org>
On 05/11/2025 11:00, Rob Herring (Arm) wrote:
>
> On Wed, 05 Nov 2025 09:35:59 +0200, Matti Vaittinen wrote:
>> From: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> The ROHM BD72720 is a new PMIC with 10 BUCk and 11 LDO regulators.
>>
>> The BD72720 is designed to support using the BUCK10 as a supply for
>> the LDOs 1 to 4. When the BUCK10 is used for this, it can be set to a
>> LDON_HEAD mode. In this mode, the BUCK10 voltage can't be controlled by
>> software, but the voltage is adjusted by PMIC to match the LDO1 .. LDO4
>> voltages with a given offset. Offset can be 50mV .. 300mV and is
>> changeable at 50mV steps.
>>
>> Add 'ldon-head-microvolt' property to denote a board which is designed
>> to utilize the LDON_HEAD mode.
>>
>> All other properties are already existing.
>>
>> Add dt-binding doc for ROHM BD72720 regulators to make it usable.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---
>> Revision history:
>> v2 => v3:
>> - drop unnecessary descriptions
>> - use microvolts for the 'ldon-head' dt-property
>>
>> RFCv1 => v2:
>> - No changes
>> ---
>> .../regulator/rohm,bd72720-regulator.yaml | 149 ++++++++++++++++++
>> 1 file changed, 149 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml: patternProperties:^buck[1-10]$:properties:rohm,ldon-head-microvolt: '$ref' should not be valid under {'const': '$ref'}
> hint: Standard unit suffix properties don't need a type $ref
> from schema $id: http://devicetree.org/meta-schemas/core.yaml
Nice! I'm not sure if anyone has said it but these bots are helpful :) I
forgot the type to ldon-head when switching from -millivolt to
-microvolt. I'll address this for the next version.
> doc reference errors (make refcheckdocs):
Thanks for including the make -command to the mail! I didn't even know
about 'refcheckdocs' target.
> Warning: Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
> Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml: Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
Hmm. I suppose this is because the MFD binding is added only later in
the series(?) I suppose we can't help it because the MFD binding
references the regulator binding as well. So, this is kind of a chicken
and egg problem?
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v3 05/16] dt-bindings: mfd: ROHM BD72720
From: Matti Vaittinen @ 2025-11-05 11:39 UTC (permalink / raw)
To: Rob Herring (Arm), Matti Vaittinen
Cc: Stephen Boyd, linux-pm, Alexandre Belloni, linux-clk,
Conor Dooley, Sebastian Reichel, Lee Jones, Linus Walleij,
linux-rtc, linux-gpio, Michael Turquette, devicetree,
Matti Vaittinen, Liam Girdwood, Pavel Machek, Bartosz Golaszewski,
Mark Brown, Andreas Kemnade, linux-kernel, linux-leds,
Krzysztof Kozlowski
In-Reply-To: <176233321210.143104.455177775703669783.robh@kernel.org>
On 05/11/2025 11:00, Rob Herring (Arm) wrote:
>
> On Wed, 05 Nov 2025 09:37:05 +0200, Matti Vaittinen wrote:
>> From: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> The ROHM BD72720 is a power management IC integrating regulators, GPIOs,
>> charger, LEDs, RTC and a clock gate.
>>
>> Add dt-binding doc for ROHM BD72720.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---
>> Revision history:
>> v2 => v3:
>> - Styling
>> - Document all pin functions
>> - use pattern-properties
>> - re-use existing Rsense binding
>> - correct the example
>>
>> RFCv1 => v2:
>> - Typofixes
>> ---
>> .../bindings/mfd/rohm,bd72720-pmic.yaml | 273 ++++++++++++++++++
>> 1 file changed, 273 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml: Unresolvable reference: /schemas/regulator/rohm,bd77270-regulator.yaml
Not sure how this slipped through. I'll fix this in next version. Thanks.
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
From: Conor Dooley @ 2025-11-05 18:33 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Ovidiu Panait, claudiu.beznea.uj, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, p.zabel, linux-rtc, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <2025110420204948103c2f@mail.local>
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On Tue, Nov 04, 2025 at 09:20:49PM +0100, Alexandre Belloni wrote:
> On 04/11/2025 17:28:27+0000, Conor Dooley wrote:
> > On Mon, Nov 03, 2025 at 12:18:45PM +0000, Ovidiu Panait wrote:
> > > The Renesas RZ/V2H RTC IP is based on the same RTCA3 IP as RZ/G3S
> > > (r9a08g045), with the following differences:
> > > - It lacks the time capture functionality
> > > - The maximum supported periodic interrupt frequency is 128Hz instead
> > > of 256Hz
> > > - It requires two reset lines instead of one
> > >
> > > Add new compatible string "renesas,r9a09g057-rtca3" for RZ/V2H and update
> > > the binding accordingly:
> > > - Allow "resets" to contain one or two entries depending on the SoC.
> > > - Add "reset-names" property, but make it required only for RZ/V2H.
> > >
> > > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > + reset-names:
> > > + items:
> > > + - const: rtc
> > > + - const: rtc_rtest
> >
> > If you respin, just make this second one rtest.
>
> I already applied it as it had your ack but I can still change it
It's fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 02/16] dt-bindings: battery: Clarify trickle-charge
From: Krzysztof Kozlowski @ 2025-11-06 8:00 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Linus Walleij, Bartosz Golaszewski, Alexandre Belloni, linux-leds,
devicetree, linux-kernel, linux-pm, linux-clk, linux-gpio,
linux-rtc, Andreas Kemnade
In-Reply-To: <742fcdcc8b6dcb5989418e8c1cf5a7d7ba5434a5.1762327887.git.mazziesaccount@gmail.com>
On Wed, Nov 05, 2025 at 09:36:16AM +0200, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> The term 'trickle-charging' is used to describe a very slow charging
> phase, where electrons "trickle-in" the battery.
>
> There are two different use-cases for this type of charging. At least
> some Li-Ion batteries can benefit from very slow, constant current,
> pre-pre phase 'trickle-charging', if a battery is very empty.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 03/16] dt-bindings: battery: Add trickle-charge upper limit
From: Krzysztof Kozlowski @ 2025-11-06 8:01 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Linus Walleij, Bartosz Golaszewski, Alexandre Belloni, linux-leds,
devicetree, linux-kernel, linux-pm, linux-clk, linux-gpio,
linux-rtc, Andreas Kemnade
In-Reply-To: <1babb4f8e9a1d21daab737e3427005852ec304fb.1762327887.git.mazziesaccount@gmail.com>
On Wed, Nov 05, 2025 at 09:36:31AM +0200, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> Some of the chargers for lithium-ion batteries use a trickle-charging as
> a first charging phase for very empty batteries, to "wake-up" the battery.
> Trickle-charging is a low current, constant current phase. After the
> voltage of the very empty battery has reached an upper limit for
> trickle charging, the pre-charge phase is started with a higher current.
>
> Allow defining the upper limit for trickle charging voltage, after which
> the charging should be changed to the pre-charging.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/6] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
From: Geert Uytterhoeven @ 2025-11-06 8:47 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, p.zabel, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20251021080705.18116-3-ovidiu.panait.rb@renesas.com>
Hi Ovidiu,
Sorry, I still had outstanding review comments I hadn't sent yet, as
I hadn't finished my review yet.
On Tue, 21 Oct 2025 at 10:07, Ovidiu Panait
<ovidiu.panait.rb@renesas.com> wrote:
> The Renesas RZ/V2H RTC IP is based on the same RTCA3 IP as RZ/G3S
> (r9a08g045), with the following differences:
> - It lacks the time capture functionality
> - The maximum supported periodic interrupt frequency is 128Hz instead
> of 256Hz
> - It requires two reset lines instead of one
>
> Add new compatible string "renesas,r9a09g057-rtca3" for RZ/V2H and update
> the binding accordingly:
> - Allow "resets" to contain one or two entries depending on the SoC.
> - Add "reset-names" property, but make it required only for RZ/V2H.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> ---
> v2 changes:
> - Added "reset-names" property and made it required for RZ/V2H.
Thanks for the update!
> --- a/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
> +++ b/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
> @@ -61,6 +63,39 @@ required:
> - power-domains
> - resets
>
> +allOf:
> + - $ref: rtc.yaml#
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r9a08g045-rtca3
> + then:
> + properties:
> + resets:
> + items:
> + - description: VBATTB module reset
> + reset-names:
> + const: vbattb
Please add this property to the example at the bottom, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH v2 2/6] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
From: Ovidiu Panait @ 2025-11-06 9:13 UTC (permalink / raw)
To: geert, alexandre.belloni@bootlin.com
Cc: Claudiu Beznea, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, magnus.damm, mturquette@baylibre.com,
sboyd@kernel.org, p.zabel@pengutronix.de,
linux-rtc@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <CAMuHMdUR=_5Ex57gvgFXyxhSDkqdd0DjcTqV0m59tquxKzQnNg@mail.gmail.com>
Hi Geert,
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: Thursday, November 6, 2025 10:47 AM
> To: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> Cc: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>;
> alexandre.belloni@bootlin.com; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; magnus.damm <magnus.damm@gmail.com>;
> mturquette@baylibre.com; sboyd@kernel.org; p.zabel@pengutronix.de; linux-
> rtc@vger.kernel.org; linux-renesas-soc@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> clk@vger.kernel.org
> Subject: Re: [PATCH v2 2/6] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H
> support
>
> Hi Ovidiu,
>
> Sorry, I still had outstanding review comments I hadn't sent yet, as
> I hadn't finished my review yet.
>
> On Tue, 21 Oct 2025 at 10:07, Ovidiu Panait
> <ovidiu.panait.rb@renesas.com> wrote:
> > The Renesas RZ/V2H RTC IP is based on the same RTCA3 IP as RZ/G3S
> > (r9a08g045), with the following differences:
> > - It lacks the time capture functionality
> > - The maximum supported periodic interrupt frequency is 128Hz instead
> > of 256Hz
> > - It requires two reset lines instead of one
> >
> > Add new compatible string "renesas,r9a09g057-rtca3" for RZ/V2H and
> update
> > the binding accordingly:
> > - Allow "resets" to contain one or two entries depending on the SoC.
> > - Add "reset-names" property, but make it required only for RZ/V2H.
> >
> > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > ---
> > v2 changes:
> > - Added "reset-names" property and made it required for RZ/V2H.
>
> Thanks for the update!
>
> > --- a/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
>
> > @@ -61,6 +63,39 @@ required:
> > - power-domains
> > - resets
> >
> > +allOf:
> > + - $ref: rtc.yaml#
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: renesas,r9a08g045-rtca3
> > + then:
> > + properties:
> > + resets:
> > + items:
> > + - description: VBATTB module reset
> > + reset-names:
> > + const: vbattb
>
> Please add this property to the example at the bottom, too.
>
Thanks for your review!
Please see the latest v3 series:
https://lore.kernel.org/all/20251103121848.6539-1-ovidiu.panait.rb@renesas.com/
The first two patches were applied by Alexandre in the meantime.
Alexandre, would it be possible to drop the patches from your queue and I
will send v4 to address the latest feedback from Geert and Conor?
Thanks!
Ovidiu
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v7 0/4] Add NVIDIA VRS RTC support
From: Jon Hunter @ 2025-11-06 10:04 UTC (permalink / raw)
To: Shubhi Garg, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Catalin Marinas, Will Deacon, Alexandre Belloni
Cc: devicetree, linux-arm-kernel, linux-rtc, linux-tegra
In-Reply-To: <bd7d8771-e063-4f03-9b0f-bc6ad95adb3d@nvidia.com>
Hi Alexandre,
On 29/10/2025 12:49, Jon Hunter wrote:
>
> On 07/10/2025 14:57, Shubhi Garg wrote:
>> This patch series adds support for NVIDIA's Voltage Regulator
>> Specification
>> (VRS) RTC device. It provides following features:
>> - read/set system time
>> - 32kHz clock support with backup battery input to retain system time
>> across boot
>> - alarm functionality to wake system from suspend and shutdown state
>>
>> The series includes:
>> - Device tree bindings for the VRS RTC
>> - VRS device tree nodes for NVIDIA platforms
>> - VRS RTC device driver
>> - Configuration updates to enable the driver
>
>
> For the series ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
Are you OK to pick up the driver changes? We would like to get this into
-next unless you have any objections.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: PROBLEM: hwclock busted w/ M48T59 RTC (regression)
From: Thorsten Leemhuis @ 2025-11-06 10:25 UTC (permalink / raw)
To: Nick Bowler, Esben Haabendal
Cc: linux-kernel, regressions, linux-rtc, stable, sparclinux
In-Reply-To: <ni6gdeax2itvzagwbqkw6oj5xsbx6vqsidop6cbj2oqneovjib@mrwzqakbla35>
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Just wondering: was this fixed in between? Just asking, as I noticed the
culprit was backported to various stable/longterm series recently
Ciao, Thorsten
On 10/23/25 15:39, Nick Bowler wrote:
> On Thu, Oct 23, 2025 at 07:21:21AM +0000, Esben Haabendal wrote:
>> On Thursday, 23 October 2025 at 06:45, Nick Bowler <nbowler@draconx.ca> wrote:
>>
>>> After a stable kernel update, the hwclock command seems no longer
>>> functional on my SPARC system with an ST M48T59Y-70PC1 RTC:
>>>
>>> # hwclock
>>> [...long delay...]
>>
>> I assume this is 10 seconds long.
>
> Yeah, about that.
>
>>> hwclock: select() to /dev/rtc0 to wait for clock tick timed out
>>
>> And this is 100% reproducible, or does it sometimes work and sometimes fail?
>
> It fails every time.
>
>> Are you using the util-linux hwclock command? Which version?
>
> hwclock from util-linux 2.40.2
>
>> Do you have CONFIG_RTC_INTF_DEV_UIE_EMUL enabled?
>
> No, this option is not enabled.
>
>> Can you run `hwclock --verbose`, both with and without the reverted commit,
>> and send the output from that?
>
> 6.18-rc2 (broken):
>
> # hwclock --verbose
> hwclock from util-linux 2.40.2
> System Time: 1761226454.799573
> Trying to open: /dev/rtc0
> Using the rtc interface to the clock.
> Last drift adjustment done at 1657523820 seconds after 1969
> Last calibration done at 1657523820 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> hwclock: select() to /dev/rtc0 to wait for clock tick timed out
> ...synchronization failed
>
> 6.18-rc2 w/ revert (working):
>
> # hwclock --verbose
> hwclock from util-linux 2.40.2
> System Time: 1761226685.238753
> Trying to open: /dev/rtc0
> Using the rtc interface to the clock.
> Last drift adjustment done at 1657523820 seconds after 1969
> Last calibration done at 1657523820 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> ioctl(3, RTC_UIE_ON, 0): Input/output error
> Waiting in loop for time from /dev/rtc0 to change
> ...got clock tick
> Time read from Hardware Clock: 2025/10/23 13:38:06
> Hw clock time : 2025/10/23 13:38:06 = 1761226686 seconds since 1969
> Time since last adjustment is 103702866 seconds
> Calculated Hardware Clock drift is 0.000000 seconds
> 2025-10-23 09:38:05.239100-04:00
>
> Thanks,
> Nick
>
#regzbot poke
^ permalink raw reply
* Re: [PATCH v2 2/6] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
From: Alexandre Belloni @ 2025-11-06 10:41 UTC (permalink / raw)
To: Ovidiu Panait
Cc: geert, Claudiu Beznea, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, magnus.damm, mturquette@baylibre.com,
sboyd@kernel.org, p.zabel@pengutronix.de,
linux-rtc@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <TY7PR01MB14910AA199960CAB587D3E9F1D3C2A@TY7PR01MB14910.jpnprd01.prod.outlook.com>
On 06/11/2025 09:13:53+0000, Ovidiu Panait wrote:
> Hi Geert,
>
> > -----Original Message-----
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > Sent: Thursday, November 6, 2025 10:47 AM
> > To: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > Cc: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>;
> > alexandre.belloni@bootlin.com; robh@kernel.org; krzk+dt@kernel.org;
> > conor+dt@kernel.org; magnus.damm <magnus.damm@gmail.com>;
> > mturquette@baylibre.com; sboyd@kernel.org; p.zabel@pengutronix.de; linux-
> > rtc@vger.kernel.org; linux-renesas-soc@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> > clk@vger.kernel.org
> > Subject: Re: [PATCH v2 2/6] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H
> > support
> >
> > Hi Ovidiu,
> >
> > Sorry, I still had outstanding review comments I hadn't sent yet, as
> > I hadn't finished my review yet.
> >
> > On Tue, 21 Oct 2025 at 10:07, Ovidiu Panait
> > <ovidiu.panait.rb@renesas.com> wrote:
> > > The Renesas RZ/V2H RTC IP is based on the same RTCA3 IP as RZ/G3S
> > > (r9a08g045), with the following differences:
> > > - It lacks the time capture functionality
> > > - The maximum supported periodic interrupt frequency is 128Hz instead
> > > of 256Hz
> > > - It requires two reset lines instead of one
> > >
> > > Add new compatible string "renesas,r9a09g057-rtca3" for RZ/V2H and
> > update
> > > the binding accordingly:
> > > - Allow "resets" to contain one or two entries depending on the SoC.
> > > - Add "reset-names" property, but make it required only for RZ/V2H.
> > >
> > > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > ---
> > > v2 changes:
> > > - Added "reset-names" property and made it required for RZ/V2H.
> >
> > Thanks for the update!
> >
> > > --- a/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
> > > +++ b/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
> >
> > > @@ -61,6 +63,39 @@ required:
> > > - power-domains
> > > - resets
> > >
> > > +allOf:
> > > + - $ref: rtc.yaml#
> > > +
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: renesas,r9a08g045-rtca3
> > > + then:
> > > + properties:
> > > + resets:
> > > + items:
> > > + - description: VBATTB module reset
> > > + reset-names:
> > > + const: vbattb
> >
> > Please add this property to the example at the bottom, too.
> >
>
> Thanks for your review!
>
> Please see the latest v3 series:
> https://lore.kernel.org/all/20251103121848.6539-1-ovidiu.panait.rb@renesas.com/
>
> The first two patches were applied by Alexandre in the meantime.
>
> Alexandre, would it be possible to drop the patches from your queue and I
> will send v4 to address the latest feedback from Geert and Conor?
>
Sure, I'll drop them later today.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 08/11] input: macsmc-input: New driver to handle the Apple Mac SMC buttons/lid
From: Lee Jones @ 2025-11-06 13:53 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Hector Martin
In-Reply-To: <20251025-macsmc-subdevs-v4-8-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025, James Calligeros wrote:
> From: Hector Martin <marcan@marcan.st>
>
> This driver implements power button and lid switch support for Apple Mac
> devices using SMC controllers driven by the macsmc driver.
>
> In addition to basic input support, this also responds to the final
> shutdown warning (when the power button is held down long enough) by
> doing an emergency kernel poweroff. This allows the NVMe controller to
> be cleanly shut down, which prevents data loss for in-cache data.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Co-developed-by: Sven Peter <sven@kernel.org>
> Signed-off-by: Sven Peter <sven@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/input/misc/Kconfig | 11 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/macsmc-input.c | 208 +++++++++++++++++++++++++
> 4 files changed, 221 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 79b9f40224a9..e8283f127f11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2451,6 +2451,7 @@ F: drivers/hwmon/macsmc-hwmon.c
> F: drivers/pmdomain/apple/
> F: drivers/i2c/busses/i2c-pasemi-core.c
> F: drivers/i2c/busses/i2c-pasemi-platform.c
> +F: drivers/input/misc/macsmc-input.c
> F: drivers/input/touchscreen/apple_z2.c
> F: drivers/iommu/apple-dart.c
> F: drivers/iommu/io-pgtable-dart.c
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 0e6b49fb54bc..109660a1a5d2 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -981,4 +981,15 @@ config INPUT_STPMIC1_ONKEY
> To compile this driver as a module, choose M here: the
> module will be called stpmic1_onkey.
>
> +config INPUT_MACSMC
> + tristate "Apple Mac SMC lid/buttons"
> + depends on MFD_MACSMC
> + help
> + Say Y here if you want to use the input events delivered via the
> + SMC controller on Apple Mac machines using the macsmc driver.
> + This includes lid open/close and the power button.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called macsmc-input.
> +
> endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index ae857c24f48e..480a0d08d4ae 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_INPUT_IQS7222) += iqs7222.o
> obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
> obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
> obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
> +obj-$(CONFIG_INPUT_MACSMC_INPUT) += macsmc-input.o
> obj-$(CONFIG_INPUT_MAX7360_ROTARY) += max7360-rotary.o
> obj-$(CONFIG_INPUT_MAX77650_ONKEY) += max77650-onkey.o
> obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
> diff --git a/drivers/input/misc/macsmc-input.c b/drivers/input/misc/macsmc-input.c
> new file mode 100644
> index 000000000000..d35322856526
> --- /dev/null
> +++ b/drivers/input/misc/macsmc-input.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC input event driver
> + * Copyright The Asahi Linux Contributors
> + *
> + * This driver exposes certain events from the SMC as an input device.
> + * This includes the lid open/close and power button notifications.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/mfd/core.h>
This looks like it shouldn't be there.
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/reboot.h>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 03/11] rtc: Add new rtc-macsmc driver for Apple Silicon Macs
From: Lee Jones @ 2025-11-06 13:54 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Hector Martin
In-Reply-To: <20251025-macsmc-subdevs-v4-3-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025, James Calligeros wrote:
> From: Hector Martin <marcan@marcan.st>
>
> Apple Silicon Macs (M1, etc.) have an RTC that is part of the PMU IC,
> but most of the PMU functionality is abstracted out by the SMC.
> On T600x machines, the RTC counter must be accessed via the SMC to
> get full functionality, and it seems likely that future machines
> will move towards making SMC handle all RTC functionality.
>
> The SMC RTC counter access is implemented on all current machines
> as of the time of this writing, on firmware 12.x. However, the RTC
> offset (needed to set the time) is still only accessible via direct
> PMU access. To handle this, we expose the RTC offset as an NVMEM
> cell from the SPMI PMU device node, and this driver consumes that
> cell and uses it to compute/set the current time.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Sven Peter <sven@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/rtc/Kconfig | 11 ++
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-macsmc.c | 141 +++++++++++++++++++++++++
> 4 files changed, 154 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10f4c0034b5e..3c6322872dd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2460,6 +2460,7 @@ F: drivers/nvmem/apple-spmi-nvmem.c
> F: drivers/pinctrl/pinctrl-apple-gpio.c
> F: drivers/power/reset/macsmc-reboot.c
> F: drivers/pwm/pwm-apple.c
> +F: drivers/rtc/rtc-macsmc.c
> F: drivers/soc/apple/*
> F: drivers/spi/spi-apple.c
> F: drivers/spmi/spmi-apple-controller.c
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 4a8dc8d0a4b7..e165301d4abb 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -2078,6 +2078,17 @@ config RTC_DRV_WILCO_EC
> This can also be built as a module. If so, the module will
> be named "rtc_wilco_ec".
>
> +config RTC_DRV_MACSMC
> + tristate "Apple Mac System Management Controller RTC"
> + depends on MFD_MACSMC
> + help
> + If you say yes here you get support for RTC functions
> + inside Apple SPMI PMUs accessed through the SoC's
> + System Management Controller
> +
> + To compile this driver as a module, choose M here: the
> + module will be called rtc-macsmc.
> +
> config RTC_DRV_MSC313
> tristate "MStar MSC313 RTC"
> depends on ARCH_MSTARV7 || COMPILE_TEST
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 610a9ee5fd33..32083bd5bb81 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_RTC_DRV_M48T35) += rtc-m48t35.o
> obj-$(CONFIG_RTC_DRV_M48T59) += rtc-m48t59.o
> obj-$(CONFIG_RTC_DRV_M48T86) += rtc-m48t86.o
> obj-$(CONFIG_RTC_DRV_MA35D1) += rtc-ma35d1.o
> +obj-$(CONFIG_RTC_DRV_MACSMC) += rtc-macsmc.o
> obj-$(CONFIG_RTC_DRV_MAX31335) += rtc-max31335.o
> obj-$(CONFIG_RTC_DRV_MAX6900) += rtc-max6900.o
> obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
> diff --git a/drivers/rtc/rtc-macsmc.c b/drivers/rtc/rtc-macsmc.c
> new file mode 100644
> index 000000000000..05e360277f63
> --- /dev/null
> +++ b/drivers/rtc/rtc-macsmc.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC RTC driver
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/mfd/core.h>
Why is this here?
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/rtc.h>
> +#include <linux/slab.h>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 00/11] mfd: macsmc: add rtc, hwmon and hid subdevices
From: Lee Jones @ 2025-11-06 13:55 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Mark Kettenis, Hector Martin
In-Reply-To: <20251025-macsmc-subdevs-v4-0-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025, James Calligeros wrote:
> Hi all,
>
> This series adds support for the remaining SMC subdevices. These are the
> RTC, hwmon, and HID devices. They are being submitted together as the RTC
> and hwmon drivers both require changes to the SMC DT schema.
>
> The RTC driver is responsible for getting and setting the system clock,
> and requires an NVMEM cell. This series replaces Sven's original RTC driver
> submission [1].
>
> The hwmon function is an interesting one. While each Apple Silicon device
> exposes pretty similar sets of sensors, these all seem to be paired to
> different SMC keys in the firmware interface. This is true even when the
> sensors are on the SoC. For example, an M1 MacBook Pro will use different
> keys to access the LITTLE core temperature sensors to an M1 Mac mini. This
> necessitates describing which keys correspond to which sensors for each
> device individually, and populating the hwmon structs at runtime. We do
> this with a node in the device tree. This series includes only the keys
> for sensors which we know to be common to all devices. The SMC is also
> responsible for monitoring and controlling fan speeds on systems with fans,
> which we expose via the hwmon driver.
>
> The SMC also handles the hardware power button and lid switch. Power
> button presses and lid opening/closing are emitted as HID events, so we
> add an input subdevice to handle them.
>
> Since there are no real dependencies between the components of this series,
> it should be fine for each subsystem to take the relevant patches through
> their trees. The mfd one-liners should be taken in order to avoid trivial
> conflicts.
The MFD parts look okay. Let me know when the other drivers have been
accepted and I'll apply them all.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v4 05/11] mfd: macsmc: Add new __SMC_KEY macro
From: Lee Jones @ 2025-11-06 13:56 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Jonathan Corbet, James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251025-macsmc-subdevs-v4-5-374d5c9eba0e@gmail.com>
On Sat, 25 Oct 2025 10:24:36 +1000, James Calligeros wrote:
> When using the _SMC_KEY macro in switch/case statements, GCC 15.2.1 errors
> out with 'case label does not reduce to an integer constant'. Introduce
> a new __SMC_KEY macro that can be used instead.
>
>
Applied, thanks!
[05/11] mfd: macsmc: Add new __SMC_KEY macro
commit: 8c3290b4c975e35a01aecfb51e0e004b6f7c0480
--
Lee Jones [李琼斯]
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and HWMON due for the v6.19 merge window
From: Lee Jones @ 2025-11-06 14:00 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251025-macsmc-subdevs-v4-6-374d5c9eba0e@gmail.com>
Whoever takes this driver will need to pull the following:
The following changes since commit 3a8660878839faadb4f1a6dd72c3179c1df56787:
Linux 6.18-rc1 (2025-10-12 13:42:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-hwmon-v6.19
for you to fetch changes up to b340412a3b22b60b5e19cce8726940c7b5b14439:
mfd: macsmc: Add new __SMC_KEY macro (2025-11-06 13:58:42 +0000)
----------------------------------------------------------------
Immutable branch between MFD and HWMON due for the v6.19 merge window
----------------------------------------------------------------
James Calligeros (1):
mfd: macsmc: Add new __SMC_KEY macro
include/linux/mfd/macsmc.h | 1 +
1 file changed, 1 insertion(+)
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v2 1/4] mfd: simple-mfd-i2c: remove select I2C_K1
From: Lee Jones @ 2025-11-06 16:04 UTC (permalink / raw)
To: Lee Jones, Yixun Lan, Alex Elder, Andi Shyti, Alexandre Belloni,
Liam Girdwood, Mark Brown, Troy Mitchell
Cc: linux-kernel, linux-riscv, spacemit, linux-i2c, linux-rtc,
kernel test robot
In-Reply-To: <20251027-p1-kconfig-fix-v2-1-49688f30bae8@linux.spacemit.com>
On Mon, 27 Oct 2025 13:48:05 +0800, Troy Mitchell wrote:
> select will force a symbol to a specific value without considering
> its dependencies. As a result, the i2c-k1 driver will fail to build
> when OF or COMMON_CLK are disabled.
>
> The reason for removing I2C_K1 instead of adding a depends on condition
> is to keep the possibility for other SoCs to use this PMIC.
>
> [...]
Applied, thanks!
[1/4] mfd: simple-mfd-i2c: remove select I2C_K1
commit: ecf6bc474ae97c404e2125b413eb0ef3627b03c5
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 06/25] rtc: Add driver for RDA Micro SoC
From: Alexandre Belloni @ 2025-11-06 22:42 UTC (permalink / raw)
To: dang.huynh
Cc: Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, Bartosz Golaszewski,
Michael Turquette, Stephen Boyd, Philipp Zabel, Sebastian Reichel,
Vinod Koul, Kees Cook, Gustavo A. R. Silva, Ulf Hansson,
linux-arm-kernel, linux-unisoc, devicetree, linux-kernel,
linux-gpio, linux-rtc, linux-clk, linux-pm, dmaengine,
linux-hardening, linux-mmc
In-Reply-To: <20250917-rda8810pl-drivers-v1-6-9ca9184ca977@mainlining.org>
Hello,
There are checkpatch --strict issues, please fix them.
On 17/09/2025 03:25:03+0700, Dang Huynh via B4 Relay wrote:
> MAINTAINERS | 6 +
> drivers/rtc/Kconfig | 11 ++
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-rda.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++
Unless you can guarantee this driver will support all the future RDA
SoC RTCs, the filename needs to be SoC specific.
> +config RTC_DRV_RDA
> + tristate "RDA Micro RTC"
> + depends on ARCH_RDA || COMPILE_TEST
> + select REGMAP_MMIO
> + help
> + If you say yes here you get support for the built-in RTC on
> + RDA Micro SoC.
You probably also need to list which ones are supported.
> +static int rda_rtc_settime(struct device *dev, struct rtc_time *tm)
> +{
> + struct rda_rtc *rtc = dev_get_drvdata(dev);
> + u32 high, low;
> + int ret;
> +
> + ret = rtc_valid_tm(tm);
> + if (ret < 0)
> + return ret;
The RTC core will never pass an invalid rtc_tm, this check is useless.
> +
> + /*
> + * The number of years since 1900 in kernel,
> + * but it is defined since 2000 by HW.
> + * The number of mons' range is from 0 to 11 in kernel,
> + * but it is defined from 1 to 12 by HW.
This comment is not super useful as this is super common in the RTC
drivers,. If you want to keep it, please fix it.
> + */
> + low = FIELD_PREP(RDA_SEC_MASK, tm->tm_sec) |
> + FIELD_PREP(RDA_MIN_MASK, tm->tm_min) |
> + FIELD_PREP(RDA_HRS_MASK, tm->tm_hour);
> +
> + high = FIELD_PREP(RDA_MDAY_MASK, tm->tm_mday) |
> + FIELD_PREP(RDA_MON_MASK, tm->tm_mon + 1) |
> + FIELD_PREP(RDA_YEAR_MASK, tm->tm_year - 100) |
> + FIELD_PREP(RDA_WDAY_MASK, tm->tm_wday);
> +
> + ret = regmap_write(rtc->regmap, RDA_RTC_CAL_LOAD_LOW_REG, low);
> + if (ret < 0) {
> + dev_err(dev, "Failed to update RTC low register: %d\n", ret);
This needs to be a dev_dbg or removed.
> + return ret;
> + }
> +
> + ret = regmap_write(rtc->regmap, RDA_RTC_CAL_LOAD_HIGH_REG, high);
> + if (ret < 0) {
> + dev_err(dev, "Failed to update RTC low register: %d\n", ret);
Ditto
> + return ret;
> + }
> +
> + ret = regmap_update_bits(rtc->regmap, RDA_RTC_CMD_REG, RDA_RTC_CMD_CAL_LOAD, 1);
> + if (ret < 0) {
> + dev_err(dev, "Failed to update RTC cal load register: %d\n", ret);
Ditto
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int rda_rtc_readtime(struct device *dev, struct rtc_time *tm)
> +{
> + struct rda_rtc *rtc = dev_get_drvdata(dev);
> + unsigned int high, low;
> + int ret;
> +
> + /*
> + * Check if RTC data is valid.
> + *
> + * When this bit is set, it means the data in the RTC is invalid
> + * or not configured.
> + */
> + ret = regmap_test_bits(rtc->regmap, RDA_RTC_STA_REG, RDA_RTC_STA_NOT_PROG);
> + if (ret < 0) {
> + dev_err(dev, "Failed to read RTC status: %d\n", ret);
dev_dbg
> + return ret;
> + } else if (ret > 0)
> + return -EINVAL;
> +
> + ret = regmap_read(rtc->regmap, RDA_RTC_CUR_LOAD_HIGH_REG, &high);
> + if (ret) {
> + dev_err(dev, "Failed to read RTC high reg: %d\n", ret);
Ditto
> + return ret;
> + }
> +
> + ret = regmap_read(rtc->regmap, RDA_RTC_CUR_LOAD_LOW_REG, &low);
> + if (ret) {
> + dev_err(dev, "Failed to read RTC low reg: %d\n", ret);
Ditto
> + return ret;
> + }
> +
> + tm->tm_sec = FIELD_GET(RDA_SEC_MASK, low);
> + tm->tm_min = FIELD_GET(RDA_MIN_MASK, low);
> + tm->tm_hour = FIELD_GET(RDA_HRS_MASK, low);
> + tm->tm_mday = FIELD_GET(RDA_MDAY_MASK, high);
> + tm->tm_mon = FIELD_GET(RDA_MON_MASK, high);
> + tm->tm_year = FIELD_GET(RDA_YEAR_MASK, high);
> + tm->tm_wday = FIELD_GET(RDA_WDAY_MASK, high);
> +
> + /*
> + * The number of years since 1900 in kernel,
> + * but it is defined since 2000 by HW.
> + */
> + tm->tm_year += 100;
> + /*
> + * The number of mons' range is from 0 to 11 in kernel,
> + * but it is defined from 1 to 12 by HW.
> + */
You can probably drop both comments.
> + tm->tm_mon -= 1;
> +
> + return 0;
> +}
> +
> +static int rda_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
> +{
> + struct rda_rtc *rtc = dev_get_drvdata(dev);
> + struct rtc_time *tm = &alrm->time;
> + unsigned int high, low;
> + int ret;
> +
> + ret = regmap_read(rtc->regmap, RDA_RTC_ALARM_HIGH_REG, &high);
> + if (ret) {
> + dev_err(dev, "Failed to read alarm low reg: %d\n", ret);
Just to be clear, the driver is super verbose with all those dev_err.
Strings are bloating the kernel and those string will probably never be
seen by any user and event if they are seen, the user doesn't have any
other action to do other than retrying. Please remove them of move them
to dev_dbg
> + return ret;
> + }
> +
> + ret = regmap_read(rtc->regmap, RDA_RTC_ALARM_LOW_REG, &low);
> + if (ret) {
> + dev_err(dev, "Failed to read alarm low reg: %d\n", ret);
> + return ret;
> + }
> +
> + tm->tm_sec = FIELD_GET(RDA_SEC_MASK, low);
> + tm->tm_min = FIELD_GET(RDA_MIN_MASK, low);
> + tm->tm_hour = FIELD_GET(RDA_HRS_MASK, low);
> + tm->tm_mday = FIELD_GET(RDA_MDAY_MASK, high);
> + tm->tm_mon = FIELD_GET(RDA_MON_MASK, high);
> + tm->tm_year = FIELD_GET(RDA_YEAR_MASK, high);
> + tm->tm_wday = FIELD_GET(RDA_WDAY_MASK, high);
> +
> + /*
> + * The number of years since 1900 in kernel,
> + * but it is defined since 2000 by HW.
> + */
> + tm->tm_year += 100;
> + /*
> + * The number of mons' range is from 0 to 11 in kernel,
> + * but it is defined from 1 to 12 by HW.
> + */
> + tm->tm_mon -= 1;
> +
> + return 0;
> +}
> +
> +static int rda_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
> +{
> + struct rda_rtc *rtc = dev_get_drvdata(dev);
> +
> + if (enabled)
> + return regmap_update_bits(rtc->regmap, RDA_RTC_CMD_REG,
> + RDA_RTC_CMD_ALARM_ENABLE, 1);
> +
> + return regmap_update_bits(rtc->regmap, RDA_RTC_CMD_REG,
> + RDA_RTC_CMD_ALARM_DISABLE, 1);
Wow, this is super weird, so you have one bit to enable and one to
disable the alarm. Is RDA_RTC_CMD_REG write only?
> +}
> +
> +static int rda_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
> +{
> + struct rda_rtc *rtc = dev_get_drvdata(dev);
> + struct rtc_time *tm = &alrm->time;
> + u32 high, low;
> + int ret;
> +
> + ret = rtc_valid_tm(tm);
> + if (ret < 0)
> + return ret;
> +
tm will never be invalid
> + /* TODO: Check if it's necessary to disable IRQ first */
I'd say probably not ;)
> + rda_rtc_alarm_irq_enable(dev, 0);
> +
> + /*
> + * The number of years since 1900 in kernel,
> + * but it is defined since 2000 by HW.
> + * The number of mons' range is from 0 to 11 in kernel,
> + * but it is defined from 1 to 12 by HW.
> + */
This is still the same comment...
> + low = FIELD_PREP(RDA_SEC_MASK, tm->tm_sec) |
> + FIELD_PREP(RDA_MIN_MASK, tm->tm_min) |
> + FIELD_PREP(RDA_HRS_MASK, tm->tm_hour);
> +
> + high = FIELD_PREP(RDA_MDAY_MASK, tm->tm_mday) |
> + FIELD_PREP(RDA_MON_MASK, tm->tm_mon + 1) |
> + FIELD_PREP(RDA_YEAR_MASK, tm->tm_year - 100) |
> + FIELD_PREP(RDA_WDAY_MASK, tm->tm_wday);
> +
> +
> + ret = regmap_write(rtc->regmap, RDA_RTC_ALARM_LOW_REG, low);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set low alarm register: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_write(rtc->regmap, RDA_RTC_ALARM_HIGH_REG, high);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set low alarm register: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_update_bits(rtc->regmap, RDA_RTC_CMD_REG, RDA_RTC_CMD_ALARM_LOAD, 1);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set alarm register: %d\n", ret);
> + return ret;
> + }
> +
> + dev_dbg(dev, "Alarm set: %4d-%02d-%02d %02d:%02d:%02d\n",
> + 2000 + (tm->tm_year - 100), tm->tm_mon + 1, tm->tm_mday,
> + tm->tm_hour, tm->tm_min, tm->tm_sec);
You probably want to use %ptR or drop this as we have a tracepoint just
after.
> +
> + return 0;
> +}
> +
> +static int rda_rtc_proc(struct device *dev, struct seq_file *seq)
> +{
> + struct rda_rtc *rtc = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = regmap_test_bits(rtc->regmap, RDA_RTC_STA_REG, RDA_RTC_STA_ALARM_ENABLE);
> + if (ret < 0) {
> + dev_err(dev, "Failed to read alarm status: %d\n", ret);
> + return ret;
> + }
> +
> + seq_printf(seq, "alarm enable\t: %s\n", (ret > 0) ? "yes" : "no");
> +
> + return 0;
> +}
Drop this function, this interface is obsolete
> +
> +static const struct rtc_class_ops rda_rtc_ops = {
> + .read_time = rda_rtc_readtime,
> + .set_time = rda_rtc_settime,
> + .read_alarm = rda_rtc_readalarm,
> + .set_alarm = rda_rtc_setalarm,
> + .proc = rda_rtc_proc,
> + .alarm_irq_enable = rda_rtc_alarm_irq_enable,
> +};
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int rda_rtc_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> + /* TODO: Check if it's okay to turn on alarm IRQ when it's not set */
> + return rda_rtc_alarm_irq_enable(&pdev->dev, 1);
> +}
> +
> +static int rda_rtc_resume(struct platform_device *pdev)
> +{
> + /* If alarms were left, we turn them off. */
> + return rda_rtc_alarm_irq_enable(&pdev->dev, 0);
> +}
Let userspace enabling/disabling alarm, the kernel must not decide to
enable or disable them which fixes your TODO
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(rda_rtc_pm_ops, rda_rtc_suspend, rda_rtc_resume);
> +
> +static const struct regmap_config regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static int rda_rtc_probe(struct platform_device *pdev)
> +{
> + struct rda_rtc *rda_rtc;
> + void __iomem *base;
> +
> + rda_rtc = devm_kzalloc(&pdev->dev, sizeof(*rda_rtc), GFP_KERNEL);
> + if (!rda_rtc)
> + return -ENOMEM;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return dev_err_probe(&pdev->dev, PTR_ERR(base),
> + "failed to remap resource\n");
> +
> + rda_rtc->regmap = devm_regmap_init_mmio(&pdev->dev, base, ®map_config);
> + if (!rda_rtc->regmap)
> + return dev_err_probe(&pdev->dev, PTR_ERR(rda_rtc->regmap),
> + "can't find regmap\n");
> +
> + rda_rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
> + if (IS_ERR(rda_rtc->rtc_dev))
> + return dev_err_probe(&pdev->dev, PTR_ERR(rda_rtc->rtc_dev),
> + "failed to allocate rtc device\n");
> +
> + rda_rtc->rtc_dev->ops = &rda_rtc_ops;
> + rda_rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_2000;
> + rda_rtc->rtc_dev->range_max = RTC_TIMESTAMP_END_2127;
> +
> + platform_set_drvdata(pdev, rda_rtc);
> +
> + return devm_rtc_register_device(rda_rtc->rtc_dev);
> +}
> +
> +static const struct of_device_id rda_rtc_id_table[] = {
> + { .compatible = "rda,8810pl-rtc", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, rda_rtc_id_table);
> +
> +static struct platform_driver rda_rtc_driver = {
> + .probe = rda_rtc_probe,
> + .driver = {
> + .name = "rtc-rda",
> + .pm = &rda_rtc_pm_ops,
> + .of_match_table = rda_rtc_id_table,
> + },
> +};
> +module_platform_driver(rda_rtc_driver);
> +
> +MODULE_AUTHOR("Dang Huynh <dang.huynh@mainlining.org>");
> +MODULE_DESCRIPTION("RDA Micro RTC driver");
> +MODULE_LICENSE("GPL");
>
> --
> 2.51.0
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH V6 0/3] rtc: atcrtc100: Add Andes ATCRTC100 RTC driver
From: Alexandre Belloni @ 2025-11-06 22:47 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, CL Wang
Cc: devicetree, linux-kernel, linux-rtc, tim609
In-Reply-To: <20250915031439.2680364-1-cl634@andestech.com>
On Mon, 15 Sep 2025 11:14:36 +0800, CL Wang wrote:
> This patch series adds support for the Andes ATCRTC100 Real-Time Clock.
>
> The series is now based on the rtc-next branch from:
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git.
>
> This V6 patch series is built upon the V5 series and has been rebased
> exclusively onto the latest commit in the rtc-next branch, which
> corresponds to rtc-6.17."
>
> [...]
Applied, thanks!
[1/3] dt-bindings: rtc: Add support for ATCRTC100 RTC
https://git.kernel.org/abelloni/c/e1794c59730a
[2/3] MAINTAINERS: Add entry for ATCRTC100 RTC driver
https://git.kernel.org/abelloni/c/a603092d5be1
[3/3] rtc: atcrtc100: Add ATCRTC100 RTC driver
https://git.kernel.org/abelloni/c/7adca706fe16
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v7 0/4] Add NVIDIA VRS RTC support
From: Alexandre Belloni @ 2025-11-06 22:56 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Catalin Marinas, Will Deacon, Jonathan Hunter, Shubhi Garg
Cc: devicetree, linux-arm-kernel, linux-rtc, linux-tegra
In-Reply-To: <20251007135738.487694-1-shgarg@nvidia.com>
On Tue, 07 Oct 2025 13:57:34 +0000, Shubhi Garg wrote:
> This patch series adds support for NVIDIA's Voltage Regulator Specification
> (VRS) RTC device. It provides following features:
> - read/set system time
> - 32kHz clock support with backup battery input to retain system time
> across boot
> - alarm functionality to wake system from suspend and shutdown state
>
> [...]
Applied, thanks!
[1/4] dt-bindings: rtc: Document NVIDIA VRS RTC
https://git.kernel.org/abelloni/c/4c03653f19ae
[3/4] rtc: nvvrs: add NVIDIA VRS RTC device driver
https://git.kernel.org/abelloni/c/9d6d6b06933c
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v2 1/4] mfd: simple-mfd-i2c: remove select I2C_K1
From: Troy Mitchell @ 2025-11-07 1:29 UTC (permalink / raw)
To: Lee Jones, Yixun Lan, Alex Elder, Andi Shyti, Alexandre Belloni,
Liam Girdwood, Mark Brown, Troy Mitchell
Cc: linux-kernel, linux-riscv, spacemit, linux-i2c, linux-rtc,
kernel test robot
In-Reply-To: <176244506110.1925720.10807118665958896958.b4-ty@kernel.org>
On Thu, Nov 06, 2025 at 04:04:21PM +0000, Lee Jones wrote:
> On Mon, 27 Oct 2025 13:48:05 +0800, Troy Mitchell wrote:
> > select will force a symbol to a specific value without considering
> > its dependencies. As a result, the i2c-k1 driver will fail to build
> > when OF or COMMON_CLK are disabled.
> >
> > The reason for removing I2C_K1 instead of adding a depends on condition
> > is to keep the possibility for other SoCs to use this PMIC.
> >
> > [...]
>
> Applied, thanks!
>
> [1/4] mfd: simple-mfd-i2c: remove select I2C_K1
> commit: ecf6bc474ae97c404e2125b413eb0ef3627b03c5
Hi Lee,
I think you didn't notice this reply [1]
(Maybe because he was replying to the cover letter).
As Aurelien mentioned, the current shutdown/reboot (and possibly the regulator
as well) intends to use the `default MFD_SPACEMIT_P1`.
So if there’s no `default m if ARCH_SPACEMIT`,
the default value in subdevices may not make much sense.
But don’t worry — to make things easier for you, I’ll send an additional
patch based on your branch (in this series).
How does that sound?
Link: https://lore.kernel.org/all/aP9IVckJT-k2_O4K@aurel32.net/ [1]
>
> --
> Lee Jones [李琼斯]
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox