* Re: [PATCH] rtc: ti-k3: Add support to resume from IO DDR low power mode
From: Akashdeep Kaur @ 2026-03-13 11:17 UTC (permalink / raw)
To: Vignesh Raghavendra, praneeth, nm, alexandre.belloni, linux-rtc,
linux-kernel
Cc: msp, vishalm, sebin.francis, d-gole, k-willis
In-Reply-To: <04d217c5-e95f-4507-972f-6a8bda201bf3@ti.com>
Hi Vignesh,
On 13/03/26 13:53, Vignesh Raghavendra wrote:
>
>
> On 11/03/26 12:32, Akashdeep Kaur wrote:
>> During IO DDR low power mode, the RTC IP is reset and loses its
>> register configuration.
>
>> The DDR memory still preserves all driver states
>> (reference counts, software context).
>
> That's the definition of Suspend to RAM
>
>> System clocks are saved and restored
>> by Device Manager (DM) firmware during the resume sequence.
>
> Not relevant for this patch in particular.
>
>> Add support to reconfigure the RTC IP registers in resume handler only if
>> resume hook is called during IO DDR low power mode resume.
>>
>
> Above all is probably bit too verbose. Below text is all thats needed:
>
> Restore the RTC HW context which may be lost when system enters certain
> low power mode (IO+DDR mode). Check if the RTC registers are locked
> which would indicate loss of context (reset) and restore the context as
> needed.
Updated the commit message as suggested.
Regards,
Akashdeep Kaur
>
>> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
>> ---
>>
>> Tested deep sleep with rtcwake after IO DDR resume on AM62P-SK.
>>
>> ---
>> drivers/rtc/rtc-ti-k3.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/rtc/rtc-ti-k3.c b/drivers/rtc/rtc-ti-k3.c
>> index ec759d8f7023..e801f5b9d757 100644
>> --- a/drivers/rtc/rtc-ti-k3.c
>> +++ b/drivers/rtc/rtc-ti-k3.c
>> @@ -640,10 +640,18 @@ static int __maybe_unused ti_k3_rtc_suspend(struct device *dev)
>> static int __maybe_unused ti_k3_rtc_resume(struct device *dev)
>> {
>> struct ti_k3_rtc *priv = dev_get_drvdata(dev);
>> + int ret = 0;
>> +
>> + if (k3rtc_check_unlocked(priv)) {
>> + /* RTC locked implies low power mode exit where RTC loses context */
>> + ret = k3rtc_configure(dev);
>> + if (ret)
>> + return ret;
>> + }
>>
>> if (device_may_wakeup(dev))
>> disable_irq_wake(priv->irq);
>> - return 0;
>> + return ret;
>> }
>>
>> static SIMPLE_DEV_PM_OPS(ti_k3_rtc_pm_ops, ti_k3_rtc_suspend, ti_k3_rtc_resume);
>
^ permalink raw reply
* Re: [PATCH] rtc: armada38x: zalloc + calloc to single allocation
From: Alexandre Belloni @ 2026-03-13 10:26 UTC (permalink / raw)
To: linux-rtc, Rosen Penev
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260304225329.24510-1-rosenp@gmail.com>
On Wed, 04 Mar 2026 14:53:29 -0800, Rosen Penev wrote:
> Use a flexible array member to simplify allocation.
>
>
Applied, thanks!
[1/1] rtc: armada38x: zalloc + calloc to single allocation
https://git.kernel.org/abelloni/c/5827fe59745d
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: rtc: isl12026: convert to YAML schema
From: Alexandre Belloni @ 2026-03-13 10:20 UTC (permalink / raw)
To: Piyush Patle; +Cc: robh, krzk+dt, conor+dt, linux-rtc, devicetree, linux-kernel
In-Reply-To: <20260227185115.174997-1-piyushpatle228@gmail.com>
On Sat, 28 Feb 2026 00:21:15 +0530, Piyush Patle wrote:
> Convert the ISL12026 RTC binding from text format to YAML schema.
> Remove the legacy text binding.
>
> The new schema enables dtbs_check validation.
>
>
Applied, thanks!
[1/1] dt-bindings: rtc: isl12026: convert to YAML schema
https://git.kernel.org/abelloni/c/5ff89ef425d1
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v3 0/2] Kontron i.MX8MP OSM Devicetree Fixups
From: Alexandre Belloni @ 2026-03-13 9:28 UTC (permalink / raw)
To: Conor Dooley, devicetree, Frank Li, Frieder Schrempf, imx,
Krzysztof Kozlowski, linux-arm-kernel, linux-kernel, linux-rtc,
Rob Herring, Sascha Hauer, Shawn Guo, Frieder Schrempf
Cc: Annette Kobou, Fabio Estevam, Pengutronix Kernel Team
In-Reply-To: <20260309085749.25747-1-frieder@fris.de>
On Mon, 09 Mar 2026 09:57:41 +0100, Frieder Schrempf wrote:
> Kontron i.MX8MP OSM Devicetree Fixups
>
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> This contains three fixes and one cosmetic change for
> the Kontron i.MX8MP OSM devices.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply
https://git.kernel.org/abelloni/c/10663044bee5
Best regards,
^ permalink raw reply
* Re: [PATCH] rtc: ti-k3: Add support to resume from IO DDR low power mode
From: Vignesh Raghavendra @ 2026-03-13 8:23 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, alexandre.belloni, linux-rtc,
linux-kernel
Cc: msp, vishalm, sebin.francis, d-gole, k-willis
In-Reply-To: <20260311070214.3589965-1-a-kaur@ti.com>
On 11/03/26 12:32, Akashdeep Kaur wrote:
> During IO DDR low power mode, the RTC IP is reset and loses its
> register configuration.
> The DDR memory still preserves all driver states
> (reference counts, software context).
That's the definition of Suspend to RAM
> System clocks are saved and restored
> by Device Manager (DM) firmware during the resume sequence.
Not relevant for this patch in particular.
> Add support to reconfigure the RTC IP registers in resume handler only if
> resume hook is called during IO DDR low power mode resume.
>
Above all is probably bit too verbose. Below text is all thats needed:
Restore the RTC HW context which may be lost when system enters certain
low power mode (IO+DDR mode). Check if the RTC registers are locked
which would indicate loss of context (reset) and restore the context as
needed.
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
>
> Tested deep sleep with rtcwake after IO DDR resume on AM62P-SK.
>
> ---
> drivers/rtc/rtc-ti-k3.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-ti-k3.c b/drivers/rtc/rtc-ti-k3.c
> index ec759d8f7023..e801f5b9d757 100644
> --- a/drivers/rtc/rtc-ti-k3.c
> +++ b/drivers/rtc/rtc-ti-k3.c
> @@ -640,10 +640,18 @@ static int __maybe_unused ti_k3_rtc_suspend(struct device *dev)
> static int __maybe_unused ti_k3_rtc_resume(struct device *dev)
> {
> struct ti_k3_rtc *priv = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + if (k3rtc_check_unlocked(priv)) {
> + /* RTC locked implies low power mode exit where RTC loses context */
> + ret = k3rtc_configure(dev);
> + if (ret)
> + return ret;
> + }
>
> if (device_may_wakeup(dev))
> disable_irq_wake(priv->irq);
> - return 0;
> + return ret;
> }
>
> static SIMPLE_DEV_PM_OPS(ti_k3_rtc_pm_ops, ti_k3_rtc_suspend, ti_k3_rtc_resume);
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* ペットを愛する、経営者様へ
From: 日本ペットホテル協会 @ 2026-03-13 4:31 UTC (permalink / raw)
To: linux-rtc
ペットを愛する、経営者様へ
地域で愛犬を安心して預けられる
ペットホテル・トリミング事業を始めませんか？
■ フランチャイズシステム説明会 ■
愛犬家のオーナー多数！
ペットホテル・トリミングサロン
“ONE LUKE（ワンルーク）”
※「開業パック」をご用意しているので
経験や資格が無くても始められます。
■ 開催方式
オンライン（申込後に参加方法をご案内）
■ 日程
3月16日（月）11:00〜12:00 残り1枠
3月19日（木）15:00〜16:00 残り1枠
3月24日（火）13:00〜14:00
■ 定員
5名
■ 参加申込はこちら
https://oneluke-fc-seminar.jp/lp/
お世話になります。
この度は、ペットホテル・トリミングサロンの
フラチャイズ事業説明会の開催をご案内いたします。
ペットホテルとトリミングサービスを提供する
ONE LUKE（ワンルーク）
は、ワンちゃんが好きすぎる創業者が実際に
ペットホテルに預けたときに感じた不安や
思ったことを施設づくりに活かしています。
例えばワンちゃんが泊まるときに、少しでも
広く、心地よく過ごして欲しいという思いから、
鉄のゲージではなくオーダーで職人さんに
「お部屋」をつくっていただいています。
そうした愛犬家目線のきめ細かいサービスが支持され、
ワンルークを利用した方は高い確率でリピートしてくれます。
日本ではいまや「8世帯に1世帯」がペットを飼うまでに
増えてきましたが、ペットホテルはまだまだ店舗数が
足りていないため、今後も成長が期待できます。
ここまでこの文章を読まれたということは、
あなたもワンちゃんが大好きなのではないでしょうか。
ワンルークのFCオーナー様も愛犬家が多く、中には
ご自身が利用者だった、という方もいらっしゃいます。
説明会にて詳しいビジネスモデルをお伝えしますので、
新規事業を探している愛犬家の経営者様は
この機会にぜひご参加ください。
地域のペットライフを豊かにし、愛犬が安心して
過ごせる空間を一緒につくっていきましょう。
■ フランチャイズシステム説明会 ■
愛犬家のオーナー多数！
ペットホテル・トリミングサロン
“ONE LUKE（ワンルーク）”
■ 参加申込はこちら
https://oneluke-fc-seminar.jp/lp/
***********************************************************************
本メールのご不要な方には大変ご迷惑をおかけいたしました。
お手数お掛けしますが、メール不要のお手続きは
下記URLよりお願いいたします。
<メール停止フォーム>
https://oneluke-fc-seminar.jp/mail/
***********************************************************************
日本ペットホテル協会株式会社
愛知県名古屋市千種区内山3丁目9-23 3F
TEL:052-784-8416
***********************************************************************
^ permalink raw reply
* Re: [PATCH] rtc: add BSM flags descriptions
From: Hugo Villeneuve @ 2026-03-12 17:51 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Alexandre Belloni, Hugo Villeneuve, linux-rtc, linux-kernel
In-Reply-To: <20260113100427.f2162f0d5ba80a259511f9d2@hugovil.com>
On Tue, 13 Jan 2026 10:04:27 -0500
Hugo Villeneuve <hugo@hugovil.com> wrote:
> On Mon, 21 Jul 2025 11:33:31 -0400
> Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > It is hard to decipher what the RTC BSM flags mean, so add
> > meaningful descriptions.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > include/uapi/linux/rtc.h | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/uapi/linux/rtc.h b/include/uapi/linux/rtc.h
> > index 97aca4503a6a..da65130e316d 100644
> > --- a/include/uapi/linux/rtc.h
> > +++ b/include/uapi/linux/rtc.h
> > @@ -141,10 +141,15 @@ struct rtc_param {
> > #define RTC_PARAM_CORRECTION 1
> > #define RTC_PARAM_BACKUP_SWITCH_MODE 2
> >
> > +/* Backup switch mode */
> > #define RTC_BSM_DISABLED 0
> > -#define RTC_BSM_DIRECT 1
> > -#define RTC_BSM_LEVEL 2
> > -#define RTC_BSM_STANDBY 3
> > +#define RTC_BSM_DIRECT 1 /* Switch if Vbackup > Vdd */
> > +#define RTC_BSM_LEVEL 2 /* Switch based on a threshold, usually with an hysteresis */
> > +#define RTC_BSM_STANDBY 3 /*
> > + * Switch if Vdd > Vbackup.
> > + * Useful to ensure the RTC doesn't draw any
> > + * power until the device is first powered on.
> > + */
> >
> > #define RTC_MAX_FREQ 8192
>
> Ping?
Ping, Ping?
--
Hugo Villeneuve
^ permalink raw reply
* Re: (subset) [PATCH v4 0/5] rtc: max77686: convert to i2c_new_ancillary_device
From: Alexandre Belloni @ 2026-03-12 16:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-1-clamor95@gmail.com>
On Thu, 12 Mar 2026 10:52:53 +0200, Svyatoslav Ryhel wrote:
> rtc: max77686: convert to i2c_new_ancillary_device
>
> Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
> i2c_new_ancillary_device() to enable the use of a device tree-specified
> RTC address instead of a hardcoded value. If the device tree does not
> provide an address, use hardcoded values as a fallback.
>
> [...]
Applied, thanks!
[5/5] rtc: max77686: convert to i2c_new_ancillary_device
https://git.kernel.org/abelloni/c/0d65a9d93d87
Best regards,
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-12 16:26 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Chanwoo Choi, Alexandre Belloni, linux-gpio, devicetree,
linux-kernel, linux-pm, linux-rtc
In-Reply-To: <CAL_JsqKP-uYZf3MLFd5JrrsZ1+pxj-y+te_3uiM9N+5Xu4phUQ@mail.gmail.com>
чт, 12 бер. 2026 р. о 17:39 Rob Herring <robh@kernel.org> пише:
>
> On Thu, Mar 12, 2026 at 10:34 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > чт, 12 бер. 2026 р. о 17:20 Rob Herring <robh@kernel.org> пише:
> > >
> > > On Thu, Mar 12, 2026 at 10:52:55AM +0200, Svyatoslav Ryhel wrote:
> > > > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > > > TXT to YAML format. This patch does not change any functionality; the
> > > > bindings remain the same.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> > > > .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> > > > 2 files changed, 97 insertions(+), 127 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > > delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > > new file mode 100644
> > > > index 000000000000..4e5f997317ca
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > > @@ -0,0 +1,97 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Pinmux controller function for Maxim MAX77620 Power management IC
> > > > +
> > > > +maintainers:
> > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +description:
> > > > + Device has 8 GPIO pins which can be configured as GPIO as well as the
> > > > + special IO functions.
> > > > +
> > > > +allOf:
> > > > + - $ref: /schemas/pinctrl/pincfg-node.yaml
> > > > + - $ref: /schemas/pinctrl/pinmux-node.yaml
> > >
> > > Don't these properties apply to the child nodes?
> > >
> >
> > They do, but not all properties defined in those schema files are
> > applicable for this binding. I have marked those which can be applied
> > in the node patterns.
>
> Then additionalProperties is appropriate.
>
> > > > +
> > > > +patternProperties:
> > > > + "^(pin|gpio).":
> > > > + type: object
> > >
> > > additionalProperties: false
> >
> > I will move additionalProperties here then.
>
> No, moving it is wrong. You need it here AND in the parent node.
>
Oh, yes, you are right, it seems that I did not notice while
converting from txt. Thanks!
> Rob
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Rob Herring @ 2026-03-12 15:39 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Chanwoo Choi, Alexandre Belloni, linux-gpio, devicetree,
linux-kernel, linux-pm, linux-rtc
In-Reply-To: <CAPVz0n2GFgsrqo4_MkvNwd9t=DMU4ZGQzrpNjU+PZ4_Ysx_jcg@mail.gmail.com>
On Thu, Mar 12, 2026 at 10:34 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> чт, 12 бер. 2026 р. о 17:20 Rob Herring <robh@kernel.org> пише:
> >
> > On Thu, Mar 12, 2026 at 10:52:55AM +0200, Svyatoslav Ryhel wrote:
> > > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > > TXT to YAML format. This patch does not change any functionality; the
> > > bindings remain the same.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> > > .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> > > 2 files changed, 97 insertions(+), 127 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > new file mode 100644
> > > index 000000000000..4e5f997317ca
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > @@ -0,0 +1,97 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Pinmux controller function for Maxim MAX77620 Power management IC
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description:
> > > + Device has 8 GPIO pins which can be configured as GPIO as well as the
> > > + special IO functions.
> > > +
> > > +allOf:
> > > + - $ref: /schemas/pinctrl/pincfg-node.yaml
> > > + - $ref: /schemas/pinctrl/pinmux-node.yaml
> >
> > Don't these properties apply to the child nodes?
> >
>
> They do, but not all properties defined in those schema files are
> applicable for this binding. I have marked those which can be applied
> in the node patterns.
Then additionalProperties is appropriate.
> > > +
> > > +patternProperties:
> > > + "^(pin|gpio).":
> > > + type: object
> >
> > additionalProperties: false
>
> I will move additionalProperties here then.
No, moving it is wrong. You need it here AND in the parent node.
Rob
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-12 15:33 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Chanwoo Choi, Alexandre Belloni, linux-gpio, devicetree,
linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312152057.GA3156966-robh@kernel.org>
чт, 12 бер. 2026 р. о 17:20 Rob Herring <robh@kernel.org> пише:
>
> On Thu, Mar 12, 2026 at 10:52:55AM +0200, Svyatoslav Ryhel wrote:
> > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > TXT to YAML format. This patch does not change any functionality; the
> > bindings remain the same.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> > .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> > 2 files changed, 97 insertions(+), 127 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > new file mode 100644
> > index 000000000000..4e5f997317ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > @@ -0,0 +1,97 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Pinmux controller function for Maxim MAX77620 Power management IC
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + Device has 8 GPIO pins which can be configured as GPIO as well as the
> > + special IO functions.
> > +
> > +allOf:
> > + - $ref: /schemas/pinctrl/pincfg-node.yaml
> > + - $ref: /schemas/pinctrl/pinmux-node.yaml
>
> Don't these properties apply to the child nodes?
>
They do, but not all properties defined in those schema files are
applicable for this binding. I have marked those which can be applied
in the node patterns.
> > +
> > +patternProperties:
> > + "^(pin|gpio).":
> > + type: object
>
> additionalProperties: false
I will move additionalProperties here then.
>
> Or unevaluatedProperties with the $refs moved here.
>
> > +
> > + properties:
> > + pins:
> > + items:
> > + enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ]
> > +
> > + function:
> > + items:
> > + enum: [ gpio, lpm-control-in, fps-out, 32k-out1, sd0-dvs-in, sd1-dvs-in,
> > + reference-out ]
> > +
> > + drive-push-pull: true
> > + drive-open-drain: true
> > + bias-pull-up: true
> > + bias-pull-down: true
> > +
> > + maxim,active-fps-source:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + FPS source for the GPIOs to get enabled/disabled when system is in
> > + active state. Valid values are:
> > + - MAX77620_FPS_SRC_0: FPS source is FPS0.
> > + - MAX77620_FPS_SRC_1: FPS source is FPS1
> > + - MAX77620_FPS_SRC_2: FPS source is FPS2
> > + - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and
> > + it gets enabled/disabled by register access.
> > + Absence of this property will leave the FPS configuration register
> > + for that GPIO to default configuration.
> > +
> > + maxim,active-fps-power-up-slot:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Sequencing event slot number on which the GPIO get enabled when
> > + master FPS input event set to HIGH. This is applicable if FPS source
> > + is selected as FPS0, FPS1 or FPS2.
> > + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> > +
> > + maxim,active-fps-power-down-slot:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Sequencing event slot number on which the GPIO get disabled when
> > + master FPS input event set to LOW. This is applicable if FPS source
> > + is selected as FPS0, FPS1 or FPS2.
> > + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> > +
> > + maxim,suspend-fps-source:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This is same as property "maxim,active-fps-source" but value get
> > + configured when system enters in to suspend state.
> > +
> > + maxim,suspend-fps-power-up-slot:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This is same as property "maxim,active-fps-power-up-slot" but this
> > + value get configured into FPS configuration register when system
> > + enters into suspend. This is applicable if suspend state FPS source
> > + is selected as FPS0, FPS1 or FPS2.
> > + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> > +
> > + maxim,suspend-fps-power-down-slot:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This is same as property "maxim,active-fps-power-down-slot" but this
> > + value get configured into FPS configuration register when system
> > + enters into suspend. This is applicable if suspend state FPS source
> > + is selected as FPS0, FPS1 or FPS2.
> > + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> > +
> > + required:
> > + - pins
> > +
> > +additionalProperties: false
> > +
> > +# see maxim,max77620.yaml for an example
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> > deleted file mode 100644
> > index 28fbca180068..000000000000
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> > +++ /dev/null
> > @@ -1,127 +0,0 @@
> > -Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
> > -
> > -Device has 8 GPIO pins which can be configured as GPIO as well as the
> > -special IO functions.
> > -
> > -Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt>
> > -for details of the common pinctrl bindings used by client devices,
> > -including the meaning of the phrase "pin configuration node".
> > -
> > -Optional Pinmux properties:
> > ---------------------------
> > -Following properties are required if default setting of pins are required
> > -at boot.
> > -- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
> > -- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
> > - <pinctrl-bindings.txt>.
> > -
> > -The pin configurations are defined as child of the pinctrl states node. Each
> > -sub-node have following properties:
> > -
> > -Required properties:
> > -------------------
> > -- pins: List of pins. Valid values of pins properties are:
> > - gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
> > -
> > -Optional properties:
> > --------------------
> > -Following are optional properties defined as pinmux DT binding document
> > -<pinctrl-bindings.txt>. Absence of properties will leave the configuration
> > -on default.
> > - function,
> > - drive-push-pull,
> > - drive-open-drain,
> > - bias-pull-up,
> > - bias-pull-down.
> > -
> > -Valid values for function properties are:
> > - gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
> > - reference-out
> > -
> > -There are also customised properties for the GPIO1, GPIO2 and GPIO3. These
> > -customised properties are required to configure FPS configuration parameters
> > -of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
> > -detail of Flexible Power Sequence (FPS).
> > -
> > -- maxim,active-fps-source: FPS source for the GPIOs to get
> > - enabled/disabled when system is in
> > - active state. Valid values are:
> > - - MAX77620_FPS_SRC_0,
> > - FPS source is FPS0.
> > - - MAX77620_FPS_SRC_1,
> > - FPS source is FPS1
> > - - MAX77620_FPS_SRC_2 and
> > - FPS source is FPS2
> > - - MAX77620_FPS_SRC_NONE.
> > - GPIO is not controlled
> > - by FPS events and it gets
> > - enabled/disabled by register
> > - access.
> > - Absence of this property will leave
> > - the FPS configuration register for that
> > - GPIO to default configuration.
> > -
> > -- maxim,active-fps-power-up-slot: Sequencing event slot number on which
> > - the GPIO get enabled when
> > - master FPS input event set to HIGH.
> > - Valid values are 0 to 7.
> > - This is applicable if FPS source is
> > - selected as FPS0, FPS1 or FPS2.
> > -
> > -- maxim,active-fps-power-down-slot: Sequencing event slot number on which
> > - the GPIO get disabled when master
> > - FPS input event set to LOW.
> > - Valid values are 0 to 7.
> > - This is applicable if FPS source is
> > - selected as FPS0, FPS1 or FPS2.
> > -
> > -- maxim,suspend-fps-source: This is same as property
> > - "maxim,active-fps-source" but value
> > - get configured when system enters in
> > - to suspend state.
> > -
> > -- maxim,suspend-fps-power-up-slot: This is same as property
> > - "maxim,active-fps-power-up-slot" but
> > - this value get configured into FPS
> > - configuration register when system
> > - enters into suspend.
> > - This is applicable if suspend state
> > - FPS source is selected as FPS0, FPS1 or
> > -
> > -- maxim,suspend-fps-power-down-slot: This is same as property
> > - "maxim,active-fps-power-down-slot" but
> > - this value get configured into FPS
> > - configuration register when system
> > - enters into suspend.
> > - This is applicable if suspend state
> > - FPS source is selected as FPS0, FPS1 or
> > - FPS2.
> > -
> > -Example:
> > ---------
> > -#include <dt-bindings/mfd/max77620.h>
> > -...
> > -max77620@3c {
> > -
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&spmic_default>;
> > -
> > - spmic_default: pinmux@0 {
> > - pin_gpio0 {
> > - pins = "gpio0";
> > - function = "gpio";
> > - };
> > -
> > - pin_gpio1 {
> > - pins = "gpio1";
> > - function = "fps-out";
> > - maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
> > - };
> > -
> > - pin_gpio2 {
> > - pins = "gpio2";
> > - function = "fps-out";
> > - maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
> > - };
> > - };
> > -};
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH v4 4/5] dt-bindings: mfd: max77620: document optional RTC address for MAX77663
From: Rob Herring (Arm) @ 2026-03-12 15:31 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-gpio, Krzysztof Kozlowski, Zhang Rui, Bartosz Golaszewski,
Lukasz Luba, Alexandre Belloni, linux-kernel, linux-rtc,
Daniel Lezcano, Chanwoo Choi, Mark Brown, devicetree,
Liam Girdwood, linux-pm, Rafael J. Wysocki, Lee Jones,
Linus Walleij, Conor Dooley
In-Reply-To: <20260312085258.11431-5-clamor95@gmail.com>
On Thu, 12 Mar 2026 10:52:57 +0200, Svyatoslav Ryhel wrote:
> Document an optional second I2C address for the MAX77663 PMIC's RTC
> device, to be used if the MAX77663 RTC is located at a non-default I2C
> address.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/mfd/maxim,max77620.yaml | 22 ++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 3/5] dt-bindings: mfd: max77620: convert to DT schema
From: Rob Herring (Arm) @ 2026-03-12 15:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lukasz Luba, Conor Dooley, Linus Walleij, Rafael J. Wysocki,
Zhang Rui, Chanwoo Choi, Alexandre Belloni, linux-pm,
Krzysztof Kozlowski, Liam Girdwood, linux-kernel,
Bartosz Golaszewski, linux-gpio, Daniel Lezcano, linux-rtc,
Lee Jones, Mark Brown, devicetree
In-Reply-To: <20260312085258.11431-4-clamor95@gmail.com>
On Thu, 12 Mar 2026 10:52:56 +0200, Svyatoslav Ryhel wrote:
> Convert max77620 devicetree bindings from TXT to YAML format. This patch
> does not change any functionality; the bindings remain the same. The
> thermal bindings are incorporated into the binding. GPIO controller
> function in MAX77620 has no dedicated node and is folded into the parent
> node itself.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/gpio/trivial-gpio.yaml | 2 -
> .../devicetree/bindings/mfd/max77620.txt | 162 -------
> .../bindings/mfd/maxim,max77620.yaml | 424 ++++++++++++++++++
> .../bindings/thermal/max77620_thermal.txt | 70 ---
> 4 files changed, 424 insertions(+), 234 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
> delete mode 100644 Documentation/devicetree/bindings/thermal/max77620_thermal.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Rob Herring @ 2026-03-12 15:20 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Chanwoo Choi, Alexandre Belloni, linux-gpio, devicetree,
linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-3-clamor95@gmail.com>
On Thu, Mar 12, 2026 at 10:52:55AM +0200, Svyatoslav Ryhel wrote:
> Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> 2 files changed, 97 insertions(+), 127 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> new file mode 100644
> index 000000000000..4e5f997317ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Pinmux controller function for Maxim MAX77620 Power management IC
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + Device has 8 GPIO pins which can be configured as GPIO as well as the
> + special IO functions.
> +
> +allOf:
> + - $ref: /schemas/pinctrl/pincfg-node.yaml
> + - $ref: /schemas/pinctrl/pinmux-node.yaml
Don't these properties apply to the child nodes?
> +
> +patternProperties:
> + "^(pin|gpio).":
> + type: object
additionalProperties: false
Or unevaluatedProperties with the $refs moved here.
> +
> + properties:
> + pins:
> + items:
> + enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ]
> +
> + function:
> + items:
> + enum: [ gpio, lpm-control-in, fps-out, 32k-out1, sd0-dvs-in, sd1-dvs-in,
> + reference-out ]
> +
> + drive-push-pull: true
> + drive-open-drain: true
> + bias-pull-up: true
> + bias-pull-down: true
> +
> + maxim,active-fps-source:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + FPS source for the GPIOs to get enabled/disabled when system is in
> + active state. Valid values are:
> + - MAX77620_FPS_SRC_0: FPS source is FPS0.
> + - MAX77620_FPS_SRC_1: FPS source is FPS1
> + - MAX77620_FPS_SRC_2: FPS source is FPS2
> + - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and
> + it gets enabled/disabled by register access.
> + Absence of this property will leave the FPS configuration register
> + for that GPIO to default configuration.
> +
> + maxim,active-fps-power-up-slot:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Sequencing event slot number on which the GPIO get enabled when
> + master FPS input event set to HIGH. This is applicable if FPS source
> + is selected as FPS0, FPS1 or FPS2.
> + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> + maxim,active-fps-power-down-slot:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Sequencing event slot number on which the GPIO get disabled when
> + master FPS input event set to LOW. This is applicable if FPS source
> + is selected as FPS0, FPS1 or FPS2.
> + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> + maxim,suspend-fps-source:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + This is same as property "maxim,active-fps-source" but value get
> + configured when system enters in to suspend state.
> +
> + maxim,suspend-fps-power-up-slot:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + This is same as property "maxim,active-fps-power-up-slot" but this
> + value get configured into FPS configuration register when system
> + enters into suspend. This is applicable if suspend state FPS source
> + is selected as FPS0, FPS1 or FPS2.
> + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> + maxim,suspend-fps-power-down-slot:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + This is same as property "maxim,active-fps-power-down-slot" but this
> + value get configured into FPS configuration register when system
> + enters into suspend. This is applicable if suspend state FPS source
> + is selected as FPS0, FPS1 or FPS2.
> + enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> + required:
> + - pins
> +
> +additionalProperties: false
> +
> +# see maxim,max77620.yaml for an example
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> deleted file mode 100644
> index 28fbca180068..000000000000
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> +++ /dev/null
> @@ -1,127 +0,0 @@
> -Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
> -
> -Device has 8 GPIO pins which can be configured as GPIO as well as the
> -special IO functions.
> -
> -Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt>
> -for details of the common pinctrl bindings used by client devices,
> -including the meaning of the phrase "pin configuration node".
> -
> -Optional Pinmux properties:
> ---------------------------
> -Following properties are required if default setting of pins are required
> -at boot.
> -- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
> -- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
> - <pinctrl-bindings.txt>.
> -
> -The pin configurations are defined as child of the pinctrl states node. Each
> -sub-node have following properties:
> -
> -Required properties:
> -------------------
> -- pins: List of pins. Valid values of pins properties are:
> - gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
> -
> -Optional properties:
> --------------------
> -Following are optional properties defined as pinmux DT binding document
> -<pinctrl-bindings.txt>. Absence of properties will leave the configuration
> -on default.
> - function,
> - drive-push-pull,
> - drive-open-drain,
> - bias-pull-up,
> - bias-pull-down.
> -
> -Valid values for function properties are:
> - gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
> - reference-out
> -
> -There are also customised properties for the GPIO1, GPIO2 and GPIO3. These
> -customised properties are required to configure FPS configuration parameters
> -of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
> -detail of Flexible Power Sequence (FPS).
> -
> -- maxim,active-fps-source: FPS source for the GPIOs to get
> - enabled/disabled when system is in
> - active state. Valid values are:
> - - MAX77620_FPS_SRC_0,
> - FPS source is FPS0.
> - - MAX77620_FPS_SRC_1,
> - FPS source is FPS1
> - - MAX77620_FPS_SRC_2 and
> - FPS source is FPS2
> - - MAX77620_FPS_SRC_NONE.
> - GPIO is not controlled
> - by FPS events and it gets
> - enabled/disabled by register
> - access.
> - Absence of this property will leave
> - the FPS configuration register for that
> - GPIO to default configuration.
> -
> -- maxim,active-fps-power-up-slot: Sequencing event slot number on which
> - the GPIO get enabled when
> - master FPS input event set to HIGH.
> - Valid values are 0 to 7.
> - This is applicable if FPS source is
> - selected as FPS0, FPS1 or FPS2.
> -
> -- maxim,active-fps-power-down-slot: Sequencing event slot number on which
> - the GPIO get disabled when master
> - FPS input event set to LOW.
> - Valid values are 0 to 7.
> - This is applicable if FPS source is
> - selected as FPS0, FPS1 or FPS2.
> -
> -- maxim,suspend-fps-source: This is same as property
> - "maxim,active-fps-source" but value
> - get configured when system enters in
> - to suspend state.
> -
> -- maxim,suspend-fps-power-up-slot: This is same as property
> - "maxim,active-fps-power-up-slot" but
> - this value get configured into FPS
> - configuration register when system
> - enters into suspend.
> - This is applicable if suspend state
> - FPS source is selected as FPS0, FPS1 or
> -
> -- maxim,suspend-fps-power-down-slot: This is same as property
> - "maxim,active-fps-power-down-slot" but
> - this value get configured into FPS
> - configuration register when system
> - enters into suspend.
> - This is applicable if suspend state
> - FPS source is selected as FPS0, FPS1 or
> - FPS2.
> -
> -Example:
> ---------
> -#include <dt-bindings/mfd/max77620.h>
> -...
> -max77620@3c {
> -
> - pinctrl-names = "default";
> - pinctrl-0 = <&spmic_default>;
> -
> - spmic_default: pinmux@0 {
> - pin_gpio0 {
> - pins = "gpio0";
> - function = "gpio";
> - };
> -
> - pin_gpio1 {
> - pins = "gpio1";
> - function = "fps-out";
> - maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
> - };
> -
> - pin_gpio2 {
> - pins = "gpio2";
> - function = "fps-out";
> - maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
> - };
> - };
> -};
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v4 1/5] regulator: dt-bindings: regulator-max77620: convert to DT schema
From: Rob Herring (Arm) @ 2026-03-12 15:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Liam Girdwood, Mark Brown, Rafael J. Wysocki, Linus Walleij,
Chanwoo Choi, linux-kernel, linux-pm, Lee Jones,
Krzysztof Kozlowski, Bartosz Golaszewski, Lukasz Luba, linux-rtc,
linux-gpio, Conor Dooley, Alexandre Belloni, devicetree,
Zhang Rui, Daniel Lezcano
In-Reply-To: <20260312085258.11431-2-clamor95@gmail.com>
On Thu, 12 Mar 2026 10:52:54 +0200, Svyatoslav Ryhel wrote:
> Convert regulator-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
> .../regulator/maxim,max77620-regulator.yaml | 99 ++++++++
> .../bindings/regulator/regulator-max77620.txt | 222 ------------------
> 2 files changed, 99 insertions(+), 222 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
> delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: rtc: mpfs-rtc: permit resets
From: Alexandre Belloni @ 2026-03-12 14:34 UTC (permalink / raw)
To: linux-rtc, Conor Dooley
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daire McNamara, devicetree, linux-kernel
In-Reply-To: <20260303-flounder-slate-dd69766990ce@spud>
On Tue, 03 Mar 2026 16:36:33 +0000, Conor Dooley wrote:
> The RTC on mpfs and pic64gx has a reset pin, but until now this has been
> undocumented because platform firmware takes the RTC out of reset on
> first-party boards (or those using modified versions of the vendor
> firmware), but not all boards may take this approach. Permit providing a
> reset in devicetree for Linux, or other devicetree-consuming software,
> to use.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: rtc: mpfs-rtc: permit resets
https://git.kernel.org/abelloni/c/cbf39bfd4bf9
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 0/6] Remove use of i2c_match_id in RTC
From: Alexandre Belloni @ 2026-03-12 14:16 UTC (permalink / raw)
To: Andrew Davis; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
On Thu, 05 Mar 2026 13:35:39 -0600, Andrew Davis wrote:
> RTC subsystem is one of the last still using i2c_match_id().
> This is a v2 but nothing is changed from last time. If I'm
> not sending this to the right folks let me know.
>
> Thanks,
> Andrew
>
> [...]
Applied, thanks!
[1/6] rtc: abx80x: Remove use of i2c_match_id()
https://git.kernel.org/abelloni/c/652dc1328110
[2/6] rtc: m41t80: Remove use of i2c_match_id()
https://git.kernel.org/abelloni/c/aade5f4bf9e2
[3/6] rtc: pcf2127: Remove use of i2c_match_id()
https://git.kernel.org/abelloni/c/c85ac0b4d7c5
[4/6] rtc: rs5c372: Remove use of i2c_match_id()
https://git.kernel.org/abelloni/c/022bfe69575d
[5/6] rtc: rv8803: Remove use of i2c_match_id()
https://git.kernel.org/abelloni/c/c79e6131b17e
[6/6] rtc: rx8025: Remove use of i2c_match_id()
https://git.kernel.org/abelloni/c/fbae853a00b4
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 5/5] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-03-12 8:52 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-1-clamor95@gmail.com>
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/rtc/rtc-max77686.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 69ea3ce75b5a..3cdfd78a07cc 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -686,6 +686,11 @@ static int max77686_rtc_init_reg(struct max77686_rtc_info *info)
return ret;
}
+static void max77686_rtc_release_dev(void *client)
+{
+ i2c_unregister_device(client);
+}
+
static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
{
struct device *parent = info->dev->parent;
@@ -713,12 +718,17 @@ static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
goto add_rtc_irq;
}
- client = devm_i2c_new_dummy_device(info->dev, parent_i2c->adapter,
- info->drv_data->rtc_i2c_addr);
+ client = i2c_new_ancillary_device(parent_i2c, "rtc",
+ info->drv_data->rtc_i2c_addr);
if (IS_ERR(client))
return dev_err_probe(info->dev, PTR_ERR(client),
"Failed to allocate I2C device for RTC\n");
+ ret = devm_add_action_or_reset(info->dev, max77686_rtc_release_dev,
+ client);
+ if (ret)
+ return ret;
+
info->rtc_regmap = devm_regmap_init_i2c(client,
info->drv_data->regmap_config);
if (IS_ERR(info->rtc_regmap))
--
2.51.0
^ permalink raw reply related
* [PATCH v4 4/5] dt-bindings: mfd: max77620: document optional RTC address for MAX77663
From: Svyatoslav Ryhel @ 2026-03-12 8:52 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-1-clamor95@gmail.com>
Document an optional second I2C address for the MAX77663 PMIC's RTC
device, to be used if the MAX77663 RTC is located at a non-default I2C
address.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../bindings/mfd/maxim,max77620.yaml | 22 ++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
index 85d7fe0f9f85..602711865274 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
@@ -17,7 +17,17 @@ properties:
- maxim,max77663
reg:
- maxItems: 1
+ description:
+ Can contain an optional second I2C address pointing to the PMIC's
+ RTC device. If no RTC address is provided, a default address specific
+ to this PMIC will be used.
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pmic
+ - const: rtc
interrupts:
maxItems: 1
@@ -192,6 +202,16 @@ allOf:
maxim,suspend-fps-time-period-us:
enum: [40, 80, 160, 320, 640, 1280, 2560, 5120]
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: maxim,max77663
+ then:
+ properties:
+ reg-names: false
+
required:
- compatible
- reg
--
2.51.0
^ permalink raw reply related
* [PATCH v4 3/5] dt-bindings: mfd: max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-12 8:52 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-1-clamor95@gmail.com>
Convert max77620 devicetree bindings from TXT to YAML format. This patch
does not change any functionality; the bindings remain the same. The
thermal bindings are incorporated into the binding. GPIO controller
function in MAX77620 has no dedicated node and is folded into the parent
node itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../bindings/gpio/trivial-gpio.yaml | 2 -
.../devicetree/bindings/mfd/max77620.txt | 162 -------
.../bindings/mfd/maxim,max77620.yaml | 424 ++++++++++++++++++
.../bindings/thermal/max77620_thermal.txt | 70 ---
4 files changed, 424 insertions(+), 234 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
delete mode 100644 Documentation/devicetree/bindings/thermal/max77620_thermal.txt
diff --git a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
index 3f4bbd57fc52..fe9b14a72d69 100644
--- a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
@@ -27,7 +27,6 @@ properties:
- gateworks,pld-gpio
- ibm,ppc4xx-gpio
- loongson,ls1x-gpio
- - maxim,max77620
- nintendo,hollywood-gpio
- nxp,pca9570
- nxp,pca9571
@@ -86,7 +85,6 @@ allOf:
compatible:
contains:
enum:
- - maxim,max77620
- rockchip,rk3328-grf-gpio
- ti,lp3943-gpio
- ti,palmas-gpio
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
deleted file mode 100644
index 5a642a51d58e..000000000000
--- a/Documentation/devicetree/bindings/mfd/max77620.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-MAX77620 Power management IC from Maxim Semiconductor.
-
-Required properties:
--------------------
-- compatible: Must be one of
- "maxim,max77620"
- "maxim,max20024"
- "maxim,max77663"
-- reg: I2C device address.
-
-Optional properties:
--------------------
-- interrupts: The interrupt on the parent the controller is
- connected to.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: is <2> and their usage is compliant to the 2 cells
- variant of <../interrupt-controller/interrupts.txt>
- IRQ numbers for different interrupt source of MAX77620
- are defined at dt-bindings/mfd/max77620.h.
-
-- system-power-controller: Indicates that this PMIC is controlling the
- system power, see [1] for more details.
-
-[1] Documentation/devicetree/bindings/power/power-controller.txt
-
-Optional subnodes and their properties:
-=======================================
-
-Flexible power sequence configurations:
---------------------------------------
-The Flexible Power Sequencer (FPS) allows each regulator to power up under
-hardware or software control. Additionally, each regulator can power on
-independently or among a group of other regulators with an adjustable power-up
-and power-down delays (sequencing). GPIO1, GPIO2, and GPIO3 can be programmed
-to be part of a sequence allowing external regulators to be sequenced along
-with internal regulators. 32KHz clock can be programmed to be part of a
-sequence.
-
-The flexible sequencing structure consists of two hardware enable inputs
-(EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2.
-Each master sequencing timer is programmable through its configuration
-register to have a hardware enable source (EN1 or EN2) or a software enable
-source (SW). When enabled/disabled, the master sequencing timer generates
-eight sequencing events on different time periods called slots. The time
-period between each event is programmable within the configuration register.
-Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power
-sequence slave register which allows its enable source to be specified as
-a flexible power sequencer timer or a software bit. When a FPS source of
-regulators, GPIOs and clocks specifies the enable source to be a flexible
-power sequencer, the power up and power down delays can be specified in
-the regulators, GPIOs and clocks flexible power sequencer configuration
-registers.
-
-When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz
-clock are set into following state at the sequencing event that
-corresponds to its flexible sequencer configuration register.
- Sleep state: In this state, regulators, GPIOs
- and 32KHz clock get disabled at
- the sequencing event.
- Global Low Power Mode (GLPM): In this state, regulators are set in
- low power mode at the sequencing event.
-
-The configuration parameters of FPS is provided through sub-node "fps"
-and their child for FPS specific. The child node name for FPS are "fps0",
-"fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively.
-
-The FPS configurations like FPS source, power up and power down slots for
-regulators, GPIOs and 32kHz clocks are provided in their respective
-configuration nodes which is explained in respective sub-system DT
-binding document.
-
-There is need for different FPS configuration parameters based on system
-state like when system state changed from active to suspend or active to
-power off (shutdown).
-
-Optional properties:
--------------------
--maxim,fps-event-source: u32, FPS event source like external
- hardware input to PMIC i.e. EN0, EN1 or
- software (SW).
- The macros are defined on
- dt-bindings/mfd/max77620.h
- for different control source.
- - MAX77620_FPS_EVENT_SRC_EN0
- for hardware input pin EN0.
- - MAX77620_FPS_EVENT_SRC_EN1
- for hardware input pin EN1.
- - MAX77620_FPS_EVENT_SRC_SW
- for software control.
-
--maxim,shutdown-fps-time-period-us: u32, FPS time period in microseconds
- when system enters in to shutdown
- state.
-
--maxim,suspend-fps-time-period-us: u32, FPS time period in microseconds
- when system enters in to suspend state.
-
--maxim,device-state-on-disabled-event: u32, describe the PMIC state when FPS
- event cleared (set to LOW) whether it
- should go to sleep state or low-power
- state. Following are valid values:
- - MAX77620_FPS_INACTIVE_STATE_SLEEP
- to set the PMIC state to sleep.
- - MAX77620_FPS_INACTIVE_STATE_LOW_POWER
- to set the PMIC state to low
- power.
- Absence of this property or other value
- will not change device state when FPS
- event get cleared.
-
-Here supported time periods by device in microseconds are as follows:
-MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds.
-MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
-MAX77663 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
-
--maxim,power-ok-control: configure map power ok bit
- 1: Enables POK(Power OK) to control nRST_IO and GPIO1
- POK function.
- 0: Disables POK control.
- if property missing, do not configure MPOK bit.
- If POK mapping is enabled for GPIO1/nRST_IO then,
- GPIO1/nRST_IO pins are HIGH only if all rails
- that have POK control enabled are HIGH.
- If any of the rails goes down(which are enabled for POK
- control) then, GPIO1/nRST_IO goes LOW.
- this property is valid for max20024 only.
-
-For DT binding details of different sub modules like GPIO, pincontrol,
-regulator, power, please refer respective device-tree binding document
-under their respective sub-system directories.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-
-max77620@3c {
- compatible = "maxim,max77620";
- reg = <0x3c>;
-
- interrupt-parent = <&intc>;
- interrupts = <0 86 IRQ_TYPE_NONE>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- fps {
- fps0 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
- };
-
- fps1 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
- };
-
- fps2 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
new file mode 100644
index 000000000000..85d7fe0f9f85
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
@@ -0,0 +1,424 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max77620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX77620 Power management IC from Maxim Semiconductor
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max20024
+ - maxim,max77620
+ - maxim,max77663
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ Device has 8 GPIO pins which can be configured as GPIO as well as
+ the special IO functions. The first cell is the pin number, and the
+ second cell is used to specify the gpio polarity (GPIO_ACTIVE_HIGH or
+ GPIO_ACTIVE_LOW).
+
+ system-power-controller: true
+
+ "#thermal-sensor-cells":
+ const: 0
+ description:
+ Maxim Semiconductor MAX77620 supports alarm interrupts when its
+ die temperature crosses 120C and 140C. These threshold temperatures
+ are not configurable. Device does not provide the real temperature
+ of die other than just indicating whether temperature is above or
+ below threshold level.
+
+ fps:
+ type: object
+ additionalProperties: false
+ description: |
+ The Flexible Power Sequencer (FPS) allows each regulator to power up
+ under hardware or software control. Additionally, each regulator can
+ power on independently or among a group of other regulators with an
+ adjustable power-up and power-down delays (sequencing). GPIO1, GPIO2,
+ and GPIO3 can be programmed to be part of a sequence allowing external
+ regulators to be sequenced along with internal regulators. 32KHz clock
+ can be programmed to be part of a sequence.
+
+ The flexible sequencing structure consists of two hardware enable inputs
+ (EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2.
+ Each master sequencing timer is programmable through its configuration
+ register to have a hardware enable source (EN1 or EN2) or a software enable
+ source (SW). When enabled/disabled, the master sequencing timer generates
+ eight sequencing events on different time periods called slots. The time
+ period between each event is programmable within the configuration register.
+ Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power
+ sequence slave register which allows its enable source to be specified as
+ a flexible power sequencer timer or a software bit. When a FPS source of
+ regulators, GPIOs and clocks specifies the enable source to be a flexible
+ power sequencer, the power up and power down delays can be specified in
+ the regulators, GPIOs and clocks flexible power sequencer configuration
+ registers.
+
+ When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz clock
+ are set into following state at the sequencing event that corresponds
+ to its flexible sequencer configuration register.
+
+ Sleep state: In this state, regulators, GPIOs and 32KHz clock get disabled
+ at the sequencing event.
+ Global Low Power Mode (GLPM): In this state, regulators are set in low
+ power mode at the sequencing event.
+
+ The configuration parameters of FPS is provided through sub-node "fps"
+ and their child for FPS specific. The child node name for FPS are "fps0",
+ "fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively.
+
+ The FPS configurations like FPS source, power up and power down slots for
+ regulators, GPIOs and 32kHz clocks are provided in their respective
+ configuration nodes which is explained in respective sub-system DT
+ binding document.
+
+ There is need for different FPS configuration parameters based on system
+ state like when system state changed from active to suspend or active to
+ power off (shutdown).
+
+ patternProperties:
+ "^fps[0-2]$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ maxim,fps-event-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ FPS event source like external hardware input to PMIC i.e. EN0, EN1
+ or software (SW).
+
+ The macros are defined on dt-bindings/mfd/max77620.h for different
+ control source.
+ - MAX77620_FPS_EVENT_SRC_EN0 for hardware input pin EN0.
+ - MAX77620_FPS_EVENT_SRC_EN1 for hardware input pin EN1.
+ - MAX77620_FPS_EVENT_SRC_SW for software control.
+
+ maxim,shutdown-fps-time-period-us:
+ description:
+ FPS time period in microseconds when system enters in to shutdown state.
+
+ maxim,suspend-fps-time-period-us:
+ description:
+ FPS time period in microseconds when system enters in to suspend state.
+
+ maxim,device-state-on-disabled-event:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Describe the PMIC state when FPS event cleared (set to LOW) whether it
+ should go to sleep state or low-power state. Following are valid values:
+ - MAX77620_FPS_INACTIVE_STATE_SLEEP to set the PMIC state to sleep.
+ - MAX77620_FPS_INACTIVE_STATE_LOW_POWER to set the PMIC state to low
+ power.
+ Absence of this property or other value will not change device state
+ when FPS event get cleared.
+
+ maxim,power-ok-control:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Configure map power ok bit
+
+ 1: Enables POK(Power OK) to control nRST_IO and GPIO1 POK function.
+ 0: Disables POK control.
+
+ If property missing, do not configure MPOK bit. If POK mapping is
+ enabled for GPIO1/nRST_IO then, GPIO1/nRST_IO pins are HIGH only if
+ all rails that have POK control enabled are HIGH. If any of the rails
+ goes down (which are enabled for POK control) then, GPIO1/nRST_IO
+ goes LOW.
+ enum: [0, 1]
+
+ pinmux:
+ $ref: /schemas/pinctrl/maxim,max77620-pinctrl.yaml
+
+ regulators:
+ $ref: /schemas/regulator/maxim,max77620-regulator.yaml
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max20024
+ - maxim,max77663
+ then:
+ properties:
+ "#thermal-sensor-cells": false
+ fps:
+ patternProperties:
+ "^fps[0-2]$":
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [20, 40, 80, 160, 320, 640, 1280, 2540]
+ maxim,suspend-fps-time-period-us:
+ enum: [20, 40, 80, 160, 320, 640, 1280, 2540]
+ maxim,power-ok-control: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max77620
+ then:
+ properties:
+ fps:
+ patternProperties:
+ "^fps[0-2]$":
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [40, 80, 160, 320, 640, 1280, 2560, 5120]
+ maxim,suspend-fps-time-period-us:
+ enum: [40, 80, 160, 320, 640, 1280, 2560, 5120]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/max77620.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3c {
+ compatible = "maxim,max77620";
+ reg = <0x3c>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <86 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ system-power-controller;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&max77620_default>;
+
+ max77620_default: pinmux {
+ gpio0 {
+ pins = "gpio0";
+ function = "gpio";
+ };
+
+ gpio1 {
+ pins = "gpio1";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ gpio2 {
+ pins = "gpio2";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ gpio3 {
+ pins = "gpio3";
+ function = "gpio";
+ };
+
+ gpio4 {
+ pins = "gpio4";
+ function = "32k-out1";
+ };
+
+ gpio5-6 {
+ pins = "gpio5", "gpio6";
+ function = "gpio";
+ drive-push-pull = <1>;
+ };
+
+ gpio7 {
+ pins = "gpio7";
+ function = "gpio";
+ };
+ };
+
+ fps {
+ fps0 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
+ };
+
+ fps1 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
+ };
+
+ fps2 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>;
+ };
+ };
+
+ regulators {
+ in-sd0-supply = <&vdd_5v0_vbus>;
+ in-sd1-supply = <&vdd_5v0_vbus>;
+ in-sd2-supply = <&vdd_5v0_vbus>;
+ in-sd3-supply = <&vdd_5v0_vbus>;
+
+ in-ldo0-1-supply = <&vdd_1v8_vio>;
+ in-ldo2-supply = <&vdd_3v3_vbat>;
+ in-ldo3-5-supply = <&vdd_3v3_vbat>;
+ in-ldo4-6-supply = <&vdd_3v3_vbat>;
+ in-ldo7-8-supply = <&vdd_1v8_vio>;
+
+ sd0 {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ sd1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ vdd_1v8_vio: sd2 {
+ regulator-name = "vdd_1v8_gen";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ sd3 {
+ regulator-name = "vddio_ddr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo0 {
+ regulator-name = "avdd_pll";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ ldo1 {
+ regulator-name = "vdd_ddr_hs";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo2 {
+ regulator-name = "avdd_usb";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo3 {
+ regulator-name = "vdd_sdmmc3";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo4 {
+ regulator-name = "vdd_rtc";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ ldo5 {
+ regulator-name = "vdd_ddr_rx";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ ldo6 {
+ regulator-name = "avdd_osc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo7 {
+ regulator-name = "vdd_1v2_mhl";
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1250000>;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo8 {
+ regulator-name = "avdd_dsi_csi";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt
deleted file mode 100644
index 82ed5d487966..000000000000
--- a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Maxim Semiconductor MAX77620 supports alarm interrupts when its
-die temperature crosses 120C and 140C. These threshold temperatures
-are not configurable. Device does not provide the real temperature
-of die other than just indicating whether temperature is above or
-below threshold level.
-
-Required properties:
--------------------
-#thermal-sensor-cells: For more details, please refer to
- <devicetree/bindings/thermal/thermal-sensor.yaml>
- The value must be 0.
-
-For more details, please refer generic thermal DT binding document
-<devicetree/bindings/thermal/thermal*.yaml>.
-
-Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding
-document for the MAX77620.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-#include <dt-bindings/thermal/thermal.h>
-...
-
-i2c@7000d000 {
- spmic: max77620@3c {
- compatible = "maxim,max77620";
- :::::
- #thermal-sensor-cells = <0>;
- :::
- };
-};
-
-cool_dev: cool-dev {
- compatible = "cooling-dev";
- #cooling-cells = <2>;
-};
-
-thermal-zones {
- PMIC-Die {
- polling-delay = <0>;
- polling-delay-passive = <0>;
- thermal-sensors = <&spmic>;
-
- trips {
- pmic_die_warn_temp_thresh: hot-die {
- temperature = <120000>;
- type = "hot";
- hysteresis = <0>;
- };
-
- pmic_die_cirt_temp_thresh: cirtical-die {
- temperature = <140000>;
- type = "critical";
- hysteresis = <0>;
- };
- };
-
- cooling-maps {
- map0 {
- trip = <&pmic_die_warn_temp_thresh>;
- cooling-device = <&cool_dev THERMAL_NO_LIMIT
- THERMAL_NO_LIMIT>;
- contribution = <100>;
- };
- };
- };
-};
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-12 8:52 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-1-clamor95@gmail.com>
Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
.../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
2 files changed, 97 insertions(+), 127 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
new file mode 100644
index 000000000000..4e5f997317ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Pinmux controller function for Maxim MAX77620 Power management IC
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ Device has 8 GPIO pins which can be configured as GPIO as well as the
+ special IO functions.
+
+allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+
+patternProperties:
+ "^(pin|gpio).":
+ type: object
+
+ properties:
+ pins:
+ items:
+ enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ]
+
+ function:
+ items:
+ enum: [ gpio, lpm-control-in, fps-out, 32k-out1, sd0-dvs-in, sd1-dvs-in,
+ reference-out ]
+
+ drive-push-pull: true
+ drive-open-drain: true
+ bias-pull-up: true
+ bias-pull-down: true
+
+ maxim,active-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ FPS source for the GPIOs to get enabled/disabled when system is in
+ active state. Valid values are:
+ - MAX77620_FPS_SRC_0: FPS source is FPS0.
+ - MAX77620_FPS_SRC_1: FPS source is FPS1
+ - MAX77620_FPS_SRC_2: FPS source is FPS2
+ - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and
+ it gets enabled/disabled by register access.
+ Absence of this property will leave the FPS configuration register
+ for that GPIO to default configuration.
+
+ maxim,active-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get enabled when
+ master FPS input event set to HIGH. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,active-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get disabled when
+ master FPS input event set to LOW. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-source" but value get
+ configured when system enters in to suspend state.
+
+ maxim,suspend-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-up-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-down-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ required:
+ - pins
+
+additionalProperties: false
+
+# see maxim,max77620.yaml for an example
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
deleted file mode 100644
index 28fbca180068..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has 8 GPIO pins which can be configured as GPIO as well as the
-special IO functions.
-
-Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt>
-for details of the common pinctrl bindings used by client devices,
-including the meaning of the phrase "pin configuration node".
-
-Optional Pinmux properties:
---------------------------
-Following properties are required if default setting of pins are required
-at boot.
-- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
-- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
- <pinctrl-bindings.txt>.
-
-The pin configurations are defined as child of the pinctrl states node. Each
-sub-node have following properties:
-
-Required properties:
-------------------
-- pins: List of pins. Valid values of pins properties are:
- gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
-
-Optional properties:
--------------------
-Following are optional properties defined as pinmux DT binding document
-<pinctrl-bindings.txt>. Absence of properties will leave the configuration
-on default.
- function,
- drive-push-pull,
- drive-open-drain,
- bias-pull-up,
- bias-pull-down.
-
-Valid values for function properties are:
- gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
- reference-out
-
-There are also customised properties for the GPIO1, GPIO2 and GPIO3. These
-customised properties are required to configure FPS configuration parameters
-of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
-detail of Flexible Power Sequence (FPS).
-
-- maxim,active-fps-source: FPS source for the GPIOs to get
- enabled/disabled when system is in
- active state. Valid values are:
- - MAX77620_FPS_SRC_0,
- FPS source is FPS0.
- - MAX77620_FPS_SRC_1,
- FPS source is FPS1
- - MAX77620_FPS_SRC_2 and
- FPS source is FPS2
- - MAX77620_FPS_SRC_NONE.
- GPIO is not controlled
- by FPS events and it gets
- enabled/disabled by register
- access.
- Absence of this property will leave
- the FPS configuration register for that
- GPIO to default configuration.
-
-- maxim,active-fps-power-up-slot: Sequencing event slot number on which
- the GPIO get enabled when
- master FPS input event set to HIGH.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,active-fps-power-down-slot: Sequencing event slot number on which
- the GPIO get disabled when master
- FPS input event set to LOW.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,suspend-fps-source: This is same as property
- "maxim,active-fps-source" but value
- get configured when system enters in
- to suspend state.
-
-- maxim,suspend-fps-power-up-slot: This is same as property
- "maxim,active-fps-power-up-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
-
-- maxim,suspend-fps-power-down-slot: This is same as property
- "maxim,active-fps-power-down-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
- FPS2.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
-
- pinctrl-names = "default";
- pinctrl-0 = <&spmic_default>;
-
- spmic_default: pinmux@0 {
- pin_gpio0 {
- pins = "gpio0";
- function = "gpio";
- };
-
- pin_gpio1 {
- pins = "gpio1";
- function = "fps-out";
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- pin_gpio2 {
- pins = "gpio2";
- function = "fps-out";
- maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
- };
- };
-};
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/5] regulator: dt-bindings: regulator-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-12 8:52 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260312085258.11431-1-clamor95@gmail.com>
Convert regulator-max77620 devicetree bindings for the MAX77620 PMIC from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
.../regulator/maxim,max77620-regulator.yaml | 99 ++++++++
.../bindings/regulator/regulator-max77620.txt | 222 ------------------
2 files changed, 99 insertions(+), 222 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
new file mode 100644
index 000000000000..7118c34961ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/maxim,max77620-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator for MAX77620 Power management IC from Maxim Semiconductor.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ Device has multiple DCDC(sd[0-3]) and LDOs(ldo[0-8]). The input supply
+ of these regulators are defined under parent device node. Details of
+ regulator properties are defined as child node under sub-node "regulators"
+ which is child node of device node.
+
+patternProperties:
+ "^in-(sd[0-3]|ldo(0-1|2|3-5|4-6|7-8))-supply$":
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Input supply for DCDC or LDO
+
+ "^(sd[0-3]|ldo[0-8])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ maxim,active-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ FPS source for the GPIOs to get enabled/disabled when system is in
+ active state. Valid values are:
+ - MAX77620_FPS_SRC_0: FPS source is FPS0.
+ - MAX77620_FPS_SRC_1: FPS source is FPS1
+ - MAX77620_FPS_SRC_2: FPS source is FPS2
+ - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and
+ it gets enabled/disabled by register access.
+ Absence of this property will leave the FPS configuration register
+ for that GPIO to default configuration.
+
+ maxim,active-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get enabled when
+ master FPS input event set to HIGH. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,active-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get disabled when
+ master FPS input event set to LOW. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-source" but value get
+ configured when system enters in to suspend state.
+
+ maxim,suspend-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-up-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-down-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,ramp-rate-setting:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Ramp rate(uV/us) setting to be configured to the device. The platform
+ may have different ramp rate than advertised ramp rate if it has design
+ variation from Maxim's recommended. On this case, platform specific
+ ramp rate is used for ramp time calculation and this property is used
+ for device register configurations. The measured ramp rate of platform
+ is provided by the regulator-ramp-delay.
+
+ Maxim Max77620 supports following ramp delay:
+ SD: 13.75mV/us, 27.5mV/us, 55mV/us
+ LDOs: 5mV/us, 100mV/us
+ enum: [5000, 13750, 27500, 55000, 100000]
+
+additionalProperties: false
+
+# see maxim,max77620.yaml for an example
diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
deleted file mode 100644
index bcf788897e44..000000000000
--- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
+++ /dev/null
@@ -1,222 +0,0 @@
-Regulator DT binding for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has multiple DCDC(sd[0-3] and LDOs(ldo[0-8]). The input supply
-of these regulators are defined under parent device node.
-Details of regulator properties are defined as child node under
-sub-node "regulators" which is child node of device node.
-
-Please refer file <Documentation/devicetree/bindings/regulator/regulator.txt>
-for common regulator bindings used by client.
-
-Following are properties of parent node related to regulators.
-
-Optional properties:
--------------------
-The input supply of regulators are the optional properties on the
-parent device node. The input supply of these regulators are provided
-through following properties:
-in-sd0-supply: Input supply for SD0, INA-SD0 or INB-SD0 pins.
-in-sd1-supply: Input supply for SD1.
-in-sd2-supply: Input supply for SD2.
-in-sd3-supply: Input supply for SD3.
-in-ldo0-1-supply: Input supply for LDO0 and LDO1.
-in-ldo2-supply: Input supply for LDO2.
-in-ldo3-5-supply: Input supply for LDO3 and LDO5
-in-ldo4-6-supply: Input supply for LDO4 and LDO6.
-in-ldo7-8-supply: Input supply for LDO7 and LDO8.
-
-Optional sub nodes for regulators under "regulators" subnode:
-------------------------------------------------------------
-The subnodes name is the name of regulator and it must be one of:
- sd[0-3], ldo[0-8]
-
-Each sub-node should contain the constraints and initialization
-information for that regulator. The definition for each of these
-nodes is defined using the standard binding for regulators found at
-<Documentation/devicetree/bindings/regulator/regulator.txt>.
-
-There are also additional properties for SD/LDOs. These additional properties
-are required to configure FPS configuration parameters for SDs and LDOs.
-Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible
-Power Sequence (FPS).
-Following are additional properties:
-
-- maxim,active-fps-source: FPS source for the regulators to get
- enabled/disabled when system is in
- active state. Valid values are:
- - MAX77620_FPS_SRC_0,
- FPS source is FPS0.
- - MAX77620_FPS_SRC_1,
- FPS source is FPS1
- - MAX77620_FPS_SRC_2 and
- FPS source is FPS2
- - MAX77620_FPS_SRC_NONE.
- Regulator is not controlled
- by FPS events and it gets
- enabled/disabled by register
- access.
- Absence of this property will leave
- the FPS configuration register for that
- regulator to default configuration.
-
-- maxim,active-fps-power-up-slot: Sequencing event slot number on which
- the regulator get enabled when
- master FPS input event set to HIGH.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,active-fps-power-down-slot: Sequencing event slot number on which
- the regulator get disabled when master
- FPS input event set to LOW.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,suspend-fps-source: This is same as property
- "maxim,active-fps-source" but value
- get configured when system enters in
- to suspend state.
-
-- maxim,suspend-fps-power-up-slot: This is same as property
- "maxim,active-fps-power-up-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
-
-- maxim,suspend-fps-power-down-slot: This is same as property
- "maxim,active-fps-power-down-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
- FPS2.
-- maxim,ramp-rate-setting: integer, ramp rate(uV/us) setting to be
- configured to the device.
- The platform may have different ramp
- rate than advertised ramp rate if it has
- design variation from Maxim's
- recommended. On this case, platform
- specific ramp rate is used for ramp time
- calculation and this property is used
- for device register configurations.
- The measured ramp rate of platform is
- provided by the regulator-ramp-delay
- as described in <devicetree/bindings/
- regulator/regulator.txt>.
- Maxim Max77620 supports following ramp
- delay:
- SD: 13.75mV/us, 27.5mV/us, 55mV/us
- LDOs: 5mV/us, 100mV/us
-
-Note: If the measured ramp delay is same as advertised ramp delay then it is not
-required to provide the ramp delay with property "maxim,ramp-rate-setting". The
-ramp rate can be provided by the regulator-ramp-delay which will be used for
-ramp time calculation for voltage change as well as for device configuration.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
- in-ldo0-1-supply = <&max77620_sd2>;
- in-ldo7-8-supply = <&max77620_sd2>;
- regulators {
- sd0 {
- regulator-name = "vdd-core";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1400000>;
- regulator-boot-on;
- regulator-always-on;
- maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
- };
-
- sd1 {
- regulator-name = "vddio-ddr";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- sd2 {
- regulator-name = "vdd-pre-reg";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- };
-
- sd3 {
- regulator-name = "vdd-1v8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo0 {
- regulator-name = "avdd-sys";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo1 {
- regulator-name = "vdd-pex";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
-
- ldo2 {
- regulator-name = "vddio-sdmmc3";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo3 {
- regulator-name = "vdd-cam-hv";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo4 {
- regulator-name = "vdd-rtc";
- regulator-min-microvolt = <1250000>;
- regulator-max-microvolt = <1250000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo5 {
- regulator-name = "avdd-ts-hv";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo6 {
- regulator-name = "vdd-ts";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo7 {
- regulator-name = "vdd-gen-pll-edp";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo8 {
- regulator-name = "vdd-hdmi-dp";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
- };
-};
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/5] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-03-12 8:52 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
I have tested this patch on LG Optimus Vu P895 with max77663 PMIC and
non-default RTC position. RTC is registered correctly.
---
Changes in v4
- adjusted pinconfig node naming
- changed interrupt in the example
- fixed indentation in the example
- corrected pinconfig node name in the example
- commit "dt-bindings: gpio: trivial-gpio: remove max77620 compatible"
squashed with the converting patch for this compatible
Changes in v3
- max77620 files converted to DT schema.
Changes in v2
- dropped patch that changes max77686 and adjusted max77620 where max77663
is described.
---
Svyatoslav Ryhel (5):
regulator: dt-bindings: regulator-max77620: convert to DT schema
dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
dt-bindings: mfd: max77620: convert to DT schema
dt-bindings: mfd: max77620: document optional RTC address for MAX77663
rtc: max77686: convert to i2c_new_ancillary_device
.../bindings/gpio/trivial-gpio.yaml | 2 -
.../devicetree/bindings/mfd/max77620.txt | 162 -------
.../bindings/mfd/maxim,max77620.yaml | 444 ++++++++++++++++++
.../pinctrl/maxim,max77620-pinctrl.yaml | 97 ++++
.../bindings/pinctrl/pinctrl-max77620.txt | 127 -----
.../regulator/maxim,max77620-regulator.yaml | 99 ++++
.../bindings/regulator/regulator-max77620.txt | 222 ---------
.../bindings/thermal/max77620_thermal.txt | 70 ---
drivers/rtc/rtc-max77686.c | 14 +-
9 files changed, 652 insertions(+), 585 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
delete mode 100644 Documentation/devicetree/bindings/thermal/max77620_thermal.txt
--
2.51.0
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-12 8:02 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260311221115.GA775894-robh@kernel.org>
чт, 12 бер. 2026 р. о 00:11 Rob Herring <robh@kernel.org> пише:
>
> On Sat, Mar 07, 2026 at 03:30:21PM +0200, Svyatoslav Ryhel wrote:
> > сб, 7 бер. 2026 р. о 14:48 Krzysztof Kozlowski <krzk@kernel.org> пише:
> > >
> > > On Fri, Mar 06, 2026 at 03:33:47PM +0200, Svyatoslav Ryhel wrote:
> > > > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > > > TXT to YAML format. This patch does not change any functionality; the
> > > > bindings remain the same.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> > > > .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> > > > 2 files changed, 97 insertions(+), 127 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > > delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > > new file mode 100644
> > > > index 000000000000..7364a8bdd7d3
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > > @@ -0,0 +1,97 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Pinmux controller function for Maxim MAX77620 Power management IC
> > > > +
> > > > +maintainers:
> > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +description:
> > > > + Device has 8 GPIO pins which can be configured as GPIO as well as the
> > > > + special IO functions.
> > > > +
> > > > +allOf:
> > > > + - $ref: /schemas/pinctrl/pincfg-node.yaml
> > > > + - $ref: /schemas/pinctrl/pinmux-node.yaml
> > > > +
> > > > +patternProperties:
> > > > + "^(pin_gpio|gpio)[0-7_]+$":
> > >
> > > Underscores are not allowed in general, so pattern needs fixes. Does
> > > anything actually rely on this name? Is this ABI? I don't see old
> > > binding and driver using the name, thus this should be just ^pin-[0-7]$
> > > (+ is also not correct if you have max 8 gpios)
> > >
> >
> > Old txt schema uses pin_gpio[0-7] hence it is here, but greping trees
> > did not reveal use of pin_gpio so it may be dropped.
> >
> > No this is not ABI, name may be any. Including gpio0-1-2-3, gpio2-4
> > etc which is why + is there. or maybe you know better way to cover
> > those names?
> >
> > There are device trees which use gpio5_6 with the underscore
> > (tegra210-smaug.dts; tegra210-p2894.dtsi for example). Should the
> > schema account for those?
>
> Defining a specific pattern looks like an endorsement of the name. I
> would just do the minimum you need. Something like '^(pin|gpio).' unless
> you have a pinctrl-* property.
>
It does fit nicely. Thank you!
> Rob
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
From: Rob Herring @ 2026-03-11 22:11 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <CAPVz0n2QXSFnrkLPFVDbUjNAkp2_dTumeXh4EsB11ca0jHEC-g@mail.gmail.com>
On Sat, Mar 07, 2026 at 03:30:21PM +0200, Svyatoslav Ryhel wrote:
> сб, 7 бер. 2026 р. о 14:48 Krzysztof Kozlowski <krzk@kernel.org> пише:
> >
> > On Fri, Mar 06, 2026 at 03:33:47PM +0200, Svyatoslav Ryhel wrote:
> > > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > > TXT to YAML format. This patch does not change any functionality; the
> > > bindings remain the same.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> > > .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> > > 2 files changed, 97 insertions(+), 127 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > new file mode 100644
> > > index 000000000000..7364a8bdd7d3
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > > @@ -0,0 +1,97 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Pinmux controller function for Maxim MAX77620 Power management IC
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description:
> > > + Device has 8 GPIO pins which can be configured as GPIO as well as the
> > > + special IO functions.
> > > +
> > > +allOf:
> > > + - $ref: /schemas/pinctrl/pincfg-node.yaml
> > > + - $ref: /schemas/pinctrl/pinmux-node.yaml
> > > +
> > > +patternProperties:
> > > + "^(pin_gpio|gpio)[0-7_]+$":
> >
> > Underscores are not allowed in general, so pattern needs fixes. Does
> > anything actually rely on this name? Is this ABI? I don't see old
> > binding and driver using the name, thus this should be just ^pin-[0-7]$
> > (+ is also not correct if you have max 8 gpios)
> >
>
> Old txt schema uses pin_gpio[0-7] hence it is here, but greping trees
> did not reveal use of pin_gpio so it may be dropped.
>
> No this is not ABI, name may be any. Including gpio0-1-2-3, gpio2-4
> etc which is why + is there. or maybe you know better way to cover
> those names?
>
> There are device trees which use gpio5_6 with the underscore
> (tegra210-smaug.dts; tegra210-p2894.dtsi for example). Should the
> schema account for those?
Defining a specific pattern looks like an endorsement of the name. I
would just do the minimum you need. Something like '^(pin|gpio).' unless
you have a pinctrl-* property.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox