Linux RTC
 help / color / mirror / Atom feed
* Re: [PATCH v2 4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq balance
From: Alexandre Belloni @ 2025-10-29 10:39 UTC (permalink / raw)
  To: Jon Hunter
  Cc: Esben Haabendal, linux-rtc, linux-kernel, linux-arm-kernel,
	linux-tegra@vger.kernel.org
In-Reply-To: <0aae5643-9276-4280-8b1e-27b8fe73fe99@nvidia.com>

On 29/10/2025 09:20:17+0000, Jon Hunter wrote:
> Hi Esben,
> 
> On 16/05/2025 08:23, Esben Haabendal wrote:
> > Interrupts are automatically enabled when requested, so we need to
> > initialize irq_en accordingly to avoid causing an unbalanced enable
> > warning.
> > 
> > Signed-off-by: Esben Haabendal <esben@geanix.com>
> > ---
> >   drivers/rtc/rtc-tps6586x.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/rtc/rtc-tps6586x.c b/drivers/rtc/rtc-tps6586x.c
> > index 54c8429b16bfcc692b1f4d5404f0c42f720e93b4..76ecf7b798f0de22aa89a552a263b473ab3065ef 100644
> > --- a/drivers/rtc/rtc-tps6586x.c
> > +++ b/drivers/rtc/rtc-tps6586x.c
> > @@ -258,6 +258,7 @@ static int tps6586x_rtc_probe(struct platform_device *pdev)
> >   	irq_set_status_flags(rtc->irq, IRQ_NOAUTOEN);
> > +	rtc->irq_en = true;
> >   	ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> >   				tps6586x_rtc_irq,
> >   				IRQF_ONESHOT,
> > 
> 
> I have bisected a suspend regression on one of our Tegra20 boards (that uses
> this driver) and bisect is pointing to this commit. Reverting this commit
> fixes the problem.
> 
> Looking at the above I see that the flag IRQ_NOAUTOEN is being set and so
> now with your change we never enable the interrupt. Hence, the wake-ups are
> now broken and suspend testing fails. So it would seem best to revert this.
> 
> BTW, I looked at the change to the CPCAP driver and that driver actively
> disables the IRQ after requesting it and so I am wondering if that will also
> have alarm issues? I don't have a board with CPCAP to test.
> 

That's right, I guess you can send reverts.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v2 4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq balance
From: Jon Hunter @ 2025-10-29  9:20 UTC (permalink / raw)
  To: Esben Haabendal, Alexandre Belloni
  Cc: linux-rtc, linux-kernel, linux-arm-kernel,
	linux-tegra@vger.kernel.org
In-Reply-To: <20250516-rtc-uie-irq-fixes-v2-4-3de8e530a39e@geanix.com>

Hi Esben,

On 16/05/2025 08:23, Esben Haabendal wrote:
> Interrupts are automatically enabled when requested, so we need to
> initialize irq_en accordingly to avoid causing an unbalanced enable
> warning.
> 
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---
>   drivers/rtc/rtc-tps6586x.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/rtc/rtc-tps6586x.c b/drivers/rtc/rtc-tps6586x.c
> index 54c8429b16bfcc692b1f4d5404f0c42f720e93b4..76ecf7b798f0de22aa89a552a263b473ab3065ef 100644
> --- a/drivers/rtc/rtc-tps6586x.c
> +++ b/drivers/rtc/rtc-tps6586x.c
> @@ -258,6 +258,7 @@ static int tps6586x_rtc_probe(struct platform_device *pdev)
>   
>   	irq_set_status_flags(rtc->irq, IRQ_NOAUTOEN);
>   
> +	rtc->irq_en = true;
>   	ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
>   				tps6586x_rtc_irq,
>   				IRQF_ONESHOT,
> 

I have bisected a suspend regression on one of our Tegra20 boards (that 
uses this driver) and bisect is pointing to this commit. Reverting this 
commit fixes the problem.

Looking at the above I see that the flag IRQ_NOAUTOEN is being set and 
so now with your change we never enable the interrupt. Hence, the 
wake-ups are now broken and suspend testing fails. So it would seem best 
to revert this.

BTW, I looked at the change to the CPCAP driver and that driver actively 
disables the IRQ after requesting it and so I am wondering if that will 
also have alarm issues? I don't have a board with CPCAP to test.

Thanks
Jon

-- 
nvpublic


^ permalink raw reply

* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Matti Vaittinen @ 2025-10-29  6:32 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  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, Andreas Kemnade,
	Alexandre Belloni, linux-leds, devicetree, linux-kernel, linux-pm,
	linux-clk, linux-gpio, linux-rtc
In-Reply-To: <a81fba66-adf0-440f-96e1-bf3a83d504d8@gmail.com>

ke 29.10.2025 klo 8.22 Matti Vaittinen (mazziesaccount@gmail.com) kirjoitti:
>
> On 29/10/2025 08:03, Krzysztof Kozlowski wrote:
> > On Mon, Oct 27, 2025 at 01:45:05PM +0200, Matti Vaittinen wrote:
> >> 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.
> >
>This is already reflected by existing bindings:
> trickle-charge-current-microamp, Please, see:
> bbcecd1b9335 ("dt-bindings: Add trickle-charge upper limit")
>
Sorry, wrong commit! It should have been the
e3420b49949c ("dt-bindings: battery: add new battery parameters")
as you found out.

(Just a clarification for anyone reading this thread)

^ permalink raw reply

* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Matti Vaittinen @ 2025-10-29  6:24 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  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, Andreas Kemnade,
	Alexandre Belloni, linux-leds, devicetree, linux-kernel, linux-pm,
	linux-clk, linux-gpio, linux-rtc
In-Reply-To: <b30eed8e-c8f8-4077-9e6a-0217c5827981@kernel.org>

On 29/10/2025 08:17, Krzysztof Kozlowski wrote:
> On 29/10/2025 07:03, Krzysztof Kozlowski wrote:
>> On Mon, Oct 27, 2025 at 01:45:05PM +0200, Matti Vaittinen wrote:
>>> 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.
>>
>> In the few cases I was dealing with charging circuits, trickle charging
>> was used in context of top-off charging, so when battery is 100%. It's
>> also documented at Wiki like that:
>> https://en.wikipedia.org/wiki/Trickle_charging
>>
>>> 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.
>>
>> pre-charging is the trickle charging, no? Or you want to say that
>> trickle-charging is pre-pre-charging? But then what is pre-charging in
>> this binding?
> 
> 
> Now I see that you added initial trickle-charging in commit
> e3420b49949c79d6182dd8128fa7a3958da01b07. I looked at TI chargers for
> LiIon/LiPo batteries and few popular models use the same meaning/cycles
> as you here. Probably in LiIon/LiPo you cannot or should not use trickle
> for top-off charging (CV phase).
> 
> For NiMh these TI chargers use term "Trickle Maintenance Charge" (e.g.
> bq24400), so in separate or this patch please also clarify the
> description of properties that this is trickle-charging for LiIon/LiPo
> batteries, so the pre-pre charging.

Right. I'll try improving the description. Thanks!

> 
> Best regards,
> Krzysztof


^ permalink raw reply

* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Matti Vaittinen @ 2025-10-29  6:22 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  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, Andreas Kemnade,
	Alexandre Belloni, linux-leds, devicetree, linux-kernel, linux-pm,
	linux-clk, linux-gpio, linux-rtc
In-Reply-To: <20251029-adamant-mamba-of-patience-cddb65@kuoka>

On 29/10/2025 08:03, Krzysztof Kozlowski wrote:
> On Mon, Oct 27, 2025 at 01:45:05PM +0200, Matti Vaittinen wrote:
>> 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.
> 
> In the few cases I was dealing with charging circuits, trickle charging
> was used in context of top-off charging, so when battery is 100%. It's
> also documented at Wiki like that:
> https://en.wikipedia.org/wiki/Trickle_charging
> 
>> 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.


> pre-charging is the trickle charging, no? Or you want to say that
> trickle-charging is pre-pre-charging? But then what is pre-charging in
> this binding?

There are the (usual?) pre-charging and fast-charging phases in the Rohm 
devices. Furthermore, the fast-charging is divided to constant current 
and constant voltage phases.

In addition to this, there is a 'trickle-charging' -phase for a very 
empty battery. This is already reflected by existing bindings:
trickle-charge-current-microamp, Please, see:
bbcecd1b9335 ("dt-bindings: Add trickle-charge upper limit")

I also did do some ASCII art for my very first charger driver binding:
https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml

Do you think a comment linking to this drawing would help?

> 
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> ---
>> Revision history:
>>   RFCv1 =>:
>>   - No changes
>> ---
>>   Documentation/devicetree/bindings/power/supply/battery.yaml | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml
>> index 491488e7b970..66bed24b3dee 100644
>> --- a/Documentation/devicetree/bindings/power/supply/battery.yaml
>> +++ b/Documentation/devicetree/bindings/power/supply/battery.yaml
>> @@ -66,6 +66,9 @@ properties:
>>     trickle-charge-current-microamp:
>>       description: current for trickle-charge phase
>>   
>> +  tricklecharge-upper-limit-microvolt:
> 
> Please keep existing format, look three lines above. trickle-charge-....
> 
> But I believe this is wrong. Trickle charging does not switch to
> anything more, there is no fast charging after trickle. You have some
> sort of pre-pre-charging, which is just pre-charging.

There is trickle, pre and fast-charge phases. Furthermore, the 
fast-charge is further divided to CC and CV. Finally, if my memory 
serves me well, Linus W did explain me that some chargers use 
'trickle-charging' as a _last_ charging phase for a full battery. Thus 
the term 'trickle-charging' is slightly confusing - but it is already 
used by the existing bindings...

https://lore.kernel.org/all/20211116001755.2132036-1-linus.walleij@linaro.org/


Yours,
	-- Matti

^ permalink raw reply

* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Krzysztof Kozlowski @ 2025-10-29  6:17 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, Andreas Kemnade,
	Alexandre Belloni, linux-leds, devicetree, linux-kernel, linux-pm,
	linux-clk, linux-gpio, linux-rtc
In-Reply-To: <20251029-adamant-mamba-of-patience-cddb65@kuoka>

On 29/10/2025 07:03, Krzysztof Kozlowski wrote:
> On Mon, Oct 27, 2025 at 01:45:05PM +0200, Matti Vaittinen wrote:
>> 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.
> 
> In the few cases I was dealing with charging circuits, trickle charging
> was used in context of top-off charging, so when battery is 100%. It's
> also documented at Wiki like that:
> https://en.wikipedia.org/wiki/Trickle_charging
> 
>> 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.
> 
> pre-charging is the trickle charging, no? Or you want to say that
> trickle-charging is pre-pre-charging? But then what is pre-charging in
> this binding?


Now I see that you added initial trickle-charging in commit
e3420b49949c79d6182dd8128fa7a3958da01b07. I looked at TI chargers for
LiIon/LiPo batteries and few popular models use the same meaning/cycles
as you here. Probably in LiIon/LiPo you cannot or should not use trickle
for top-off charging (CV phase).

For NiMh these TI chargers use term "Trickle Maintenance Charge" (e.g.
bq24400), so in separate or this patch please also clarify the
description of properties that this is trickle-charging for LiIon/LiPo
batteries, so the pre-pre charging.

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Krzysztof Kozlowski @ 2025-10-29  6:03 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, Andreas Kemnade,
	Alexandre Belloni, linux-leds, devicetree, linux-kernel, linux-pm,
	linux-clk, linux-gpio, linux-rtc
In-Reply-To: <b13b733e7e0fba05652f49f727412fed9e0ceb02.1761564043.git.mazziesaccount@gmail.com>

On Mon, Oct 27, 2025 at 01:45:05PM +0200, Matti Vaittinen wrote:
> 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.

In the few cases I was dealing with charging circuits, trickle charging
was used in context of top-off charging, so when battery is 100%. It's
also documented at Wiki like that:
https://en.wikipedia.org/wiki/Trickle_charging

> 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.

pre-charging is the trickle charging, no? Or you want to say that
trickle-charging is pre-pre-charging? But then what is pre-charging in
this binding?

> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> ---
> Revision history:
>  RFCv1 =>:
>  - No changes
> ---
>  Documentation/devicetree/bindings/power/supply/battery.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml
> index 491488e7b970..66bed24b3dee 100644
> --- a/Documentation/devicetree/bindings/power/supply/battery.yaml
> +++ b/Documentation/devicetree/bindings/power/supply/battery.yaml
> @@ -66,6 +66,9 @@ properties:
>    trickle-charge-current-microamp:
>      description: current for trickle-charge phase
>  
> +  tricklecharge-upper-limit-microvolt:

Please keep existing format, look three lines above. trickle-charge-....

But I believe this is wrong. Trickle charging does not switch to
anything more, there is no fast charging after trickle. You have some
sort of pre-pre-charging, which is just pre-charging.

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v2 05/15] dt-bindings: leds: bd72720: Add BD72720
From: Krzysztof Kozlowski @ 2025-10-28  8:25 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, Andreas Kemnade,
	Alexandre Belloni, linux-leds, devicetree, linux-kernel, linux-pm,
	linux-clk, linux-gpio, linux-rtc
In-Reply-To: <fae1285b43acdd19cebfcfbcf4530bf90064f601.1761564043.git.mazziesaccount@gmail.com>

On Mon, Oct 27, 2025 at 01:46:04PM +0200, Matti Vaittinen wrote:
> Add the ROHM BD72720 documentation to the binding documents.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v7 0/4] Add NVIDIA VRS RTC support
From: Shubhi Garg @ 2025-10-28  7:09 UTC (permalink / raw)
  To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Catalin Marinas, Will Deacon, Alexandre Belloni, Jonathan Hunter,
	Thierry Reding
  Cc: devicetree, linux-arm-kernel, linux-rtc, linux-tegra
In-Reply-To: <20251007135738.487694-1-shgarg@nvidia.com>

Hi all,

Gentle ping on this series.


On 07/10/25 7:27 pm, 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
> 
> Changes in v7:
> - rtc driver fixes to remove mutex lock
> - moved rtc register definitions in driver
> - dt binding file name fix to keep same as compatible
> 
> Changes in v6:
> - compatible name fixes to "nvidia,vrs-10"
> - changed dtb node name to pmic@3c
> 
> Changes in v5:
> - moved device tree bindings from mfd to rtc
> - changed dtb node name to rtc@3c
> - removed VRS MFD driver
> - moved VRS common functions to RTC driver
> - removed unused register definitions from header
> - changed driver compatible to "nvidia,vrs10-rtc"
> 
> Changes in v4:
> - fixed device tree node name to "pmic@3c" in dtb aliases
> 
> Changes in v3:
> - fixed device tree node name to generic "pmic@3c"
> - fixed indentation in dt-bindings
> - added rate limiting to interrupt clearing debug logs
> - removed unnecessary braces in if blocks
> - changed dependency from I2C=y to I2C in mfd Kconfig
> - fixed return value in RTC driver function calls
> - fixed sizeof(*variable) inside rtc driver devm_kzalloc
> - switch to devm_device_init_wakeup() for automatic cleanup
> 
> Changes in v2:
> - fixed, copyrights, definitions and dtb node in dt-bindings
> - removed unnecessary logs from MFD and RTC driver
> - fixed RTC allocation and registration APIs
> - removed unnecessary functions in RTC driver
> - used rtc_lock/unlock in RTC irq handler
> - added alias to assign VRS RTC as RTC0
> - added driver entry in MAINTAINERS
> - few other miinor changes done in drivers
> 
> Shubhi Garg (4):
>    dt-bindings: rtc: Document NVIDIA VRS RTC
>    arm64: tegra: Add device-tree node for NVVRS RTC
>    rtc: nvvrs: add NVIDIA VRS RTC device driver
>    arm64: defconfig: enable NVIDIA VRS PSEQ RTC
> 
>   .../bindings/rtc/nvidia,vrs-10.yaml           |  59 ++
>   MAINTAINERS                                   |   8 +
>   .../arm64/boot/dts/nvidia/tegra234-p3701.dtsi |  11 +
>   .../arm64/boot/dts/nvidia/tegra234-p3767.dtsi |  15 +
>   arch/arm64/configs/defconfig                  |   1 +
>   drivers/rtc/Kconfig                           |   9 +
>   drivers/rtc/Makefile                          |   1 +
>   drivers/rtc/rtc-nvidia-vrs10.c                | 542 ++++++++++++++++++
>   8 files changed, 646 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/rtc/nvidia,vrs-10.yaml
>   create mode 100644 drivers/rtc/rtc-nvidia-vrs10.c
> 

-- 
Regards,
Shubhi


^ permalink raw reply

* Re: [PATCH v2 00/15] Support ROHM BD72720 PMIC
From: Matti Vaittinen @ 2025-10-28  6:39 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <cover.1761564043.git.mazziesaccount@gmail.com>

On 27/10/2025 13:44, Matti Vaittinen wrote:
> The ROHM BD72720 is a new power management IC for portable, battery
> powered devices. It integrates 10 BUCKs and 11 LDOs, RTC, charger, LEDs,
> GPIOs and a clock gate. To me the BD72720 seems like a successor to the
> BD71828 and BD71815 PMICs.
> 
> This series depends on the series: "[PATCH v5 0/3] power: supply: add
> charger for BD71828":
> https://lore.kernel.org/all/20250918-bd71828-charger-v5-0-851164839c28@kemnade.info/
> sent by Andreas. The power-supplly and MAINTAINERs patches (2/3 and 3/3)
> from that serties aren't merged yet.
> 
> Revision history:
>    RFCv1 => v2:
>    - Drop RFC status
>    - Use stacked regmaps to hide secondary map from the sub-drivers
>    - Quite a few styling fixes and improvements as suggested by
>      reviewers. More accurate changelog in individual patches.
>    - Link to v1:
>      https://lore.kernel.org/all/cover.1759824376.git.mazziesaccount@gmail.com/

As Alexandre pointed out, the 07/15 (MFD) patch was missing from the 
series. For some reason, google's SMTP severs refused from sending it 
with the recipient list used for all other patches, with just: "Status: 
5.7.1". After several retries I had to give-up yesterday.

Today I managed to get it through, after I dropped every direct CC 
address, leaving only the lists. No idea what is happening :(

Anyways, it's in the lore for the interested:
https://lore.kernel.org/all/4c964cef46a396209052aa4194d08fc03f989647.1761564043.git.mazziesaccount@gmail.com/

I will in any case re-spin the series with suggested changes - so 
hopefully I can get the v3 sent correctly to all the recipients :/

Yours,
	-- Matti

^ permalink raw reply

* [PATCH v2 07/15] mfd: bd71828: Support ROHM BD72720
From: Matti Vaittinen @ 2025-10-28  6:06 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <cover.1761564043.git.mazziesaccount@gmail.com>

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

The ROHM BD72720 is a power management IC which continues the BD71828
family of PMICs. Similarly to the BD71815 and BD71828, the BD72720
integrates regulators, charger, RTC, clock gate and GPIOs.

The main difference to the earlier PMICs is that the BD72720 has two
different I2C slave addresses. In addition to the registers behind the
'main I2C address', most of the charger (and to some extent LED) control
is done via registers behind a 'secondary I2C slave address', 0x4c.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

For some reason the gmail SMTP server refused from sending this (several
times). If anyone receives this more than once - I am sorry! In order to
get this through I now send this only to the lists, dropping all the
direct CCs...

Seems I need to find alternate SMTP server for my patches :(

Revision history:
 RFCv1 => v2: (Mostly addressed comments from Lee and Andreas)
 - Use stacked regmaps to avoid platform data and the tango with
   multiple regmaps in the power-supply driver
 - Use regmap_reg_range()
 - make it clear bd72720_irq_type_base is an array
 - tab-out definitions in the bd72720 header
 - minor styling

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/

There are some new variants being planned. Most notably, the BD73900
should be almost identical to the BD72720 - for everything else except
the charger block.
---
 drivers/mfd/Kconfig              |  18 +-
 drivers/mfd/rohm-bd71828.c       | 488 +++++++++++++++++++++++-
 include/linux/mfd/rohm-bd72720.h | 634 +++++++++++++++++++++++++++++++
 include/linux/mfd/rohm-generic.h |   1 +
 4 files changed, 1126 insertions(+), 15 deletions(-)
 create mode 100644 include/linux/mfd/rohm-bd72720.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6cec1858947b..61e238b316f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2211,20 +2211,22 @@ config MFD_ROHM_BD718XX
 	  and emergency shut down as well as 32,768KHz clock output.
 
 config MFD_ROHM_BD71828
-	tristate "ROHM BD71828 and BD71815 Power Management IC"
+	tristate "ROHM BD718[15/28/79], BD72720 and BD73900 PMICs"
 	depends on I2C=y
 	depends on OF
 	select REGMAP_I2C
 	select REGMAP_IRQ
 	select MFD_CORE
 	help
-	  Select this option to get support for the ROHM BD71828 and BD71815
-	  Power Management ICs. BD71828GW and BD71815AGW are single-chip power
-	  management ICs mainly for battery-powered portable devices.
-	  The BD71828 integrates 7 buck converters and 7 LDOs. The BD71815
-	  has 5 bucks, 7 LDOs, and a boost for driving LEDs. Both ICs provide
-	  also a single-cell linear charger, a Coulomb counter, a real-time
-	  clock (RTC), GPIOs and a 32.768 kHz clock gate.
+	  Select this option to get support for the ROHM BD71815, BD71828,
+	  BD71879, BD72720 and BD73900 Power Management ICs. These are
+	  single-chip power management ICs mainly for battery-powered portable
+	  devices.
+	  The BD71815 has 5 bucks, 7 LDOs, and a boost for driving LEDs.
+	  The BD718[28/79] have 7 buck converters and 7 LDOs.
+	  The BD72720 and the BD73900 have 10 bucks and 11 LDOs.
+	  All ICs provide a single-cell linear charger, a Coulomb counter,
+	  a real-time clock (RTC), GPIOs and a 32.768 kHz clock gate.
 
 config MFD_ROHM_BD957XMUF
 	tristate "ROHM BD9576MUF and BD9573MUF Power Management ICs"
diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
index 2a43005b67ee..2e546aa60ffd 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -2,7 +2,7 @@
 //
 // Copyright (C) 2019 ROHM Semiconductors
 //
-// ROHM BD71828/BD71815 PMIC driver
+// ROHM BD718[15/28/79] and BD72720 PMIC driver
 
 #include <linux/gpio_keys.h>
 #include <linux/i2c.h>
@@ -13,12 +13,29 @@
 #include <linux/mfd/core.h>
 #include <linux/mfd/rohm-bd71815.h>
 #include <linux/mfd/rohm-bd71828.h>
+#include <linux/mfd/rohm-bd72720.h>
 #include <linux/mfd/rohm-generic.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/regmap.h>
 #include <linux/types.h>
 
+#define BD72720_TYPED_IRQ_REG(_irq, _stat_offset, _mask, _type_offset)     \
+	[_irq] = {							   \
+		.reg_offset = (_stat_offset),				   \
+		.mask = (_mask),					   \
+		{							   \
+			.type_reg_offset = (_type_offset),		   \
+			.type_reg_mask = BD72720_GPIO_IRQ_TYPE_MASK,	   \
+			.type_rising_val = BD72720_GPIO_IRQ_TYPE_RISING,   \
+			.type_falling_val = BD72720_GPIO_IRQ_TYPE_FALLING, \
+			.type_level_low_val = BD72720_GPIO_IRQ_TYPE_LOW,   \
+			.type_level_high_val = BD72720_GPIO_IRQ_TYPE_HIGH, \
+			.types_supported = IRQ_TYPE_EDGE_BOTH |		   \
+				IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW,  \
+		},							   \
+	}
+
 static struct gpio_keys_button button = {
 	.code = KEY_POWER,
 	.gpio = -1,
@@ -43,6 +60,12 @@ static const struct resource bd71828_rtc_irqs[] = {
 	DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC2, "bd70528-rtc-alm-2"),
 };
 
+static const struct resource bd72720_rtc_irqs[] = {
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_RTC0, "bd70528-rtc-alm-0"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_RTC1, "bd70528-rtc-alm-1"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_RTC2, "bd70528-rtc-alm-2"),
+};
+
 static const struct resource bd71815_power_irqs[] = {
 	DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_RMV, "bd71815-dcin-rmv"),
 	DEFINE_RES_IRQ_NAMED(BD71815_INT_CLPS_OUT, "bd71815-dcin-clps-out"),
@@ -156,6 +179,74 @@ static struct mfd_cell bd71828_mfd_cells[] = {
 	},
 };
 
+static const struct resource bd72720_power_irqs[] = {
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBUS_RMV, "bd72720_int_vbus_rmv"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBUS_DET, "bd72720_int_vbus_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBUS_MON_RES, "bd72720_int_vbus_mon_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBUS_MON_DET, "bd72720_int_vbus_mon_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_MON_RES, "bd72720_int_vsys_mon_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_MON_DET, "bd72720_int_vsys_mon_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_UV_RES, "bd72720_int_vsys_uv_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_UV_DET, "bd72720_int_vsys_uv_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_LO_RES, "bd72720_int_vsys_lo_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_LO_DET, "bd72720_int_vsys_lo_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_OV_RES, "bd72720_int_vsys_ov_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VSYS_OV_DET, "bd72720_int_vsys_ov_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_BAT_ILIM, "bd72720_int_bat_ilim"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_CHG_DONE, "bd72720_int_chg_done"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_EXTEMP_TOUT, "bd72720_int_extemp_tout"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_CHG_WDT_EXP, "bd72720_int_chg_wdt_exp"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_BAT_MNT_OUT, "bd72720_int_bat_mnt_out"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_BAT_MNT_IN, "bd72720_int_bat_mnt_in"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_CHG_TRNS, "bd72720_int_chg_trns"),
+
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_MON_RES, "bd72720_int_vbat_mon_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_MON_DET, "bd72720_int_vbat_mon_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_SHT_RES, "bd72720_int_vbat_sht_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_SHT_DET, "bd72720_int_vbat_sht_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_LO_RES, "bd72720_int_vbat_lo_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_LO_DET, "bd72720_int_vbat_lo_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_OV_RES, "bd72720_int_vbat_ov_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_VBAT_OV_DET, "bd72720_int_vbat_ov_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_BAT_RMV, "bd72720_int_bat_rmv"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_BAT_DET, "bd72720_int_bat_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_DBAT_DET, "bd72720_int_dbat_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_BAT_TEMP_TRNS, "bd72720_int_bat_temp_trns"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_LOBTMP_RES, "bd72720_int_lobtmp_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_LOBTMP_DET, "bd72720_int_lobtmp_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OVBTMP_RES, "bd72720_int_ovbtmp_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OVBTMP_DET, "bd72720_int_ovbtmp_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OCUR1_RES, "bd72720_int_ocur1_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OCUR1_DET, "bd72720_int_ocur1_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OCUR2_RES, "bd72720_int_ocur2_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OCUR2_DET, "bd72720_int_ocur2_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OCUR3_RES, "bd72720_int_ocur3_res"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_OCUR3_DET, "bd72720_int_ocur3_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_CC_MON1_DET, "bd72720_int_cc_mon1_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_CC_MON2_DET, "bd72720_int_cc_mon2_det"),
+	DEFINE_RES_IRQ_NAMED(BD72720_INT_CC_MON3_DET, "bd72720_int_cc_mon3_det"),
+};
+
+static const struct mfd_cell bd72720_mfd_cells[] = {
+	{ .name = "bd72720-pmic", },
+	{ .name = "bd72720-gpio", },
+	{ .name = "bd72720-led", },
+	{ .name = "bd72720-clk", },
+	{
+		.name = "bd72720-power",
+		.resources = bd72720_power_irqs,
+		.num_resources = ARRAY_SIZE(bd72720_power_irqs),
+	}, {
+		.name = "bd72720-rtc",
+		.resources = bd72720_rtc_irqs,
+		.num_resources = ARRAY_SIZE(bd72720_rtc_irqs),
+	}, {
+		.name = "gpio-keys",
+		.platform_data = &bd71828_powerkey_data,
+		.pdata_size = sizeof(bd71828_powerkey_data),
+	},
+};
+
 static const struct regmap_range bd71815_volatile_ranges[] = {
 	regmap_reg_range(BD71815_REG_SEC, BD71815_REG_YEAR),
 	regmap_reg_range(BD71815_REG_CONF, BD71815_REG_BAT_TEMP),
@@ -180,6 +271,87 @@ static const struct regmap_range bd71828_volatile_ranges[] = {
 	regmap_reg_range(BD71828_REG_INT_MAIN, BD71828_REG_IO_STAT),
 };
 
+static const struct regmap_range bd72720_volatile_ranges_4b[] = {
+	regmap_reg_range(BD72720_REG_RESETSRC_1, BD72720_REG_RESETSRC_2),
+	regmap_reg_range(BD72720_REG_POWER_STATE, BD72720_REG_POWER_STATE),
+	/* The state indicator bit changes when new state is reached */
+	regmap_reg_range(BD72720_REG_PS_CTRL_1, BD72720_REG_PS_CTRL_1),
+	regmap_reg_range(BD72720_REG_RCVNUM, BD72720_REG_RCVNUM),
+	regmap_reg_range(BD72720_REG_CONF, BD72720_REG_HALL_STAT),
+	regmap_reg_range(BD72720_REG_RTC_SEC, BD72720_REG_RTC_YEAR),
+	regmap_reg_range(BD72720_REG_INT_LVL1_STAT, BD72720_REG_INT_ETC2_SRC),
+};
+
+static const struct regmap_range bd72720_precious_ranges_4b[] = {
+	regmap_reg_range(BD72720_REG_INT_LVL1_STAT, BD72720_REG_INT_ETC2_STAT),
+};
+
+/*
+ * The BD72720 is an odd beast in that it contains two separate sets of
+ * registers, both starting from address 0x0. The twist is that these "pages"
+ * are behind different I2C slave addresses. Most of the registers are behind
+ * a slave address 0x4b, which will be used as the "main" address for this
+ * device.
+ * Most of the charger related registers are located behind slave address 0x4c.
+ * It is tempting to push the dealing with the charger registers and the extra
+ * 0x4c device in power-supply driver - but perhaps it's better for the sake of
+ * the cleaner re-use to deal with setting up all of the regmaps here.
+ * Furthermore, the LED stuff may need access to both of these devices.
+ *
+ * Instead of providing one of the regmaps to sub-devices in MFD platform data,
+ * we create one more 'wrapper regmap' with custom read/write operations. These
+ * custom accessors will select which of the 'real' regmaps to use, based on
+ * the register address.
+ * The register addresses are 8-bit, so we add offset 0x100 to the addresses
+ * behind the secondary slave 0x4c. The 'wrapper' regmap can then detect the
+ * correct slave address based on the register address and call regmap_write()
+ * and regmap_read() using correct 'real' regmap. This way the registers of
+ * both of the slaves can be accessed using one 'wrapper' regmap.
+ *
+ * NOTE: The added offsets mean that the defined addresses for slave 0x4c must
+ * be used through the 'wrapper' regmap because the offset must be stripped
+ * from the register addresses. The 0x4b can be accessed both indirectly using
+ * the 'wrapper' regmap, and directly using the 'real' regmap.
+ */
+#define BD72720_SECONDARY_I2C_SLAVE 0x4c
+
+struct bd72720_regmaps {
+	struct regmap *map1_4b;
+	struct regmap *map2_4c;
+};
+
+/* Translate the slave 0x4c wrapper register address to a real one */
+#define BD72720_REG_UNWRAP(reg) ((reg) - 0x100)
+
+/* Ranges given to 'real' 0x4c regmap must use unwrapped addresses. */
+#define BD72720_UNWRAP_REG_RANGE(startreg, endreg)					\
+	regmap_reg_range(BD72720_REG_UNWRAP(startreg), BD72720_REG_UNWRAP(endreg))
+static const struct regmap_range bd72720_volatile_ranges_4c[] = {
+	/* Status information */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_CHG_STATE, BD72720_REG_CHG_EN),
+	/*
+	 * Under certain circumstances, write to some bits may be
+	 * ignored
+	 */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_CHG_CTRL, BD72720_REG_CHG_CTRL),
+	/*
+	 * TODO: Ensure this is used to advertise state, not (only?) to
+	 * control it.
+	 */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_VSYS_STATE_STAT, BD72720_REG_VSYS_STATE_STAT),
+	/* Measured data */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_VM_VBAT_U, BD72720_REG_VM_VF_L),
+	/* Self clearing bits */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_VM_VSYS_SA_MINMAX_CTRL,
+				 BD72720_REG_VM_VSYS_SA_MINMAX_CTRL),
+	/* Counters, self clearing bits */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_CC_CURCD_U, BD72720_REG_CC_CTRL),
+	/* Self clearing bits */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_CC_CCNTD_CTRL, BD72720_REG_CC_CCNTD_CTRL),
+	/* Self clearing bits */
+	BD72720_UNWRAP_REG_RANGE(BD72720_REG_IMPCHK_CTRL, BD72720_REG_IMPCHK_CTRL),
+};
+
 static const struct regmap_access_table bd71815_volatile_regs = {
 	.yes_ranges = &bd71815_volatile_ranges[0],
 	.n_yes_ranges = ARRAY_SIZE(bd71815_volatile_ranges),
@@ -190,6 +362,21 @@ static const struct regmap_access_table bd71828_volatile_regs = {
 	.n_yes_ranges = ARRAY_SIZE(bd71828_volatile_ranges),
 };
 
+static const struct regmap_access_table bd72720_volatile_regs_4b = {
+	.yes_ranges = &bd72720_volatile_ranges_4b[0],
+	.n_yes_ranges = ARRAY_SIZE(bd72720_volatile_ranges_4b),
+};
+
+static const struct regmap_access_table bd72720_precious_regs_4b = {
+	.yes_ranges = &bd72720_precious_ranges_4b[0],
+	.n_yes_ranges = ARRAY_SIZE(bd72720_precious_ranges_4b),
+};
+
+static const struct regmap_access_table bd72720_volatile_regs_4c = {
+	.yes_ranges = &bd72720_volatile_ranges_4c[0],
+	.n_yes_ranges = ARRAY_SIZE(bd72720_volatile_ranges_4c),
+};
+
 static const struct regmap_config bd71815_regmap = {
 	.reg_bits = 8,
 	.val_bits = 8,
@@ -206,10 +393,79 @@ static const struct regmap_config bd71828_regmap = {
 	.cache_type = REGCACHE_MAPLE,
 };
 
+static int regmap_write_wrapper(void *context, unsigned int reg, unsigned int val)
+{
+	struct bd72720_regmaps *maps = context;
+
+	if (reg < 0x100)
+		return regmap_write(maps->map1_4b, reg, val);
+
+	reg = BD72720_REG_UNWRAP(reg);
+
+	return regmap_write(maps->map2_4c, reg, val);
+}
+
+static int regmap_read_wrapper(void *context, unsigned int reg, unsigned int *val)
+{
+	struct bd72720_regmaps *maps = context;
+
+	if (reg < 0x100)
+		return regmap_read(maps->map1_4b, reg, val);
+
+	reg = BD72720_REG_UNWRAP(reg);
+
+	return regmap_read(maps->map2_4c, reg, val);
+}
+
+static const struct regmap_config bd72720_wrapper_map_config = {
+	.name = "wrap-map",
+	.reg_bits = 9,
+	.val_bits = 8,
+	.max_register = BD72720_REG_IMPCHK_CTRL,
+	/*
+	 * We don't want to duplicate caches. It would be a bit faster to
+	 * have the cache in this 'wrapper regmap', and not in the 'real
+	 * regmaps' bd72720_regmap_4b and bd72720_regmap_4c below. This would
+	 * require all the subdevices to use the wrapper-map in order to be
+	 * able to benefit from the cache.
+	 * Currently most of the sub-devices use only the same slave-address
+	 * as this MFD driver. Now, because we don't add the offset to the
+	 * registers belonging to this slave, those devices can use either the
+	 * wrapper map, or the bd72720_regmap_4b directly. This means majority
+	 * of our sub devices don't need to care which regmap they get using
+	 * the dev_get_regmap(). This unifies the code between the BD72720 and
+	 * those variants which don't have this 'multiple slave addresses'
+	 * -hassle.
+	 * So, for a small performance penalty, we simplify the code for the
+	 * sub-devices by having the caches in the wrapped regmaps and not here.
+	 */
+	.cache_type = REGCACHE_NONE,
+	.reg_write = regmap_write_wrapper,
+	.reg_read = regmap_read_wrapper,
+};
+
+static const struct regmap_config bd72720_regmap_4b = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.volatile_table = &bd72720_volatile_regs_4b,
+	.precious_table = &bd72720_precious_regs_4b,
+	.max_register = BD72720_REG_INT_ETC2_SRC,
+	.cache_type = REGCACHE_MAPLE,
+};
+
+static const struct regmap_config bd72720_regmap_4c = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.volatile_table = &bd72720_volatile_regs_4c,
+	.max_register = BD72720_REG_UNWRAP(BD72720_REG_IMPCHK_CTRL),
+	.cache_type = REGCACHE_MAPLE,
+};
+
 /*
  * Mapping of main IRQ register bits to sub-IRQ register offsets so that we can
  * access corect sub-IRQ registers based on bits that are set in main IRQ
- * register. BD71815 and BD71828 have same sub-register-block offests.
+ * register. BD71815 and BD71828 have same sub-register-block offests, the
+ * BD72720 has a different one.
  */
 
 static unsigned int bit0_offsets[] = {11};		/* RTC IRQ */
@@ -221,6 +477,15 @@ static unsigned int bit5_offsets[] = {3};		/* VSYS IRQ */
 static unsigned int bit6_offsets[] = {1, 2};		/* DCIN IRQ */
 static unsigned int bit7_offsets[] = {0};		/* BUCK IRQ */
 
+static unsigned int bd72720_bit0_offsets[] = {0, 1};	/* PS1 and PS2 */
+static unsigned int bd72720_bit1_offsets[] = {2, 3};	/* DVS1 and DVS2 */
+static unsigned int bd72720_bit2_offsets[] = {4};	/* VBUS */
+static unsigned int bd72720_bit3_offsets[] = {5};	/* VSYS */
+static unsigned int bd72720_bit4_offsets[] = {6};	/* CHG */
+static unsigned int bd72720_bit5_offsets[] = {7, 8};	/* BAT1 and BAT2 */
+static unsigned int bd72720_bit6_offsets[] = {9};	/* IBAT */
+static unsigned int bd72720_bit7_offsets[] = {10, 11};	/* ETC1 and ETC2 */
+
 static const struct regmap_irq_sub_irq_map bd718xx_sub_irq_offsets[] = {
 	REGMAP_IRQ_MAIN_REG_OFFSET(bit0_offsets),
 	REGMAP_IRQ_MAIN_REG_OFFSET(bit1_offsets),
@@ -232,6 +497,17 @@ static const struct regmap_irq_sub_irq_map bd718xx_sub_irq_offsets[] = {
 	REGMAP_IRQ_MAIN_REG_OFFSET(bit7_offsets),
 };
 
+static const struct regmap_irq_sub_irq_map bd72720_sub_irq_offsets[] = {
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit0_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit1_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit2_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit3_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit4_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit5_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit6_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bd72720_bit7_offsets),
+};
+
 static const struct regmap_irq bd71815_irqs[] = {
 	REGMAP_IRQ_REG(BD71815_INT_BUCK1_OCP, 0, BD71815_INT_BUCK1_OCP_MASK),
 	REGMAP_IRQ_REG(BD71815_INT_BUCK2_OCP, 0, BD71815_INT_BUCK2_OCP_MASK),
@@ -405,6 +681,117 @@ static const struct regmap_irq bd71828_irqs[] = {
 	REGMAP_IRQ_REG(BD71828_INT_RTC2, 11, BD71828_INT_RTC2_MASK),
 };
 
+static const struct regmap_irq bd72720_irqs[] = {
+	REGMAP_IRQ_REG(BD72720_INT_LONGPUSH, 0, BD72720_INT_LONGPUSH_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_MIDPUSH, 0, BD72720_INT_MIDPUSH_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_SHORTPUSH, 0, BD72720_INT_SHORTPUSH_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_PUSH, 0, BD72720_INT_PUSH_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_HALL_DET, 0, BD72720_INT_HALL_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_HALL_TGL, 0, BD72720_INT_HALL_TGL_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_WDOG, 0, BD72720_INT_WDOG_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_SWRESET, 0, BD72720_INT_SWRESET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_SEQ_DONE, 1, BD72720_INT_SEQ_DONE_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_PGFAULT, 1, BD72720_INT_PGFAULT_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK1_DVS, 2, BD72720_INT_BUCK1_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK2_DVS, 2, BD72720_INT_BUCK2_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK3_DVS, 2, BD72720_INT_BUCK3_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK4_DVS, 2, BD72720_INT_BUCK4_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK5_DVS, 2, BD72720_INT_BUCK5_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK6_DVS, 2, BD72720_INT_BUCK6_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK7_DVS, 2, BD72720_INT_BUCK7_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK8_DVS, 2, BD72720_INT_BUCK8_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK9_DVS, 3, BD72720_INT_BUCK9_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BUCK10_DVS, 3, BD72720_INT_BUCK10_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_LDO1_DVS, 3, BD72720_INT_LDO1_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_LDO2_DVS, 3, BD72720_INT_LDO2_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_LDO3_DVS, 3, BD72720_INT_LDO3_DVS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_LDO4_DVS, 3, BD72720_INT_LDO4_DVS_MASK),
+
+	REGMAP_IRQ_REG(BD72720_INT_VBUS_RMV, 4, BD72720_INT_VBUS_RMV_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBUS_DET, 4, BD72720_INT_VBUS_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBUS_MON_RES, 4, BD72720_INT_VBUS_MON_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBUS_MON_DET, 4, BD72720_INT_VBUS_MON_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_MON_RES, 5, BD72720_INT_VSYS_MON_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_MON_DET, 5, BD72720_INT_VSYS_MON_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_UV_RES, 5, BD72720_INT_VSYS_UV_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_UV_DET, 5, BD72720_INT_VSYS_UV_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_LO_RES, 5, BD72720_INT_VSYS_LO_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_LO_DET, 5, BD72720_INT_VSYS_LO_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_OV_RES, 5, BD72720_INT_VSYS_OV_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VSYS_OV_DET, 5, BD72720_INT_VSYS_OV_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BAT_ILIM, 6, BD72720_INT_BAT_ILIM_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_CHG_DONE, 6, BD72720_INT_CHG_DONE_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_EXTEMP_TOUT, 6, BD72720_INT_EXTEMP_TOUT_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_CHG_WDT_EXP, 6, BD72720_INT_CHG_WDT_EXP_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BAT_MNT_OUT, 6, BD72720_INT_BAT_MNT_OUT_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BAT_MNT_IN, 6, BD72720_INT_BAT_MNT_IN_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_CHG_TRNS, 6, BD72720_INT_CHG_TRNS_MASK),
+
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_MON_RES, 7, BD72720_INT_VBAT_MON_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_MON_DET, 7, BD72720_INT_VBAT_MON_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_SHT_RES, 7, BD72720_INT_VBAT_SHT_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_SHT_DET, 7, BD72720_INT_VBAT_SHT_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_LO_RES, 7, BD72720_INT_VBAT_LO_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_LO_DET, 7, BD72720_INT_VBAT_LO_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_OV_RES, 7, BD72720_INT_VBAT_OV_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VBAT_OV_DET, 7, BD72720_INT_VBAT_OV_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BAT_RMV, 8, BD72720_INT_BAT_RMV_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BAT_DET, 8, BD72720_INT_BAT_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_DBAT_DET, 8, BD72720_INT_DBAT_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_BAT_TEMP_TRNS, 8, BD72720_INT_BAT_TEMP_TRNS_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_LOBTMP_RES, 8, BD72720_INT_LOBTMP_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_LOBTMP_DET, 8, BD72720_INT_LOBTMP_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OVBTMP_RES, 8, BD72720_INT_OVBTMP_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OVBTMP_DET, 8, BD72720_INT_OVBTMP_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OCUR1_RES, 9, BD72720_INT_OCUR1_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OCUR1_DET, 9, BD72720_INT_OCUR1_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OCUR2_RES, 9, BD72720_INT_OCUR2_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OCUR2_DET, 9, BD72720_INT_OCUR2_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OCUR3_RES, 9, BD72720_INT_OCUR3_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_OCUR3_DET, 9, BD72720_INT_OCUR3_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_CC_MON1_DET, 10, BD72720_INT_CC_MON1_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_CC_MON2_DET, 10, BD72720_INT_CC_MON2_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_CC_MON3_DET, 10, BD72720_INT_CC_MON3_DET_MASK),
+/*
+ * The GPIO1_IN and GPIO2_IN IRQs are generated from the PMIC's GPIO1 and GPIO2
+ * pins. Eg, they may be wired to other devices which can then use the PMIC as
+ * an interrupt controller. The GPIO1 and GPIO2 can have the IRQ type
+ * specified. All of the types (falling, rising, and both edges as well as low
+ * and high levels) are supported.
+ */
+	BD72720_TYPED_IRQ_REG(BD72720_INT_GPIO1_IN, 10, BD72720_INT_GPIO1_IN_MASK, 0),
+	BD72720_TYPED_IRQ_REG(BD72720_INT_GPIO2_IN, 10, BD72720_INT_GPIO2_IN_MASK, 1),
+	REGMAP_IRQ_REG(BD72720_INT_VF125_RES, 11, BD72720_INT_VF125_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VF125_DET, 11, BD72720_INT_VF125_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VF_RES, 11, BD72720_INT_VF_RES_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_VF_DET, 11, BD72720_INT_VF_DET_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_RTC0, 11, BD72720_INT_RTC0_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_RTC1, 11, BD72720_INT_RTC1_MASK),
+	REGMAP_IRQ_REG(BD72720_INT_RTC2, 11, BD72720_INT_RTC2_MASK),
+};
+
+static int bd72720_set_type_config(unsigned int **buf, unsigned int type,
+				   const struct regmap_irq *irq_data,
+				   int idx, void *irq_drv_data)
+{
+	const struct regmap_irq_type *t = &irq_data->type;
+
+	/*
+	 * The regmap IRQ ecpects IRQ_TYPE_EDGE_BOTH to be written to register
+	 * as logical OR of the type_falling_val and type_rising_val. This is
+	 * not how the BD72720 implements this configuration, hence we need
+	 * to handle this specific case separately.
+	 */
+	if (type == IRQ_TYPE_EDGE_BOTH) {
+		buf[0][idx] &= ~t->type_reg_mask;
+		buf[0][idx] |= BD72720_GPIO_IRQ_TYPE_BOTH;
+
+		return 0;
+	}
+
+	return regmap_irq_set_type_config_simple(buf, type, irq_data, idx, irq_drv_data);
+}
+
 static const struct regmap_irq_chip bd71828_irq_chip = {
 	.name = "bd71828_irq",
 	.main_status = BD71828_REG_INT_MAIN,
@@ -437,6 +824,28 @@ static const struct regmap_irq_chip bd71815_irq_chip = {
 	.irq_reg_stride = 1,
 };
 
+static const unsigned int bd72720_irq_type_base[] = {BD72720_REG_GPIO1_CTRL};
+
+static const struct regmap_irq_chip bd72720_irq_chip = {
+	.name = "bd72720_irq",
+	.main_status = BD72720_REG_INT_LVL1_STAT,
+	.irqs = &bd72720_irqs[0],
+	.num_irqs = ARRAY_SIZE(bd72720_irqs),
+	.status_base = BD72720_REG_INT_PS1_STAT,
+	.unmask_base = BD72720_REG_INT_PS1_EN,
+	.config_base = &bd72720_irq_type_base[0],
+	.num_config_bases = 1,
+	.num_config_regs = 2,
+	.set_type_config = bd72720_set_type_config,
+	.ack_base = BD72720_REG_INT_PS1_STAT,
+	.init_ack_masked = true,
+	.num_regs = 12,
+	.num_main_regs = 1,
+	.sub_reg_offsets = &bd72720_sub_irq_offsets[0],
+	.num_main_status_bits = 8,
+	.irq_reg_stride = 1,
+};
+
 static int set_clk_mode(struct device *dev, struct regmap *regmap,
 			int clkmode_reg)
 {
@@ -483,11 +892,40 @@ static void bd71828_remove_poweroff(void *data)
 	pm_power_off = NULL;
 }
 
+static struct regmap *bd72720_do_regmaps(struct i2c_client *i2c)
+{
+	struct bd72720_regmaps *maps;
+	struct i2c_client *secondary_i2c;
+
+	secondary_i2c = devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter,
+						  BD72720_SECONDARY_I2C_SLAVE);
+	if (IS_ERR(secondary_i2c)) {
+		dev_err_probe(&i2c->dev, PTR_ERR(secondary_i2c),
+			      "Failed to get secondary I2C\n");
+
+		return (struct regmap *)secondary_i2c;
+	}
+
+	maps = devm_kzalloc(&i2c->dev, sizeof(*maps), GFP_KERNEL);
+	if (!maps)
+		return ERR_PTR(-ENOMEM);
+
+	maps->map1_4b = devm_regmap_init_i2c(i2c, &bd72720_regmap_4b);
+	if (IS_ERR(maps->map1_4b))
+		return maps->map1_4b;
+
+	maps->map2_4c = devm_regmap_init_i2c(secondary_i2c, &bd72720_regmap_4c);
+	if (IS_ERR(maps->map2_4c))
+		return maps->map2_4c;
+
+	return devm_regmap_init(&i2c->dev, NULL, maps, &bd72720_wrapper_map_config);
+}
+
 static int bd71828_i2c_probe(struct i2c_client *i2c)
 {
 	struct regmap_irq_chip_data *irq_data;
 	int ret;
-	struct regmap *regmap;
+	struct regmap *regmap = NULL;
 	const struct regmap_config *regmap_config;
 	const struct regmap_irq_chip *irqchip;
 	unsigned int chip_type;
@@ -495,6 +933,7 @@ static int bd71828_i2c_probe(struct i2c_client *i2c)
 	int cells;
 	int button_irq;
 	int clkmode_reg;
+	int main_lvl_mask_reg = 0, main_lvl_val = 0;
 
 	if (!i2c->irq) {
 		dev_err(&i2c->dev, "No IRQ configured\n");
@@ -526,16 +965,34 @@ static int bd71828_i2c_probe(struct i2c_client *i2c)
 		 */
 		button_irq = 0;
 		break;
+	case ROHM_CHIP_TYPE_BD72720:
+	{
+		mfd = bd72720_mfd_cells;
+		cells = ARRAY_SIZE(bd72720_mfd_cells);
+
+		regmap = bd72720_do_regmaps(i2c);
+		if (IS_ERR(regmap))
+			return dev_err_probe(&i2c->dev, PTR_ERR(regmap),
+				     "Failed to initialize Regmap\n");
+
+		irqchip = &bd72720_irq_chip;
+		clkmode_reg = BD72720_REG_OUT32K;
+		button_irq = BD72720_INT_SHORTPUSH;
+		main_lvl_mask_reg = BD72720_REG_INT_LVL1_EN;
+		main_lvl_val = BD72720_MASK_LVL1_EN_ALL;
+		break;
+	}
 	default:
 		dev_err(&i2c->dev, "Unknown device type");
 		return -EINVAL;
 	}
 
-	regmap = devm_regmap_init_i2c(i2c, regmap_config);
-	if (IS_ERR(regmap))
-		return dev_err_probe(&i2c->dev, PTR_ERR(regmap),
+	if (!regmap) {
+		regmap = devm_regmap_init_i2c(i2c, regmap_config);
+		if (IS_ERR(regmap))
+			return dev_err_probe(&i2c->dev, PTR_ERR(regmap),
 				     "Failed to initialize Regmap\n");
-
+	}
 	ret = devm_regmap_add_irq_chip(&i2c->dev, regmap, i2c->irq,
 				       IRQF_ONESHOT, 0, irqchip, &irq_data);
 	if (ret)
@@ -545,6 +1002,20 @@ static int bd71828_i2c_probe(struct i2c_client *i2c)
 	dev_dbg(&i2c->dev, "Registered %d IRQs for chip\n",
 		irqchip->num_irqs);
 
+	/*
+	 * On some ICs the main IRQ register has corresponding mask register.
+	 * This is not handled by the regmap IRQ. Let's enable all the main
+	 * level IRQs here. Further writes to the main level MASK is not
+	 * needed because masking is handled by the per IRQ 2.nd level MASK
+	 * registers. 2.nd level masks are handled by the regmap IRQ.
+	 */
+	if (main_lvl_mask_reg) {
+		ret = regmap_write(regmap, main_lvl_mask_reg, main_lvl_val);
+		if (ret) {
+			return dev_err_probe(&i2c->dev, ret,
+					"Failed to enable main level IRQs\n");
+		}
+	}
 	if (button_irq) {
 		ret = regmap_irq_get_virq(irq_data, button_irq);
 		if (ret < 0)
@@ -586,6 +1057,9 @@ static const struct of_device_id bd71828_of_match[] = {
 	}, {
 		.compatible = "rohm,bd71815",
 		.data = (void *)ROHM_CHIP_TYPE_BD71815,
+	}, {
+		.compatible = "rohm,bd72720",
+		.data = (void *)ROHM_CHIP_TYPE_BD72720,
 	 },
 	{ },
 };
diff --git a/include/linux/mfd/rohm-bd72720.h b/include/linux/mfd/rohm-bd72720.h
new file mode 100644
index 000000000000..42fcf8f81b2f
--- /dev/null
+++ b/include/linux/mfd/rohm-bd72720.h
@@ -0,0 +1,634 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright 2024 ROHM Semiconductors.
+ *
+ * Author: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ */
+
+#ifndef _MFD_BD72720_H
+#define _MFD_BD72720_H
+
+#include <linux/regmap.h>
+
+enum {
+	BD72720_BUCK1,
+	BD72720_BUCK2,
+	BD72720_BUCK3,
+	BD72720_BUCK4,
+	BD72720_BUCK5,
+	BD72720_BUCK6,
+	BD72720_BUCK7,
+	BD72720_BUCK8,
+	BD72720_BUCK9,
+	BD72720_BUCK10,
+	BD72720_BUCK11,
+	BD72720_LDO1,
+	BD72720_LDO2,
+	BD72720_LDO3,
+	BD72720_LDO4,
+	BD72720_LDO5,
+	BD72720_LDO6,
+	BD72720_LDO7,
+	BD72720_LDO8,
+	BD72720_LDO9,
+	BD72720_LDO10,
+	BD72720_LDO11,
+	BD72720_REGULATOR_AMOUNT,
+};
+
+/* BD72720 interrupts */
+#define BD72720_INT_LONGPUSH_MASK	BIT(0)
+#define BD72720_INT_MIDPUSH_MASK	BIT(1)
+#define BD72720_INT_SHORTPUSH_MASK	BIT(2)
+#define BD72720_INT_PUSH_MASK		BIT(3)
+#define BD72720_INT_HALL_DET_MASK	BIT(4)
+#define BD72720_INT_HALL_TGL_MASK	BIT(5)
+#define BD72720_INT_WDOG_MASK		BIT(6)
+#define BD72720_INT_SWRESET_MASK	BIT(7)
+#define BD72720_INT_SEQ_DONE_MASK	BIT(0)
+#define BD72720_INT_PGFAULT_MASK	BIT(4)
+#define BD72720_INT_BUCK1_DVS_MASK	BIT(0)
+#define BD72720_INT_BUCK2_DVS_MASK	BIT(1)
+#define BD72720_INT_BUCK3_DVS_MASK	BIT(2)
+#define BD72720_INT_BUCK4_DVS_MASK	BIT(3)
+#define BD72720_INT_BUCK5_DVS_MASK	BIT(4)
+#define BD72720_INT_BUCK6_DVS_MASK	BIT(5)
+#define BD72720_INT_BUCK7_DVS_MASK	BIT(6)
+#define BD72720_INT_BUCK8_DVS_MASK	BIT(7)
+#define BD72720_INT_BUCK9_DVS_MASK	BIT(0)
+#define BD72720_INT_BUCK10_DVS_MASK	BIT(1)
+#define BD72720_INT_LDO1_DVS_MASK	BIT(4)
+#define BD72720_INT_LDO2_DVS_MASK	BIT(5)
+#define BD72720_INT_LDO3_DVS_MASK	BIT(6)
+#define BD72720_INT_LDO4_DVS_MASK	BIT(7)
+#define BD72720_INT_VBUS_RMV_MASK	BIT(0)
+#define BD72720_INT_VBUS_DET_MASK	BIT(1)
+#define BD72720_INT_VBUS_MON_RES_MASK	BIT(2)
+#define BD72720_INT_VBUS_MON_DET_MASK	BIT(3)
+#define BD72720_INT_VSYS_MON_RES_MASK	BIT(0)
+#define BD72720_INT_VSYS_MON_DET_MASK	BIT(1)
+#define BD72720_INT_VSYS_UV_RES_MASK	BIT(2)
+#define BD72720_INT_VSYS_UV_DET_MASK	BIT(3)
+#define BD72720_INT_VSYS_LO_RES_MASK	BIT(4)
+#define BD72720_INT_VSYS_LO_DET_MASK	BIT(5)
+#define BD72720_INT_VSYS_OV_RES_MASK	BIT(6)
+#define BD72720_INT_VSYS_OV_DET_MASK	BIT(7)
+#define BD72720_INT_BAT_ILIM_MASK	BIT(0)
+#define BD72720_INT_CHG_DONE_MASK	BIT(1)
+#define BD72720_INT_EXTEMP_TOUT_MASK	BIT(2)
+#define BD72720_INT_CHG_WDT_EXP_MASK	BIT(3)
+#define BD72720_INT_BAT_MNT_OUT_MASK	BIT(4)
+#define BD72720_INT_BAT_MNT_IN_MASK	BIT(5)
+#define BD72720_INT_CHG_TRNS_MASK	BIT(7)
+#define BD72720_INT_VBAT_MON_RES_MASK	BIT(0)
+#define BD72720_INT_VBAT_MON_DET_MASK	BIT(1)
+#define BD72720_INT_VBAT_SHT_RES_MASK	BIT(2)
+#define BD72720_INT_VBAT_SHT_DET_MASK	BIT(3)
+#define BD72720_INT_VBAT_LO_RES_MASK	BIT(4)
+#define BD72720_INT_VBAT_LO_DET_MASK	BIT(5)
+#define BD72720_INT_VBAT_OV_RES_MASK	BIT(6)
+#define BD72720_INT_VBAT_OV_DET_MASK	BIT(7)
+#define BD72720_INT_BAT_RMV_MASK	BIT(0)
+#define BD72720_INT_BAT_DET_MASK	BIT(1)
+#define BD72720_INT_DBAT_DET_MASK	BIT(2)
+#define BD72720_INT_BAT_TEMP_TRNS_MASK	BIT(3)
+#define BD72720_INT_LOBTMP_RES_MASK	BIT(4)
+#define BD72720_INT_LOBTMP_DET_MASK	BIT(5)
+#define BD72720_INT_OVBTMP_RES_MASK	BIT(6)
+#define BD72720_INT_OVBTMP_DET_MASK	BIT(7)
+#define BD72720_INT_OCUR1_RES_MASK	BIT(0)
+#define BD72720_INT_OCUR1_DET_MASK	BIT(1)
+#define BD72720_INT_OCUR2_RES_MASK	BIT(2)
+#define BD72720_INT_OCUR2_DET_MASK	BIT(3)
+#define BD72720_INT_OCUR3_RES_MASK	BIT(4)
+#define BD72720_INT_OCUR3_DET_MASK	BIT(5)
+#define BD72720_INT_CC_MON1_DET_MASK	BIT(0)
+#define BD72720_INT_CC_MON2_DET_MASK	BIT(1)
+#define BD72720_INT_CC_MON3_DET_MASK	BIT(2)
+#define BD72720_INT_GPIO1_IN_MASK	BIT(4)
+#define BD72720_INT_GPIO2_IN_MASK	BIT(5)
+#define BD72720_INT_VF125_RES_MASK	BIT(0)
+#define BD72720_INT_VF125_DET_MASK	BIT(1)
+#define BD72720_INT_VF_RES_MASK		BIT(2)
+#define BD72720_INT_VF_DET_MASK		BIT(3)
+#define BD72720_INT_RTC0_MASK		BIT(4)
+#define BD72720_INT_RTC1_MASK		BIT(5)
+#define BD72720_INT_RTC2_MASK		BIT(6)
+
+enum {
+	/*
+	 * The IRQs excluding GPIO1 and GPIO2 are ordered in a same way as the
+	 * respective IRQ bits in status and mask registers are ordered.
+	 *
+	 * The BD72720_INT_GPIO1_IN and BD72720_INT_GPIO2_IN are IRQs which can
+	 * be used by other devices. Let's have  GPIO1 and GPIO2 as first IRQs
+	 * here so we can use the regmap-IRQ with standard device tree xlate
+	 * while devices connected to the BD72720 IRQ input pins can refer to
+	 * the first two interrupt numbers in their device tree. If we placed
+	 * BD72720_INT_GPIO1_IN and BD72720_INT_GPIO2_IN after the CC_MON_DET
+	 * interrupts (like they are in the registers), the devices using
+	 * BD72720 as an IRQ parent should refer the interrupts starting with
+	 * an offset which might not be trivial to understand.
+	 */
+	BD72720_INT_GPIO1_IN,
+	BD72720_INT_GPIO2_IN,
+	BD72720_INT_LONGPUSH,
+	BD72720_INT_MIDPUSH,
+	BD72720_INT_SHORTPUSH,
+	BD72720_INT_PUSH,
+	BD72720_INT_HALL_DET,
+	BD72720_INT_HALL_TGL,
+	BD72720_INT_WDOG,
+	BD72720_INT_SWRESET,
+	BD72720_INT_SEQ_DONE,
+	BD72720_INT_PGFAULT,
+	BD72720_INT_BUCK1_DVS,
+	BD72720_INT_BUCK2_DVS,
+	BD72720_INT_BUCK3_DVS,
+	BD72720_INT_BUCK4_DVS,
+	BD72720_INT_BUCK5_DVS,
+	BD72720_INT_BUCK6_DVS,
+	BD72720_INT_BUCK7_DVS,
+	BD72720_INT_BUCK8_DVS,
+	BD72720_INT_BUCK9_DVS,
+	BD72720_INT_BUCK10_DVS,
+	BD72720_INT_LDO1_DVS,
+	BD72720_INT_LDO2_DVS,
+	BD72720_INT_LDO3_DVS,
+	BD72720_INT_LDO4_DVS,
+	BD72720_INT_VBUS_RMV,
+	BD72720_INT_VBUS_DET,
+	BD72720_INT_VBUS_MON_RES,
+	BD72720_INT_VBUS_MON_DET,
+	BD72720_INT_VSYS_MON_RES,
+	BD72720_INT_VSYS_MON_DET,
+	BD72720_INT_VSYS_UV_RES,
+	BD72720_INT_VSYS_UV_DET,
+	BD72720_INT_VSYS_LO_RES,
+	BD72720_INT_VSYS_LO_DET,
+	BD72720_INT_VSYS_OV_RES,
+	BD72720_INT_VSYS_OV_DET,
+	BD72720_INT_BAT_ILIM,
+	BD72720_INT_CHG_DONE,
+	BD72720_INT_EXTEMP_TOUT,
+	BD72720_INT_CHG_WDT_EXP,
+	BD72720_INT_BAT_MNT_OUT,
+	BD72720_INT_BAT_MNT_IN,
+	BD72720_INT_CHG_TRNS,
+	BD72720_INT_VBAT_MON_RES,
+	BD72720_INT_VBAT_MON_DET,
+	BD72720_INT_VBAT_SHT_RES,
+	BD72720_INT_VBAT_SHT_DET,
+	BD72720_INT_VBAT_LO_RES,
+	BD72720_INT_VBAT_LO_DET,
+	BD72720_INT_VBAT_OV_RES,
+	BD72720_INT_VBAT_OV_DET,
+	BD72720_INT_BAT_RMV,
+	BD72720_INT_BAT_DET,
+	BD72720_INT_DBAT_DET,
+	BD72720_INT_BAT_TEMP_TRNS,
+	BD72720_INT_LOBTMP_RES,
+	BD72720_INT_LOBTMP_DET,
+	BD72720_INT_OVBTMP_RES,
+	BD72720_INT_OVBTMP_DET,
+	BD72720_INT_OCUR1_RES,
+	BD72720_INT_OCUR1_DET,
+	BD72720_INT_OCUR2_RES,
+	BD72720_INT_OCUR2_DET,
+	BD72720_INT_OCUR3_RES,
+	BD72720_INT_OCUR3_DET,
+	BD72720_INT_CC_MON1_DET,
+	BD72720_INT_CC_MON2_DET,
+	BD72720_INT_CC_MON3_DET,
+	BD72720_INT_VF125_RES,
+	BD72720_INT_VF125_DET,
+	BD72720_INT_VF_RES,
+	BD72720_INT_VF_DET,
+	BD72720_INT_RTC0,
+	BD72720_INT_RTC1,
+	BD72720_INT_RTC2,
+};
+
+/*
+ * BD72720 Registers:
+ * The BD72720 has two sets of registers behind two different I2C slave
+ * addresses. "Common" registers being behind 0x4b, the charger registers
+ * being behind 0x4c.
+ */
+/* Registers behind I2C slave 0x4b */
+enum {
+	BD72720_REG_PRODUCT_ID,
+	BD72720_REG_MANUFACTURER_ID,
+	BD72720_REG_PMIC_REV_NUM,
+	BD72720_REG_NVM_REV_NUM,
+	BD72720_REG_BOOTSRC		= 0x10,
+	BD72720_REG_RESETSRC_1,
+	BD72720_REG_RESETSRC_2,
+	BD72720_REG_RESETSRC_3,
+	BD72720_REG_RESETSRC_4,
+	BD72720_REG_RESETSRC_5,
+	BD72720_REG_RESETSRC_6,
+	BD72720_REG_RESETSRC_7,
+	BD72720_REG_POWER_STATE,
+	BD72720_REG_PS_CFG,
+	BD72720_REG_PS_CTRL_1,
+	BD72720_REG_PS_CTRL_2,
+	BD72720_REG_RCVCFG,
+	BD72720_REG_RCVNUM,
+	BD72720_REG_CRDCFG,
+	BD72720_REG_REX_CTRL,
+
+	BD72720_REG_BUCK1_ON,
+	BD72720_REG_BUCK1_MODE,
+	/* Deep idle vsel */
+	BD72720_REG_BUCK1_VSEL_DI,
+	/* Idle vsel */
+	BD72720_REG_BUCK1_VSEL_I,
+	/* Suspend vsel */
+	BD72720_REG_BUCK1_VSEL_S,
+	/* Run boot vsel */
+	BD72720_REG_BUCK1_VSEL_RB,
+	/* Run0 ... run3 vsel */
+	BD72720_REG_BUCK1_VSEL_RB0,
+	BD72720_REG_BUCK1_VSEL_RB1,
+	BD72720_REG_BUCK1_VSEL_RB2,
+	BD72720_REG_BUCK1_VSEL_RB3,
+
+	BD72720_REG_BUCK2_ON,
+	BD72720_REG_BUCK2_MODE,
+	BD72720_REG_BUCK2_VSEL_DI,
+	BD72720_REG_BUCK2_VSEL_I,
+	BD72720_REG_BUCK2_VSEL_S,
+	/* Run vsel */
+	BD72720_REG_BUCK2_VSEL_R,
+
+	BD72720_REG_BUCK3_ON,
+	BD72720_REG_BUCK3_MODE,
+	BD72720_REG_BUCK3_VSEL_DI,
+	BD72720_REG_BUCK3_VSEL_I,
+	BD72720_REG_BUCK3_VSEL_S,
+	BD72720_REG_BUCK3_VSEL_R,
+
+	BD72720_REG_BUCK4_ON,
+	BD72720_REG_BUCK4_MODE,
+	BD72720_REG_BUCK4_VSEL_DI,
+	BD72720_REG_BUCK4_VSEL_I,
+	BD72720_REG_BUCK4_VSEL_S,
+	BD72720_REG_BUCK4_VSEL_R,
+
+	BD72720_REG_BUCK5_ON,
+	BD72720_REG_BUCK5_MODE,
+	BD72720_REG_BUCK5_VSEL,
+
+	BD72720_REG_BUCK6_ON,
+	BD72720_REG_BUCK6_MODE,
+	BD72720_REG_BUCK6_VSEL,
+
+	BD72720_REG_BUCK7_ON,
+	BD72720_REG_BUCK7_MODE,
+	BD72720_REG_BUCK7_VSEL,
+
+	BD72720_REG_BUCK8_ON,
+	BD72720_REG_BUCK8_MODE,
+	BD72720_REG_BUCK8_VSEL,
+
+	BD72720_REG_BUCK9_ON,
+	BD72720_REG_BUCK9_MODE,
+	BD72720_REG_BUCK9_VSEL,
+
+	BD72720_REG_BUCK10_ON,
+	BD72720_REG_BUCK10_MODE,
+	BD72720_REG_BUCK10_VSEL,
+
+	BD72720_REG_LDO1_ON,
+	BD72720_REG_LDO1_MODE1,
+	BD72720_REG_LDO1_MODE2,
+	BD72720_REG_LDO1_VSEL_DI,
+	BD72720_REG_LDO1_VSEL_I,
+	BD72720_REG_LDO1_VSEL_S,
+	BD72720_REG_LDO1_VSEL_RB,
+	BD72720_REG_LDO1_VSEL_R0,
+	BD72720_REG_LDO1_VSEL_R1,
+	BD72720_REG_LDO1_VSEL_R2,
+	BD72720_REG_LDO1_VSEL_R3,
+
+	BD72720_REG_LDO2_ON,
+	BD72720_REG_LDO2_MODE,
+	BD72720_REG_LDO2_VSEL_DI,
+	BD72720_REG_LDO2_VSEL_I,
+	BD72720_REG_LDO2_VSEL_S,
+	BD72720_REG_LDO2_VSEL_R,
+
+	BD72720_REG_LDO3_ON,
+	BD72720_REG_LDO3_MODE,
+	BD72720_REG_LDO3_VSEL_DI,
+	BD72720_REG_LDO3_VSEL_I,
+	BD72720_REG_LDO3_VSEL_S,
+	BD72720_REG_LDO3_VSEL_R,
+
+	BD72720_REG_LDO4_ON,
+	BD72720_REG_LDO4_MODE,
+	BD72720_REG_LDO4_VSEL_DI,
+	BD72720_REG_LDO4_VSEL_I,
+	BD72720_REG_LDO4_VSEL_S,
+	BD72720_REG_LDO4_VSEL_R,
+
+	BD72720_REG_LDO5_ON,
+	BD72720_REG_LDO5_MODE,
+	BD72720_REG_LDO5_VSEL,
+
+	BD72720_REG_LDO6_ON,
+	BD72720_REG_LDO6_MODE,
+	BD72720_REG_LDO6_VSEL,
+
+	BD72720_REG_LDO7_ON,
+	BD72720_REG_LDO7_MODE,
+	BD72720_REG_LDO7_VSEL,
+
+	BD72720_REG_LDO8_ON,
+	BD72720_REG_LDO8_MODE,
+	BD72720_REG_LDO8_VSEL,
+
+	BD72720_REG_LDO9_ON,
+	BD72720_REG_LDO9_MODE,
+	BD72720_REG_LDO9_VSEL,
+
+	BD72720_REG_LDO10_ON,
+	BD72720_REG_LDO10_MODE,
+	BD72720_REG_LDO10_VSEL,
+
+	BD72720_REG_LDO11_ON,
+	BD72720_REG_LDO11_MODE,
+	BD72720_REG_LDO11_VSEL,
+
+	BD72720_REG_GPIO1_ON		= 0x8b,
+	BD72720_REG_GPIO2_ON,
+	BD72720_REG_GPIO3_ON,
+	BD72720_REG_GPIO4_ON,
+	BD72720_REG_GPIO5_ON,
+
+	BD72720_REG_GPIO1_CTRL,
+	BD72720_REG_GPIO2_CTRL,
+#define BD72720_GPIO_IRQ_TYPE_MASK	GENMASK(6, 4)
+#define BD72720_GPIO_IRQ_TYPE_FALLING	0x0
+#define BD72720_GPIO_IRQ_TYPE_RISING	0x1
+#define BD72720_GPIO_IRQ_TYPE_BOTH	0x2
+#define BD72720_GPIO_IRQ_TYPE_HIGH	0x3
+#define BD72720_GPIO_IRQ_TYPE_LOW	0x4
+	BD72720_REG_GPIO3_CTRL,
+	BD72720_REG_GPIO4_CTRL,
+	BD72720_REG_GPIO5_CTRL,
+#define BD72720_GPIO_DRIVE_MASK		BIT(1)
+#define BD72720_GPIO_HIGH		BIT(0)
+
+	BD72720_REG_EPDEN_CTRL,
+	BD72720_REG_GATECNT_CTRL,
+	BD72720_REG_LED_CTRL,
+
+	BD72720_REG_PWRON_CFG1,
+	BD72720_REG_PWRON_CFG2,
+
+	BD72720_REG_OUT32K,
+	BD72720_REG_CONF,
+	BD72720_REG_HALL_STAT,
+
+	BD72720_REG_RTC_SEC		= 0xa0,
+#define BD72720_REG_RTC_START		BD72720_REG_RTC_SEC
+	BD72720_REG_RTC_MIN,
+	BD72720_REG_RTC_HOUR,
+	BD72720_REG_RTC_WEEK,
+	BD72720_REG_RTC_DAY,
+	BD72720_REG_RTC_MON,
+	BD72720_REG_RTC_YEAR,
+
+	BD72720_REG_RTC_ALM0_SEC,
+#define BD72720_REG_RTC_ALM_START	BD72720_REG_RTC_ALM0_SEC
+	BD72720_REG_RTC_ALM0_MIN,
+	BD72720_REG_RTC_ALM0_HOUR,
+	BD72720_REG_RTC_ALM0_WEEK,
+	BD72720_REG_RTC_ALM0_MON,
+	BD72720_REG_RTC_ALM0_YEAR,
+
+	BD72720_REG_RTC_ALM1_SEC,
+	BD72720_REG_RTC_ALM1_MIN,
+	BD72720_REG_RTC_ALM1_HOUR,
+	BD72720_REG_RTC_ALM1_WEEK,
+	BD72720_REG_RTC_ALM1_MON,
+	BD72720_REG_RTC_ALM1_YEAR,
+
+	BD72720_REG_RTC_ALM0_EN,
+	BD72720_REG_RTC_ALM1_EN,
+	BD72720_REG_RTC_ALM2,
+
+	BD72720_REG_INT_LVL1_EN		= 0xc0,
+#define BD72720_MASK_LVL1_EN_ALL	GENMASK(7, 0)
+	BD72720_REG_INT_PS1_EN,
+	BD72720_REG_INT_PS2_EN,
+	BD72720_REG_INT_DVS1_EN,
+	BD72720_REG_INT_DVS2_EN,
+	BD72720_REG_INT_VBUS_EN,
+	BD72720_REG_INT_VSYS_EN,
+	BD72720_REG_INT_CHG_EN,
+	BD72720_REG_INT_BAT1_EN,
+	BD72720_REG_INT_BAT2_EN,
+	BD72720_REG_INT_IBAT_EN,
+	BD72720_REG_INT_ETC1_EN,
+	BD72720_REG_INT_ETC2_EN,
+
+	/*
+	 * The _STAT registers inform IRQ line state, and are used to ack IRQ.
+	 * The _SRC registers below indicate current state of the function
+	 * connected to the line.
+	 */
+	BD72720_REG_INT_LVL1_STAT,
+	BD72720_REG_INT_PS1_STAT,
+	BD72720_REG_INT_PS2_STAT,
+	BD72720_REG_INT_DVS1_STAT,
+	BD72720_REG_INT_DVS2_STAT,
+	BD72720_REG_INT_VBUS_STAT,
+	BD72720_REG_INT_VSYS_STAT,
+	BD72720_REG_INT_CHG_STAT,
+	BD72720_REG_INT_BAT1_STAT,
+	BD72720_REG_INT_BAT2_STAT,
+	BD72720_REG_INT_IBAT_STAT,
+	BD72720_REG_INT_ETC1_STAT,
+	BD72720_REG_INT_ETC2_STAT,
+
+	BD72720_REG_INT_LVL1_SRC,
+	BD72720_REG_INT_PS1_SRC,
+	BD72720_REG_INT_PS2_SRC,
+	BD72720_REG_INT_DVS1_SRC,
+	BD72720_REG_INT_DVS2_SRC,
+	BD72720_REG_INT_VBUS_SRC,
+#define BD72720_MASK_DCIN_DET	BIT(1)
+	BD72720_REG_INT_VSYS_SRC,
+	BD72720_REG_INT_CHG_SRC,
+	BD72720_REG_INT_BAT1_SRC,
+	BD72720_REG_INT_BAT2_SRC,
+	BD72720_REG_INT_IBAT_SRC,
+	BD72720_REG_INT_ETC1_SRC,
+	BD72720_REG_INT_ETC2_SRC,
+};
+
+/* Register masks */
+#define BD72720_MASK_DEEP_IDLE_EN	BIT(0)
+#define BD72720_MASK_IDLE_EN		BIT(1)
+#define BD72720_MASK_SUSPEND_EN		BIT(2)
+#define BD72720_MASK_RUN_B_EN		BIT(3)
+#define BD72720_MASK_RUN_0_EN		BIT(4)
+#define BD72720_MASK_RUN_1_EN		BIT(5)
+#define BD72720_MASK_RUN_2_EN		BIT(6)
+#define BD72720_MASK_RUN_3_EN		BIT(7)
+
+#define BD72720_MASK_RAMP_UP_DELAY	GENMASK(7, 6)
+#define BD72720_MASK_BUCK_VSEL		GENMASK(7, 0)
+#define BD72720_MASK_LDO12346_VSEL	GENMASK(6, 0)
+#define BD72720_MASK_LDO_VSEL		GENMASK(7, 0)
+
+#define BD72720_I2C4C_ADDR_OFFSET	0x100
+
+/* Registers behind I2C slave 0x4c */
+enum {
+	BD72720_REG_CHG_STATE = BD72720_I2C4C_ADDR_OFFSET,
+	BD72720_REG_CHG_LAST_STATE,
+	BD72720_REG_CHG_VBUS_STAT,
+	BD72720_REG_CHG_VSYS_STAT,
+	BD72720_REG_CHG_BAT_TEMP_STAT,
+	BD72720_REG_CHG_WDT_STAT,
+	BD72720_REG_CHG_ILIM_STAT,
+	BD72720_REG_CHG_CHG_STAT,
+	BD72720_REG_CHG_EN,
+	BD72720_REG_CHG_INIT,
+	BD72720_REG_CHG_CTRL,
+	BD72720_REG_CHG_SET_1,
+	BD72720_REG_CHG_SET_2,
+	BD72720_REG_CHG_SET_3,
+	BD72720_REG_CHG_VPRE,
+	BD72720_REG_CHG_VBAT_1,
+	BD72720_REG_CHG_VBAT_2,
+	BD72720_REG_CHG_VBAT_3,
+	BD72720_REG_CHG_VBAT_4,
+	BD72720_REG_CHG_BAT_SET_1,
+	BD72720_REG_CHG_BAT_SET_2,
+	BD72720_REG_CHG_BAT_SET_3,
+	BD72720_REG_CHG_IPRE,
+	BD72720_REG_CHG_IFST_TERM,
+	BD72720_REG_CHG_VSYS_REG,
+	BD72720_REG_CHG_VBUS_SET,
+	BD72720_REG_CHG_WDT_PRE,
+	BD72720_REG_CHG_WDT_FST,
+	BD72720_REG_CHG_LED_CTRL,
+	BD72720_REG_CHG_CFG_1,
+	BD72720_REG_CHG_IFST_1,
+	BD72720_REG_CHG_IFST_2,
+	BD72720_REG_CHG_IFST_3,
+	BD72720_REG_CHG_IFST_4,
+	BD72720_REG_CHG_S_CFG_1,
+	BD72720_REG_CHG_S_CFG_2,
+	BD72720_REG_RS_VBUS,
+	BD72720_REG_RS_IBUS,
+	BD72720_REG_RS_VSYS,
+	BD72720_REG_VSYS_STATE_STAT,	/* 0x27 + offset*/
+
+	BD72720_REG_VM_VBAT_U		= BD72720_I2C4C_ADDR_OFFSET + 0x30,
+	BD72720_REG_VM_VBAT_L,
+	BD72720_REG_VM_OCV_PRE_U,
+	BD72720_REG_VM_OCV_PRE_L,
+	BD72720_REG_VM_OCV_PST_U,
+	BD72720_REG_VM_OCV_PST_L,
+	BD72720_REG_VM_OCV_PWRON_U,
+	BD72720_REG_VM_OCV_PWRON_L,
+	BD72720_REG_VM_DVBAT_IMP_U,
+	BD72720_REG_VM_DVBAT_IMP_L,
+	BD72720_REG_VM_SA_VBAT_U,
+	BD72720_REG_VM_SA_VBAT_L,
+	BD72720_REG_VM_SA_VBAT_MIN_U,
+	BD72720_REG_VM_SA_VBAT_MIN_L,
+	BD72720_REG_VM_SA_VBAT_MAX_U,
+	BD72720_REG_VM_SA_VBAT_MAX_L,
+	BD72720_REG_REX_SA_VBAT_U,
+	BD72720_REG_REX_SA_VBAT_L,
+	BD72720_REG_VM_VSYS_U,
+	BD72720_REG_VM_VSYS_L,
+	BD72720_REG_VM_SA_VSYS_U,
+	BD72720_REG_VM_SA_VSYS_L,
+	BD72720_REG_VM_SA_VSYS_MIN_U,
+	BD72720_REG_VM_SA_VSYS_MIN_L,
+	BD72720_REG_VM_SA_VSYS_MAX_U,
+	BD72720_REG_VM_SA_VSYS_MAX_L,
+	BD72720_REG_VM_SA2_VSYS_U,
+	BD72720_REG_VM_SA2_VSYS_L,
+	BD72720_REG_VM_VBUS_U,
+#define BD72720_MASK_VDCIN_U	GENMASK(3, 0)
+	BD72720_REG_VM_VBUS_L,
+	BD72720_REG_VM_BATID_U,
+	BD72720_REG_VM_BATID_L,
+	BD72720_REG_VM_BATID_NOLOAD_U,
+	BD72720_REG_VM_BATID_NOLOAD_L,
+	BD72720_REG_VM_BATID_OFS_U,
+	BD72720_REG_VM_BATID_OFS_L,
+	BD72720_REG_VM_VTH_U,
+	BD72720_REG_VM_VTH_L,
+	BD72720_REG_VM_VTH_CORR_U,
+	BD72720_REG_VM_VTH_CORR_L,
+	BD72720_REG_VM_BTMP_U,
+	BD72720_REG_VM_BTMP_L,
+	BD72720_REG_VM_BTMP_IMP_U,
+	BD72720_REG_VM_BTMP_IMP_L,
+	BD72720_REG_VM_VF_U,
+	BD72720_REG_VM_VF_L,
+	BD72720_REG_VM_BATID_TH_U,
+	BD72720_REG_VM_BATID_TH_L,
+	BD72720_REG_VM_BTMP_OV_THR,
+	BD72720_REG_VM_BTMP_OV_DUR,
+	BD72720_REG_VM_BTMP_LO_THR,
+	BD72720_REG_VM_BTMP_LO_DUR,
+	BD72720_REG_ALM_VBAT_TH_U,
+	BD72720_REG_ALM_VBAT_TH_L,
+	BD72720_REG_ALM_VSYS_TH,
+	BD72720_REG_ALM_VBUS_TH,
+	BD72720_REG_ALM_VF_TH,
+	BD72720_REG_VSYS_MAX,
+	BD72720_REG_VSYS_MIN,
+	BD72720_REG_VM_VSYS_SA_MINMAX_CTRL,
+	BD72720_REG_VM_SA_CFG,		/* 0x6c + offset*/
+
+	BD72720_REG_CC_CURCD_U		= BD72720_I2C4C_ADDR_OFFSET + 0x70,
+	BD72720_REG_CC_CURCD_L,
+	BD72720_REG_CC_CURCD_IMP_U,
+	BD72720_REG_CC_CURCD_IMP_L,
+	BD72720_REG_CC_SA_CURCD_U,
+	BD72720_REG_CC_SA_CURCD_L,
+	BD72720_REG_CC_OCUR_MON,
+	BD72720_REG_CC_CCNTD_3,
+	BD72720_REG_CC_CCNTD_2,
+	BD72720_REG_CC_CCNTD_1,
+	BD72720_REG_CC_CCNTD_0,
+	BD72720_REG_REX_CCNTD_3,
+	BD72720_REG_REX_CCNTD_2,
+	BD72720_REG_REX_CCNTD_1,
+	BD72720_REG_REX_CCNTD_0,
+	BD72720_REG_FULL_CCNTD_3,
+	BD72720_REG_FULL_CCNTD_2,
+	BD72720_REG_FULL_CCNTD_1,
+	BD72720_REG_FULL_CCNTD_0,
+	BD72720_REG_CCNTD_CHG_3,
+	BD72720_REG_CCNTD_CHG_2,
+	BD72720_REG_CC_STAT,
+	BD72720_REG_CC_CTRL,
+	BD72720_REG_CC_OCUR_THR_1,
+	BD72720_REG_CC_OCUR_THR_2,
+	BD72720_REG_CC_OCUR_THR_3,
+	BD72720_REG_REX_CURCD_TH,
+	BD72720_REG_CC_BATCAP1_TH_U,
+	BD72720_REG_CC_BATCAP1_TH_L,
+	BD72720_REG_CC_BATCAP2_TH_U,
+	BD72720_REG_CC_BATCAP2_TH_L,
+	BD72720_REG_CC_BATCAP3_TH_U,
+	BD72720_REG_CC_BATCAP3_TH_L,
+	BD72720_REG_CC_CCNTD_CTRL,
+	BD72720_REG_CC_SA_CFG,		/* 0x92 + offset*/
+	BD72720_REG_IMPCHK_CTRL		= BD72720_I2C4C_ADDR_OFFSET + 0xa0,
+};
+
+#endif /* __LINUX_MFD_BD72720_H */
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index 579e8dcfcca4..0a284919a6c3 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -16,6 +16,7 @@ enum rohm_chip_type {
 	ROHM_CHIP_TYPE_BD71828,
 	ROHM_CHIP_TYPE_BD71837,
 	ROHM_CHIP_TYPE_BD71847,
+	ROHM_CHIP_TYPE_BD72720,
 	ROHM_CHIP_TYPE_BD96801,
 	ROHM_CHIP_TYPE_BD96802,
 	ROHM_CHIP_TYPE_BD96805,
-- 
2.51.0


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

^ permalink raw reply related

* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Linus Walleij @ 2025-10-27 22:42 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,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <a5957c4f83724d4f32527fb892fc340af4eeddde.1761564043.git.mazziesaccount@gmail.com>

Hi Matti,

thanks for your patch!

On Mon, Oct 27, 2025 at 12:45 PM Matti Vaittinen
<mazziesaccount@gmail.com> wrote:

> +  rohm,clkout-open-drain:
> +    description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 1

I think CMOS is the same as "push-pull" ( I could be wrong, but I think I've
seen that before) so I would probably try to use the pin config standard
names as strings here but I'm not sure.

rohm,clkout-bias-open-drain;
rohm,clkout-bias-push-pull;

Mutually exclusive.

Or maybe use the pattern from rohm,pin-dvs0
with string enumerators?

rohm,clkout-bias = "open-drain";
rohm,clkout-bias = "push-pull";

?

> +examples:

Maybe add some of the exotic string options into the example so
people will get it right?

Yours,
Linus Walleij

^ permalink raw reply

* Re: [PATCH v2 03/15] dt-bindings: power: supply: BD72720 managed battery
From: Linus Walleij @ 2025-10-27 22:34 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,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <e8d0273bcf0ac67382e17c40be87d345e28ac06c.1761564043.git.mazziesaccount@gmail.com>

On Mon, Oct 27, 2025 at 12:45 PM Matti Vaittinen
<mazziesaccount@gmail.com> wrote:

> 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>

From my PoV this looks good, and makes it easy for engineers
to read the DTS file and understand what is going on, so after
addressing Rob's final comments you can add:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply

* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Andreas Kemnade @ 2025-10-27 21:20 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
In-Reply-To: <a5957c4f83724d4f32527fb892fc340af4eeddde.1761564043.git.mazziesaccount@gmail.com>

On Mon, 27 Oct 2025 13:45:46 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> 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>
> 
[...]
> +
> +  rohm,charger-sense-resistor-milli-ohms:
> +    minimum: 10
> +    maximum: 50
> +    description: |
> +      BD72720 has a SAR ADC for measuring charging currents. External sense
> +      resistor (RSENSE in data sheet) should be used. If some other but
> +      30 mOhm resistor is used the resistance value should be given here in
> +      milli Ohms.
> +
rohm,bd71828.yaml has rohm,charger-sense-resistor-micro-ohms, lets
keep that unified.

Regards,
Andreas

^ permalink raw reply

* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Rob Herring @ 2025-10-27 21:13 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Krzysztof Kozlowski,
	Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <a5957c4f83724d4f32527fb892fc340af4eeddde.1761564043.git.mazziesaccount@gmail.com>

On Mon, Oct 27, 2025 at 01:45:46PM +0200, Matti Vaittinen wrote:
> 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:
>  RFCv1 => v2:
>  - Typofixes
> ---
>  .../bindings/mfd/rohm,bd72720-pmic.yaml       | 269 ++++++++++++++++++
>  1 file changed, 269 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
> new file mode 100644
> index 000000000000..b0d4bc01d199
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
> @@ -0,0 +1,269 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/rohm,bd72720-pmic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ROHM BD72720 Power Management Integrated Circuit
> +
> +maintainers:
> +  - Matti Vaittinen <mazziesaccount@gmail.com>
> +
> +description: |
> +  BD72720 is a single-chip power management IC for battery-powered portable
> +  devices. The BD72720 integrates 10 bucks and 11 LDOs, and a 3000 mA
> +  switching charger. The IC also includes a Coulomb counter, a real-time
> +  clock (RTC), GPIOs and a 32.768 kHz clock gate.
> +
> +# In addition to the properties found from the charger node, the ROHM BD72720
> +# uses properties from a static battery node. Please see the:
> +# Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml

Why is all of this a comment?

> +#
> +# Following properties are used
> +# when present:
> +#
> +# charge-full-design-microamp-hours: Battry capacity in mAh
> +# voltage-max-design-microvolt:      Maximum voltage
> +# voltage-min-design-microvolt:      Minimum voltage system is still operating.
> +# degrade-cycle-microamp-hours:      Capacity lost due to aging at each full
> +#                                    charge cycle.
> +# ocv-capacity-celsius:              Array of OCV table temperatures. 1/table.
> +# ocv-capacity-table-<N>:            Table of OCV voltage/SOC pairs. Corresponds
> +#                                    N.th temperature in ocv-capacity-celsius
> +#
> +# ROHM specific properties:
> +# rohm,voltage-vdr-thresh-microvolt: Threshold for starting the VDR correction
> +# rohm,volt-drop-soc:                Table of capacity values matching the
> +#                                    values in VDR tables.
> +# rohm,volt-drop-high-temp-microvolt: VDR table for high temperature
> +# rohm,volt-drop-normal-temp-microvolt: VDR table for normal temperature
> +# rohm,volt-drop-low-temp-microvolt:  VDR table for low temperature
> +# rohm,volt-drop-very-low-temp-microvolt: VDR table for very low temperature
> +#
> +# VDR tables are (usually) determined for a specific battery by ROHM.
> +# The battery node would then be referred from the charger node:
> +#
> +# monitored-battery = <&battery>;
> +
> +properties:
> +  compatible:
> +    const: rohm,bd72720
> +
> +  reg:
> +    description:
> +      I2C slave address.
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  gpio-controller: true
> +
> +  "#gpio-cells":
> +    const: 2
> +    description: |

Don't need '|'

> +      The first cell is the pin number and the second cell is used to specify
> +      flags. See ../gpio/gpio.txt for more information.

Don't add new references to old .txt bindings.

> +
> +  clocks:
> +    maxItems: 1
> +
> +  "#clock-cells":
> +    const: 0
> +
> +  clock-output-names:
> +    const: bd71828-32k-out
> +
> +  rohm,clkout-open-drain:
> +    description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0

0 is already the minimum for unsigned.

> +    maximum: 1
> +
> +  rohm,charger-sense-resistor-milli-ohms:
> +    minimum: 10
> +    maximum: 50
> +    description: |

Don't need '|'

> +      BD72720 has a SAR ADC for measuring charging currents. External sense
> +      resistor (RSENSE in data sheet) should be used. If some other but
> +      30 mOhm resistor is used the resistance value should be given here in
> +      milli Ohms.
> +
> +  regulators:
> +    $ref: ../regulator/rohm,bd77270-regulator.yaml

/schemas/regulator/...

> +    description:
> +      List of child nodes that specify the regulators.
> +
> +  leds:
> +    $ref: ../leds/rohm,bd71828-leds.yaml

/schemas/leds/...

> +
> +  rohm,pin-dvs0:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description:
> +      BD72720 has 4 different OTP options to determine the use of dvs0-pin.
> +      OTP0 - regulator RUN state control.
> +      OTP1 - GPI.
> +      OTP2 - GPO.
> +      OTP3 - Power sequencer output.
> +      This property specifies the use of the pin.
> +    enum:
> +      - dvs-input
> +      - gpi
> +      - gpo
> +
> +  rohm,pin-dvs1:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description:
> +      see rohm,pin-dvs0
> +    enum:
> +      - dvs-input
> +      - gpi
> +      - gpo

These 2 could be combined into a single entry in patternProperties.

> +
> +  rohm,pin-exten0:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: BD72720 has an OTP option to use exten0-pin for different
> +      purposes. Set this property accordingly.
> +    const: gpo
> +
> +  rohm,pin-exten1:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: BD72720 has an OTP option to use exten1-pin for different
> +      purposes. Set this property accordingly.
> +    const: gpo

And these 2 also.

> +
> +  rohm,pin-fault_b:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: BD72720 has an OTP option to use fault_b-pin for different
> +      purposes. Set this property accordingly.
> +    const: gpo

Seems like different purposes would have more than 1 option.

> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - "#clock-cells"
> +  - regulators
> +  - gpio-controller
> +  - "#gpio-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/leds/common.h>
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        pmic: pmic@4b {
> +            compatible = "rohm,bd71828";
> +            reg = <0x4b>;

Just 1 complete example in the mfd schema and drop this example.

> +
> +            interrupt-parent = <&gpio1>;
> +            interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
> +
> +            clocks = <&osc 0>;
> +            #clock-cells = <0>;
> +            clock-output-names = "bd71828-32k-out";
> +
> +            gpio-controller;
> +            #gpio-cells = <2>;
> +            gpio-reserved-ranges = <0 1>, <2 1>;
> +
> +            rohm,charger-sense-resistor-ohms = <10000000>;
> +
> +            regulators {
> +                buck1: BUCK1 {
> +                    regulator-name = "buck1";
> +                    regulator-min-microvolt = <500000>;
> +                    regulator-max-microvolt = <2000000>;
> +                    regulator-ramp-delay = <2500>;
> +                };
> +                buck2: BUCK2 {
> +                    regulator-name = "buck2";
> +                    regulator-min-microvolt = <500000>;
> +                    regulator-max-microvolt = <2000000>;
> +                    regulator-ramp-delay = <2500>;
> +                };
> +                buck3: BUCK3 {
> +                    regulator-name = "buck3";
> +                    regulator-min-microvolt = <1200000>;
> +                    regulator-max-microvolt = <2000000>;
> +                };
> +                buck4: BUCK4 {
> +                    regulator-name = "buck4";
> +                    regulator-min-microvolt = <1000000>;
> +                    regulator-max-microvolt = <1800000>;
> +                };
> +                buck5: BUCK5 {
> +                    regulator-name = "buck5";
> +                    regulator-min-microvolt = <2500000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +                buck6: BUCK6 {
> +                    regulator-name = "buck6";
> +                    regulator-min-microvolt = <500000>;
> +                    regulator-max-microvolt = <2000000>;
> +                    regulator-ramp-delay = <2500>;
> +                };
> +                buck7: BUCK7 {
> +                    regulator-name = "buck7";
> +                    regulator-min-microvolt = <500000>;
> +                    regulator-max-microvolt = <2000000>;
> +                    regulator-ramp-delay = <2500>;
> +                };
> +                ldo1: LDO1 {
> +                    regulator-name = "ldo1";
> +                    regulator-min-microvolt = <800000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +                ldo2: LDO2 {
> +                    regulator-name = "ldo2";
> +                    regulator-min-microvolt = <800000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +                ldo3: LDO3 {
> +                    regulator-name = "ldo3";
> +                    regulator-min-microvolt = <800000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +                ldo4: LDO4 {
> +                    regulator-name = "ldo4";
> +                    regulator-min-microvolt = <800000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +                ldo5: LDO5 {
> +                    regulator-name = "ldo5";
> +                    regulator-min-microvolt = <800000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +                ldo6: LDO6 {
> +                    regulator-name = "ldo6";
> +                    regulator-min-microvolt = <1800000>;
> +                    regulator-max-microvolt = <1800000>;
> +                };
> +                ldo7_reg: LDO7 {
> +                    regulator-name = "ldo7";
> +                    regulator-min-microvolt = <800000>;
> +                    regulator-max-microvolt = <3300000>;
> +                };
> +            };
> +
> +            leds {
> +                compatible = "rohm,bd71828-leds";
> +
> +                led-1 {
> +                    rohm,led-compatible = "bd71828-grnled";
> +                    function = LED_FUNCTION_INDICATOR;
> +                    color = <LED_COLOR_ID_GREEN>;
> +                };
> +                led-2 {
> +                    rohm,led-compatible = "bd71828-ambled";
> +                    function = LED_FUNCTION_CHARGING;
> +                    color = <LED_COLOR_ID_AMBER>;
> +                };
> +            };
> +        };
> +    };
> -- 
> 2.51.0
> 



^ permalink raw reply

* Re: [PATCH v2 03/15] dt-bindings: power: supply: BD72720 managed battery
From: Rob Herring @ 2025-10-27 21:08 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Krzysztof Kozlowski,
	Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <e8d0273bcf0ac67382e17c40be87d345e28ac06c.1761564043.git.mazziesaccount@gmail.com>

On Mon, Oct 27, 2025 at 01:45:23PM +0200, Matti Vaittinen wrote:
> 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>
> ---
> Revision history:
>  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
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml b/Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml
> new file mode 100644
> index 000000000000..1ab3418d4338
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/supply/rohm,vdr-battery.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Battery managed by the BD72720 PMIC
> +
> +maintainers:
> +  - Matti Vaittinen <mazziesaccount@gmail.com>
> +
> +description:
> +  A battery which has VDR parameters measuerd for ROHM chargers.
> +
> +allOf:
> +  - $ref: battery.yaml#
> +
> +properties:
> +  rohm,voltage-vdr-thresh-microvolt:
> +    description: Threshold for starting the VDR correction

No constraints? Is 4000V okay?

> +
> +  rohm,volt-drop-soc:
> +    description: Table of capacity values matching the values in VDR tables.
> +      The value should be given as tenths of a percentage.

We have a standard unit for this too. '-bp' or basis points (1/100 of 
percent).

> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  rohm,volt-drop-temperatures-millicelsius:
> +    description: An array containing the temperature in milli celsius, for each
> +      of the VDR lookup table.
> +
> +patternProperties:
> +  '^rohm,volt-drop-[0-9]-microvolt':
> +    description: Table of the voltage drop rate (VDR) values. Each entry in the
> +      table should match a capacity value in the rohm,volt-drop-soc table.
> +      Furthermore, the values should be obtained for the temperature given in
> +      rohm,volt-drop-temperatures-millicelsius table at index matching the
> +      number in this table's name.
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    power {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      battery: battery {
> +        compatible = "simple-battery";
> +
> +        ocv-capacity-celsius = <25>;
> +        ocv-capacity-table-0 = <4200000 100 4184314 100 4140723 95 4099487 90
> +          4060656 85 4024350 80 3991121 75 3954379 70 3913265 65 3877821 60
> +          3855577 55 3837466 50 3822194 45 3809012 40 3795984 35 3780647 30
> +          3760505 25 3741532 20 3718837 15 3696698 10 3690594 5 3581427 0>;
> +
> +        rohm,volt-drop-soc = <1000 1000 950 900 850 800 750 700 650 600 550 500
> +          450 400 350 300 250 200 150 100 50 00 (-50)>;
> +
> +        rohm,volt-drop-temperatures-millicelsius = <45000 25000 5000 0>;
> +
> +        rohm,volt-drop-0-microvolt =  <100 100 102 104 106 109 114 124
> +          117 107 107 109 112 116 117 108 109 109 108 109 122 126 130>;
> +
> +        rohm,volt-drop-1-microvolt = <100 100 102 105 98 100 105 102
> +          101 99 98 100 103 105 109 117 111 109 110 114 128 141 154>;
> +
> +        rohm,volt-drop-2-microvolt = <100 100 98 107 112 114 118 118 112
> +          108 108 110 111 113 117 123 131 144 157 181 220 283 399>;
> +
> +        rohm,volt-drop-3-temp-microvolt = <86 86 105 109 114 110 115 115
> +          110 108 110 112 114 118 124 134 136 160 177 201 241 322 403>;
> +
> +        rohm,voltage-vdr-thresh-microvolt = <4150000>;
> +
> +        charge-full-design-microamp-hours = <1799000>;
> +        voltage-max-design-microvolt = <4200000>;
> +        voltage-min-design-microvolt = <3500000>;
> +        degrade-cycle-microamp-hours = <131>;
> +      };
> +    };
> -- 
> 2.51.0
> 



^ permalink raw reply

* Re: [PATCH v2 01/15] dt-bindings: regulator: ROHM BD72720
From: Rob Herring @ 2025-10-27 21:03 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Krzysztof Kozlowski,
	Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <25746d258ac57ae3eee82a20fa14a8a168f35e58.1761564043.git.mazziesaccount@gmail.com>

On Mon, Oct 27, 2025 at 01:44:49PM +0200, Matti Vaittinen wrote:
> 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-millivolt' 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:
>  RFCv1 =>:
>  - No changes
> ---
>  .../regulator/rohm,bd72720-regulator.yaml     | 153 ++++++++++++++++++
>  1 file changed, 153 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml
> 
> diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml
> new file mode 100644
> index 000000000000..665086f56928
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml
> @@ -0,0 +1,153 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/rohm,bd72720-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ROHM BD72720 Power Management Integrated Circuit regulators
> +
> +maintainers:
> +  - Matti Vaittinen <mazziesaccount@gmail.com>
> +
> +description: |
> +  This module is part of the ROHM BD72720 MFD device. For more details
> +  see Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml.
> +
> +  The regulator controller is represented as a sub-node of the PMIC node
> +  on the device tree.
> +
> +  Regulator nodes should be named to BUCK_<number> and LDO_<number>.
> +  The valid names for BD72720 regulator nodes are
> +  buck1, buck2, buck3, buck4, buck5, buck6, buck7, buck8, buck9, buck10
> +  ldo1, ldo2, ldo3, ldo4, ldo5, ldo6, ldo7, ldo8, ldo9, ldo10, ldo11
> +
> +patternProperties:
> +  "^ldo[1-11]$":
> +    type: object
> +    description:
> +      Properties for single LDO regulator.
> +    $ref: regulator.yaml#
> +
> +    properties:
> +      regulator-name:
> +        pattern: "^ldo[1-11]$"
> +        description:
> +          should be "ldo1", ..., "ldo11"

No need to repeat in prose what the schema says.

> +
> +      rohm,dvs-run-voltage:
> +        description:
> +          PMIC default "RUN" state voltage in uV. See below table for
> +          LDOs which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +      rohm,dvs-idle-voltage:
> +        description:
> +          PMIC default "IDLE" state voltage in uV. See below table for
> +          LDOs which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +      rohm,dvs-suspend-voltage:
> +        description:
> +          PMIC default "SUSPEND" state voltage in uV. See below table for
> +          LDOs which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +      rohm,dvs-lpsr-voltage:
> +        description:
> +          PMIC default "deep-idle" state voltage in uV. See below table for
> +          LDOs which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +        # Supported default DVS states:
> +        #     ldo        |    run     |   idle    | suspend   | lpsr
> +        # --------------------------------------------------------------
> +        # 1, 2, 3, and 4 | supported  | supported | supported | supported
> +        # --------------------------------------------------------------
> +        # 5 - 11         |                    supported (*)
> +        # --------------------------------------------------------------
> +        #
> +        # (*) All states use same voltage but have own enable / disable
> +        #      settings. Voltage 0 can be specified for a state to make
> +        #      regulator disabled on that state.
> +
> +    unevaluatedProperties: false
> +
> +  "^buck[1-10]$":
> +    type: object
> +    description:
> +      Properties for single BUCK regulator.
> +    $ref: regulator.yaml#
> +
> +    properties:
> +      regulator-name:
> +        pattern: "^buck[1-10]$"
> +        description:
> +          should be "buck1", ..., "buck10"

Same here.

> +
> +      rohm,ldon-head-millivolt:

Use standard unit-suffixes. (-microvolt)

> +        description:
> +          Set this on boards where BUCK10 is used to supply LDOs 1-4. The bucki
> +          voltage will be changed by the PMIC to follow the LDO output voltages
> +          with the offset voltage given here. This will improve the LDO efficiency.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 50
> +        maximum: 300
> +
> +      rohm,dvs-run-voltage:
> +        description:
> +          PMIC default "RUN" state voltage in uV. See below table for
> +          bucks which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +      rohm,dvs-idle-voltage:
> +        description:
> +          PMIC default "IDLE" state voltage in uV. See below table for
> +          bucks which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +      rohm,dvs-suspend-voltage:
> +        description:
> +          PMIC default "SUSPEND" state voltage in uV. See below table for
> +          bucks which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +      rohm,dvs-lpsr-voltage:
> +        description:
> +          PMIC default "deep-idle" state voltage in uV. See below table for
> +          bucks which support this. 0 means disabled.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3300000
> +
> +        # Supported default DVS states:
> +        #     buck       |    run     |   idle    | suspend   | lpsr
> +        # --------------------------------------------------------------
> +        # 1, 2, 3, and 4 | supported  | supported | supported | supported
> +        # --------------------------------------------------------------
> +        # 5 - 10    |                    supported (*)
> +        # --------------------------------------------------------------
> +        #
> +        # (*) All states use same voltage but have own enable / disable
> +        #      settings. Voltage 0 can be specified for a state to make
> +        #      regulator disabled on that state.
> +
> +    required:
> +      - regulator-name
> +
> +    unevaluatedProperties: false
> +
> +additionalProperties: false
> -- 
> 2.51.0
> 



^ permalink raw reply

* Re: [PATCH v2 0/4] fix the SpacemiT P1 Kconfig and resend the K1 I2C ILCR patch.
From: Troy Mitchell @ 2025-10-27 13:52 UTC (permalink / raw)
  To: Troy Mitchell, Lee Jones, Yixun Lan, Alex Elder, Andi Shyti,
	Alexandre Belloni, Liam Girdwood, Mark Brown, linux-kernel,
	linux-riscv, spacemit, linux-i2c, linux-rtc, kernel test robot
In-Reply-To: <aP9IVckJT-k2_O4K@aurel32.net>

On Mon, Oct 27, 2025 at 11:24:21AM +0100, Aurelien Jarno wrote:
> Hi,
> 
> On 2025-10-27 13:48, Troy Mitchell wrote:
> > Since P1 Kconfig directly selects K1_I2C, after the I2C ILCR patch was
> > merged, the driver would fail [1] when COMMON_CLK was not selected.
> > 
> > This series fixes the P1 Kconfig and resends the I2C ILCR patch(This
> > patch has reverted by maintainer [2]). In addition, the Kconfig for
> > P1's two subdevices, regulator and RTC, has been updated to use
> > 'depends on MFD_SPACEMIT_P1' instead of 'select'.
> > 
> > Link: https://lore.kernel.org/oe-kbuild-all/202510202150.2qXd8e7Y-lkp@intel.com/ [1]
> > Link: https://lore.kernel.org/all/sdhkjmi5l2m4ua4zqkwkecbihul5bc2dbmitudwfd57y66mdht@6ipjfyz7dtmx/ [2]
> > 
> > Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> 
> I think this series misses a patch to add a default value for 
> MFD_SPACEMIT_P1. Otherwise it doesn't make sense to define a default 
> value for the ones depending on it (RTC_DRV_SPACEMIT_P1, 
> REGULATOR_SPACEMIT_P1).
Yes, I forgot that. I'll add it in the next version. Thanks!

                                  - Troy
> 
> Regards
> Aurelien
> 
> -- 
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                     http://aurel32.net
> 

^ permalink raw reply

* Re: [PATCH v2 12/15] rtc: bd70528: Support BD72720 rtc
From: Matti Vaittinen @ 2025-10-27 13:02 UTC (permalink / raw)
  To: Alexandre Belloni
  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, Andreas Kemnade, linux-leds,
	devicetree, linux-kernel, linux-pm, linux-clk, linux-gpio,
	linux-rtc
In-Reply-To: <202510271238195ef3bdfb@mail.local>

On 27/10/2025 14:38, Alexandre Belloni wrote:
> On 27/10/2025 13:47:51+0200, Matti Vaittinen wrote:
>> The BD72720 has similar RTC block as a few other ROHM PMICs.
>>
>> Add support for BD72720 RTC.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
> 
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> 
> Note that we didn't get 07/15 that adds linux/mfd/rohm-bd72720.h which
> this patch depends on.

Thanks for the heads-up Alexandre!

For some reason the SMTP server seems to be blocking the 7/15 :/ I will 
try to figure out a way to send it :(

Yours,
	-- Matti

^ permalink raw reply

* Re: [PATCH v2 12/15] rtc: bd70528: Support BD72720 rtc
From: Alexandre Belloni @ 2025-10-27 12:38 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, Andreas Kemnade, linux-leds,
	devicetree, linux-kernel, linux-pm, linux-clk, linux-gpio,
	linux-rtc
In-Reply-To: <380ea1fdbb94a796418e8f463c6a9436001d572d.1761564043.git.mazziesaccount@gmail.com>

On 27/10/2025 13:47:51+0200, Matti Vaittinen wrote:
> The BD72720 has similar RTC block as a few other ROHM PMICs.
> 
> Add support for BD72720 RTC.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> 

Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Note that we didn't get 07/15 that adds linux/mfd/rohm-bd72720.h which
this patch depends on.

> ---
> Revision history:
>  RFCv1 =>:
>  - No changes
> ---
>  drivers/rtc/Kconfig       |  3 ++-
>  drivers/rtc/rtc-bd70528.c | 21 ++++++++++++++-------
>  2 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 2933c41c77c8..418f6c28847a 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -561,7 +561,8 @@ config RTC_DRV_BD70528
>  	depends on MFD_ROHM_BD71828
>  	help
>  	  If you say Y here you will get support for the RTC
> -	  block on ROHM BD71815 and BD71828 Power Management IC.
> +	  block on ROHM BD71815, BD71828 and BD72720 Power
> +	  Management ICs.
>  
>  	  This driver can also be built as a module. If so, the module
>  	  will be called rtc-bd70528.
> diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
> index 954ac4ef53e8..4c8599761b2e 100644
> --- a/drivers/rtc/rtc-bd70528.c
> +++ b/drivers/rtc/rtc-bd70528.c
> @@ -7,6 +7,7 @@
>  #include <linux/bcd.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/of.h>
>  #include <linux/platform_device.h>
> @@ -262,13 +263,13 @@ static int bd70528_probe(struct platform_device *pdev)
>  
>  		/*
>  		 * See also BD718XX_ALM_EN_OFFSET:
> -		 * This works for BD71828 and BD71815 as they have same offset
> -		 * between ALM0 start and ALM0_MASK. If new ICs are to be
> -		 * added this requires proper check as ALM0_MASK is not located
> -		 * at the end of ALM0 block - but after all ALM blocks so if
> -		 * amount of ALMs differ the offset to enable/disable is likely
> -		 * to be incorrect and enable/disable must be given as own
> -		 * reg address here.
> +		 * This works for BD71828, BD71815, and BD72720 as they all
> +		 * have same offset between the ALM0 start and the ALM0_MASK.
> +		 * If new ICs are to be added this requires proper check as
> +		 * the  ALM0_MASK is not located at the end of ALM0 block -
> +		 * but after all ALM blocks. If amount of ALMs differ, the
> +		 * offset to enable/disable is likely to be incorrect and
> +		 * enable/disable must be given as own reg address here.
>  		 */
>  		bd_rtc->bd718xx_alm_block_start = BD71815_REG_RTC_ALM_START;
>  		hour_reg = BD71815_REG_HOUR;
> @@ -278,6 +279,11 @@ static int bd70528_probe(struct platform_device *pdev)
>  		bd_rtc->bd718xx_alm_block_start = BD71828_REG_RTC_ALM_START;
>  		hour_reg = BD71828_REG_RTC_HOUR;
>  		break;
> +	case ROHM_CHIP_TYPE_BD72720:
> +		bd_rtc->reg_time_start = BD72720_REG_RTC_START;
> +		bd_rtc->bd718xx_alm_block_start = BD72720_REG_RTC_ALM_START;
> +		hour_reg = BD72720_REG_RTC_HOUR;
> +		break;
>  	default:
>  		dev_err(&pdev->dev, "Unknown chip\n");
>  		return -ENOENT;
> @@ -337,6 +343,7 @@ static int bd70528_probe(struct platform_device *pdev)
>  static const struct platform_device_id bd718x7_rtc_id[] = {
>  	{ "bd71828-rtc", ROHM_CHIP_TYPE_BD71828 },
>  	{ "bd71815-rtc", ROHM_CHIP_TYPE_BD71815 },
> +	{ "bd72720-rtc", ROHM_CHIP_TYPE_BD72720 },
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(platform, bd718x7_rtc_id);
> -- 
> 2.51.0
> 



-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v2 09/15] regulator: bd71828: Support ROHM BD72720
From: Mark Brown @ 2025-10-27 12:15 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
	Liam Girdwood, Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <28f888c9784058b2d727a4b6185ac49874552847.1761564043.git.mazziesaccount@gmail.com>

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

On Mon, Oct 27, 2025 at 01:47:10PM +0200, Matti Vaittinen wrote:
> ROHM BD72720 is a power management IC which integrates 10 buck and 11 LDO
> regulators. This PMIC has plenty of commonalities with the BD71828 and
> BD71879.

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

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

^ permalink raw reply

* Re: [PATCH v2 08/15] regulator: bd71828: rename IC specific entities
From: Mark Brown @ 2025-10-27 12:14 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
	Liam Girdwood, Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <aa2b31267e6cc93bad4c823ef1ba07ba43efd572.1761564043.git.mazziesaccount@gmail.com>

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

On Mon, Oct 27, 2025 at 01:46:57PM +0200, Matti Vaittinen wrote:
> The new ROHM BD72720 PMIC has similarities with the BD71828. It makes
> sense to support the regulator control for both PMICs using the same
> driver. It is often more clear to have the IC specific functions and
> globals named starting with the chip-name. So, as a preparatory step,
> prefix the BD71828 specific functions and globals with the bd71828.

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

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

^ permalink raw reply

* Re: [PATCH v2 4/4] regulator: spacemit: MFD_SPACEMIT_P1 as dependencies
From: Mark Brown @ 2025-10-27 12:08 UTC (permalink / raw)
  To: Troy Mitchell
  Cc: Lee Jones, Yixun Lan, Alex Elder, Andi Shyti, Alexandre Belloni,
	Liam Girdwood, linux-kernel, linux-riscv, spacemit, linux-i2c,
	linux-rtc
In-Reply-To: <20251027-p1-kconfig-fix-v2-4-49688f30bae8@linux.spacemit.com>

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

On Mon, Oct 27, 2025 at 01:48:08PM +0800, Troy Mitchell wrote:
> REGULATOR_SPACEMIT_P1 is a subdevice of P1 and should depend on
> MFD_SPACEMIT_P1 rather than selecting it directly. Using 'select'
> does not always respect the parent's dependencies, so 'depends on'
> is the safer and more correct choice.

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

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

^ permalink raw reply

* [PATCH v2 15/15] MAINTAINERS: Add ROHM BD72720 PMIC
From: Matti Vaittinen @ 2025-10-27 11:48 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, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <cover.1761564043.git.mazziesaccount@gmail.com>

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

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

* [PATCH v2 14/15] power: supply: bd71828-power: Support ROHM BD72720
From: Matti Vaittinen @ 2025-10-27 11:48 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, Andreas Kemnade, Alexandre Belloni,
	linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
	linux-gpio, linux-rtc
In-Reply-To: <cover.1761564043.git.mazziesaccount@gmail.com>

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

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:
 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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox