* [PATCH 09/15] dt-bindings: mfd: ricoh,rn5t618: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert the binding to use the generic power-controller schema instead by
referencing power-controller.yaml and removing the local
`system-power-controller` property.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
index e3d64307b5315730e8374e863203a15abb9f83e3..d81691f4d5742f46bb6cf37be4270fc4a38f21f9 100644
--- a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
+++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
@@ -18,6 +18,7 @@ description: |
The RC5T619 additionally includes USB charger detection and an RTC.
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- if:
properties:
compatible:
@@ -68,15 +69,10 @@ properties:
interrupts:
maxItems: 1
- system-power-controller:
- type: boolean
- description: |
- See Documentation/devicetree/bindings/power/power-controller.txt
-
regulators:
type: object
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
--
2.37.1
^ permalink raw reply related
* [PATCH 08/15] dt-bindings: mfd: rockchip,rk8x: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert the binding to use the generic power-controller schema instead by
referencing power-controller.yaml and removing the local
`system-power-controller` property.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml | 10 ++++------
Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml | 7 +++----
Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml | 3 +--
Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml | 9 +++++----
Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml | 10 ++++------
Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml | 5 ++---
Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml | 9 +++++----
7 files changed, 24 insertions(+), 29 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml
index 7c71447200ba4c131b67f94c11913f70be625980..5d644f3fbe1bf734efb6a49b4f7284b7397b33d7 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml
@@ -13,6 +13,9 @@ description: |
Rockchip RK801 series PMIC. This device consists of an i2c controlled MFD
that includes multiple switchable regulators.
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
enum:
@@ -24,11 +27,6 @@ properties:
interrupts:
maxItems: 1
- system-power-controller:
- type: boolean
- description:
- Telling whether or not this PMIC is controlling the system power.
-
wakeup-source:
type: boolean
description:
@@ -76,7 +74,7 @@ required:
- reg
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
index da2391530c16c0aa5067128cd6f76e99f1f0f8fe..7a123bcd4320f10a85178ad23609147586fddb20 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
@@ -46,8 +46,6 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- system-power-controller: true
-
wakeup-source:
type: boolean
description:
@@ -87,6 +85,7 @@ properties:
unevaluatedProperties: false
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- if:
properties:
'#clock-cells':
@@ -108,7 +107,7 @@ required:
- interrupts
- "#clock-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -126,7 +125,7 @@ examples:
interrupts = <RK_PA6 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pmic_int_l>;
- rockchip,system-power-controller;
+ system-power-controller;
wakeup-source;
#clock-cells = <0>;
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
index eb5bca31948ef0d39c46025d0cca65b8b4105a50..e441c648969915137f73e4222dde2446d43765ba 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
@@ -29,8 +29,6 @@ properties:
'#gpio-cells':
const: 2
- system-power-controller: true
-
rockchip,reset-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
@@ -136,6 +134,7 @@ patternProperties:
enum: [gpio_pwrctrl1, gpio_pwrctrl2, gpio_pwrctrl3]
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml
required:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
index 50dfffac8fbf53034df8b0c88eb43c7675749311..9bb1467bf5ffe923275589c6817db9d4710043bd 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
@@ -14,6 +14,9 @@ description: |
Rockchip RK808 series PMIC. This device consists of an i2c controlled MFD
that includes regulators, an RTC, and a power button.
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
enum:
@@ -41,8 +44,6 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- system-power-controller: true
-
wakeup-source:
type: boolean
description:
@@ -119,7 +120,7 @@ required:
- interrupts
- "#clock-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -140,7 +141,7 @@ examples:
dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>,
<&gpio7 15 GPIO_ACTIVE_HIGH>;
reg = <0x1b>;
- rockchip,system-power-controller;
+ system-power-controller;
wakeup-source;
#clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
index 0676890f101e5481a7466b26de5544a829c29101..853ad270a827fd0b40c50e69fb48a2e23d16c51d 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
@@ -15,6 +15,9 @@ description:
that includes regulators, a RTC, a GPIO controller, a power button, and a
battery charger manager with fuel gauge.
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
enum:
@@ -39,11 +42,6 @@ properties:
'#gpio-cells':
const: 2
- system-power-controller:
- type: boolean
- description:
- Telling whether or not this PMIC is controlling the system power.
-
wakeup-source:
type: boolean
@@ -108,7 +106,7 @@ required:
- interrupts
- '#clock-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
index 2cb6d176a84cfb4c07a17b6390470b0ddb95bea1..4c5d2f43a6f182ff2bb0fe26869a1c56120146cf 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
@@ -53,8 +53,6 @@ properties:
'#sound-dai-cells':
const: 0
- system-power-controller: true
-
wakeup-source:
type: boolean
description:
@@ -157,6 +155,7 @@ properties:
additionalProperties: false
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- $ref: /schemas/sound/dai-common.yaml#
- if:
properties:
@@ -195,7 +194,7 @@ required:
- interrupts
- "#clock-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
index 90d944c27ba147aa83ff86fdacb546d08272fe1e..d1ca8b447034f2d0d1d3474932f3dedef6dff0de 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
@@ -14,6 +14,9 @@ description: |
Rockchip RK818 series PMIC. This device consists of an i2c controlled MFD
that includes regulators, an RTC, and a power button.
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
enum:
@@ -41,8 +44,6 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- system-power-controller: true
-
wakeup-source:
type: boolean
description:
@@ -111,7 +112,7 @@ required:
- interrupts
- "#clock-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -130,7 +131,7 @@ examples:
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pmic_int>;
- rockchip,system-power-controller;
+ system-power-controller;
wakeup-source;
#clock-cells = <1>;
--
2.37.1
^ permalink raw reply related
* [PATCH 07/15] dt-bindings: mfd: ti,tps65910: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Mark the "ti,system-power-controller" as deprecated and include a reference
to power-controller.yaml to uses the common definition.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/mfd/ti,tps65910.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml b/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml
index f1a76f88fc0cdd60d8ba8f7153db7701e82fa183..3939e8518a8e72351e62ac07365a34dc1145e824 100644
--- a/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml
@@ -72,6 +72,7 @@ properties:
ti,system-power-controller:
type: boolean
description: Identify whether or not this pmic controls the system power
+ deprecated: true
ti,sleep-enable:
type: boolean
@@ -170,9 +171,10 @@ required:
- '#gpio-cells'
- regulators
-additionalProperties: false
+unevaluatedProperties: false
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- if:
properties:
compatible:
@@ -216,7 +218,7 @@ examples:
#interrupt-cells = <2>;
interrupt-controller;
- ti,system-power-controller;
+ system-power-controller;
ti,vmbch-threshold = <0>;
ti,vmbch2-threshold = <0>;
--
2.37.1
^ permalink raw reply related
* [PATCH 06/15] dt-bindings: mfd: ene-kb[3]930: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert the binding to use the generic power-controller schema instead by
referencing power-controller.yaml and removing the local
`system-power-controller` property definition.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/mfd/ene-kb3930.yaml | 7 ++++---
Documentation/devicetree/bindings/mfd/ene-kb930.yaml | 6 +++---
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
index 9b11b6e2bbf746f46406db268bf49b6775939fb3..1847a6d5b22e8ded8638424cfdc6605005d20846 100644
--- a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
+++ b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
@@ -13,6 +13,9 @@ description: |
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
items:
@@ -26,13 +29,11 @@ properties:
description: GPIO used with the shutdown protocol on Ariel
maxItems: 2
- system-power-controller: true
-
required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/ene-kb930.yaml b/Documentation/devicetree/bindings/mfd/ene-kb930.yaml
index 02c111def5de5fa480c59e70518e1de89b2aff08..e0c8abf95bd92f6aa463e3347c101a1c1589161e 100644
--- a/Documentation/devicetree/bindings/mfd/ene-kb930.yaml
+++ b/Documentation/devicetree/bindings/mfd/ene-kb930.yaml
@@ -13,7 +13,9 @@ description: |
maintainers:
- Dmitry Osipenko <digetx@gmail.com>
-$ref: /schemas/power/supply/power-supply.yaml
+allOf:
+ - $ref: /schemas/power/supply/power-supply.yaml
+ - $ref: /schemas/power/power-controller.yaml#
properties:
compatible:
@@ -24,8 +26,6 @@ properties:
reg:
maxItems: 1
- system-power-controller: true
-
required:
- compatible
- reg
--
2.37.1
^ permalink raw reply related
* [PATCH 05/15] dt-bindings: rtc: ingenic,rtc: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert the binding to use the generic power-controller schema instead by
referencing power-controller.yaml and removing the local
`system-power-controller` property definition.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
index de9879bdb3175a7e0f24304b5a084a8faa233c46..415566d8dba564ebad976689596bbcd699ed6021 100644
--- a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
@@ -11,6 +11,7 @@ maintainers:
allOf:
- $ref: rtc.yaml#
+ - $ref: /schemas/power/power-controller.yaml#
- if:
not:
properties:
@@ -53,12 +54,6 @@ properties:
"#clock-cells":
const: 0
- system-power-controller:
- description: |
- Indicates that the RTC is responsible for powering OFF
- the system.
- type: boolean
-
ingenic,reset-pin-assert-time-ms:
minimum: 0
maximum: 125
--
2.37.1
^ permalink raw reply related
* [PATCH 04/15] dt-bindings: regulator: act8x: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert the binding to use the generic power-controller schema instead by
referencing power-controller.yaml and removing the local
`system-power-controller` property definition.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/regulator/active-semi,act8600.yaml | 11 ++++-------
.../devicetree/bindings/regulator/active-semi,act8846.yaml | 11 ++++-------
.../devicetree/bindings/regulator/active-semi,act8865.yaml | 11 ++++-------
.../devicetree/bindings/regulator/active-semi,act8945a.yaml | 11 ++++-------
4 files changed, 16 insertions(+), 28 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
index b8ca967bc83d1ddff40679427da9d2d9cd3b13b8..49f74a9b1eaab19ff6d1c4e633b916a51c6a2f86 100644
--- a/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
@@ -9,6 +9,9 @@ title: Active-semi ACT8600 regulator
maintainers:
- Paul Cercueil <paul@crapouillou.net>
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
const: active-semi,act8600
@@ -16,12 +19,6 @@ properties:
reg:
maxItems: 1
- system-power-controller:
- description:
- Indicates that the ACT8600 is responsible for powering OFF
- the system.
- type: boolean
-
active-semi,vsel-high:
description:
Indicates the VSEL pin is high. If this property is missing,
@@ -75,7 +72,7 @@ properties:
inl-supply:
description: Handle to the INL input supply
-additionalProperties: false
+unevaluatedProperties: false
required:
- reg
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
index 02f45b5834d008e8e21cafb692e829d4046c1b92..29ec8ab1b642635b8a1452a5d4b515e88445c63b 100644
--- a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
@@ -9,6 +9,9 @@ title: Active-semi ACT8846 regulator
maintainers:
- Paul Cercueil <paul@crapouillou.net>
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
const: active-semi,act8846
@@ -16,12 +19,6 @@ properties:
reg:
maxItems: 1
- system-power-controller:
- description:
- Indicates that the ACT8846 is responsible for powering OFF
- the system.
- type: boolean
-
active-semi,vsel-high:
description:
Indicates the VSEL pin is high. If this property is missing,
@@ -59,7 +56,7 @@ properties:
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
-additionalProperties: false
+unevaluatedProperties: false
required:
- reg
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
index afe1abc2d727b37b3652634edd6cbcb8132e5f76..2423d9b65192e984de4d9bd83b1a25846bc12361 100644
--- a/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
@@ -9,6 +9,9 @@ title: Active-semi ACT8865 regulator
maintainers:
- Paul Cercueil <paul@crapouillou.net>
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
const: active-semi,act8865
@@ -16,12 +19,6 @@ properties:
reg:
maxItems: 1
- system-power-controller:
- description:
- Indicates that the ACT8865 is responsible for powering OFF
- the system.
- type: boolean
-
active-semi,vsel-high:
description:
Indicates the VSEL pin is high. If this property is missing,
@@ -79,7 +76,7 @@ properties:
inl67-supply:
description: Handle to the INL67 input supply
-additionalProperties: false
+unevaluatedProperties: false
required:
- reg
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
index a8d579844dc7bcf634bb1e84dccb8cd5d31b96f9..f19d3f0e0784d5efbd2bf06dc0c2a25e45dbac70 100644
--- a/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
@@ -9,6 +9,9 @@ title: Active-semi ACT8945a regulator
maintainers:
- Paul Cercueil <paul@crapouillou.net>
+allOf:
+ - $ref: /schemas/power/power-controller.yaml#
+
properties:
compatible:
const: active-semi,act8945a
@@ -16,12 +19,6 @@ properties:
reg:
maxItems: 1
- system-power-controller:
- description:
- Indicates that the ACT8945a is responsible for powering OFF
- the system.
- type: boolean
-
active-semi,vsel-high:
description:
Indicates the VSEL pin is high. If this property is missing,
@@ -127,7 +124,7 @@ properties:
- active-semi,chglev-gpios
- active-semi,lbo-gpios
-additionalProperties: false
+unevaluatedProperties: false
required:
- reg
--
2.37.1
^ permalink raw reply related
* [PATCH 03/15] dt-bindings: regulator: ti,tps65219: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert the binding to use the generic power-controller schema instead by
referencing power-controller.yaml and removing the local
`system-power-controller` property definition.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/regulator/ti,tps65219.yaml | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml
index 7c64e588a8b54d90ee10c4c155f9db62b5a72c32..d3a82aa7319f0096d8c98bae450190f946a85a9a 100644
--- a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml
+++ b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml
@@ -31,11 +31,6 @@ properties:
reg:
maxItems: 1
- system-power-controller:
- type: boolean
- description: Optional property that indicates that this device is
- controlling system power.
-
interrupts:
description: Short-circuit, over-current, under-voltage for regulators, PB interrupts.
maxItems: 1
@@ -99,9 +94,10 @@ required:
- interrupts
- regulators
-additionalProperties: false
+unevaluatedProperties: false
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- if:
properties:
compatible:
--
2.37.1
^ permalink raw reply related
* [PATCH 02/15] dt-bindings: soc: bcm2835-pm: Use generic power-controller schema
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Switch the binding to use the generic power-controller schema and drop the
local definition. Also replace `additionalProperties` with
`unevaluatedProperties`.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
index 039c8e4a4c51b3fc05a75d75509145419ceabd95..3420e1f1f6c4efcc5c91425f2486fccc4b00acf1 100644
--- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
@@ -50,9 +50,6 @@ properties:
- const: h264
- const: isp
- system-power-controller:
- type: boolean
-
timeout-sec: true
required:
@@ -62,6 +59,7 @@ required:
- "#reset-cells"
allOf:
+ - $ref: /schemas/power/power-controller.yaml#
- $ref: /schemas/watchdog/watchdog.yaml#
- if:
@@ -90,7 +88,7 @@ allOf:
reg-names:
maxItems: 1
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.37.1
^ permalink raw reply related
* [PATCH 01/15] dt-bindings: power: power-controller: Convert to yaml format
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
In-Reply-To: <20260316-power-controller-v1-0-92c80e5e1744@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Convert power-controller.txt to yaml format. Drop the example because
there is already one in regulator/active-semi,act8846.yaml.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/power/power-controller.txt | 17 ------------
.../bindings/power/power-controller.yaml | 30 ++++++++++++++++++++++
2 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/power-controller.txt b/Documentation/devicetree/bindings/power/power-controller.txt
deleted file mode 100644
index e45affea80781292316c75ed387ba38402501c5b..0000000000000000000000000000000000000000
--- a/Documentation/devicetree/bindings/power/power-controller.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Generic system power control capability
-
-Power-management integrated circuits or miscellaneous hardware components are
-sometimes able to control the system power. The device driver associated with these
-components might need to define this capability, which tells the kernel that
-it can be used to switch off the system. The corresponding device must have the
-standard property "system-power-controller" in its device node. This property
-marks the device as able to control the system power. In order to test if this
-property is found programmatically, use the helper function
-"of_device_is_system_power_controller" from of.h .
-
-Example:
-
-act8846: act8846@5 {
- compatible = "active-semi,act8846";
- system-power-controller;
-}
diff --git a/Documentation/devicetree/bindings/power/power-controller.yaml b/Documentation/devicetree/bindings/power/power-controller.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..ff698365d778446c08ceeb5f3ef144d5e97d2f79
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power-controller.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic System Power Control Capability
+
+maintainers:
+ - Rafael J. Wysocki <rafael@kernel.org>
+ - Ulf Hansson <ulf.hansson@linaro.org>
+
+description: |
+ Power-management integrated circuits or miscellaneous hardware components
+ are sometimes able to control the system power. The device driver associated
+ with these components might need to define this capability, which tells the
+ kernel that it can be used to switch off the system. The corresponding device
+ must have the standard property "system-power-controller" in its device node. This
+ property marks the device as able to control the system power.
+
+ In order to test if this property is found programmatically, use the helper
+ function "of_device_is_system_power_controller" from of.h.
+
+properties:
+ system-power-controller:
+ type: boolean
+ description:
+ Indicates that this device can be used to control the system power.
+
+additionalProperties: true
--
2.37.1
^ permalink raw reply related
* [PATCH 00/15] Convert power-controller to dt-schema and update various yaml file to referencing it
From: Peng Fan (OSS) @ 2026-03-16 14:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Saenz Julienne, Lee Jones, Liam Girdwood, Mark Brown,
Shree Ramamoorthy, Jerome Neanne, Paul Cercueil,
Alexandre Belloni, Dmitry Osipenko, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, Sebastian Reichel, Andreas Kemnade,
Jonathan Neuschäfer, Lubomir Rintel, Julien Panis,
Matti Vaittinen, Alexander Kurz, Krzysztof Kozlowski,
André Draszik
Cc: devicetree, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-rtc, linux-rockchip, linux-samsung-soc, Peng Fan
Convert power-controller.txt to dt-schema
Update various dt-bindings to use generic power-controller.yaml without
defining local property.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (15):
dt-bindings: power: power-controller: Convert to yaml format
dt-bindings: soc: bcm2835-pm: Use generic power-controller schema
dt-bindings: regulator: ti,tps65219: Use generic power-controller schema
dt-bindings: regulator: act8x: Use generic power-controller schema
dt-bindings: rtc: ingenic,rtc: Use generic power-controller schema
dt-bindings: mfd: ene-kb[3]930: Use generic power-controller schema
dt-bindings: mfd: ti,tps65910: Use generic power-controller schema
dt-bindings: mfd: rockchip,rk8x: Use generic power-controller schema
dt-bindings: mfd: ricoh,rn5t618: Use generic power-controller schema
dt-bindings: mfd: netronix,ntxec: Use generic power-controller schema
dt-bindings: mfd: ti,twl: Use generic power-controller schema
dt-bindings: mfd: ti,tps6594: Use generic power-controller schema
dt-bindings: mfd: rohm,bd71828-pmic: Use generic power-controller schema
dt-bindings: mfd: fsl,mc13xxx: Use generic power-controller schema
dt-bindings: mfd: samsung,s2mpg10-pmic: Use generic power-controller schema
.../devicetree/bindings/mfd/ene-kb3930.yaml | 7 ++---
.../devicetree/bindings/mfd/ene-kb930.yaml | 6 ++---
.../devicetree/bindings/mfd/fsl,mc13xxx.yaml | 5 ++--
.../devicetree/bindings/mfd/netronix,ntxec.yaml | 9 +++----
.../devicetree/bindings/mfd/ricoh,rn5t618.yaml | 8 ++----
.../devicetree/bindings/mfd/rockchip,rk801.yaml | 10 +++-----
.../devicetree/bindings/mfd/rockchip,rk805.yaml | 7 +++--
.../devicetree/bindings/mfd/rockchip,rk806.yaml | 3 +--
.../devicetree/bindings/mfd/rockchip,rk808.yaml | 9 ++++---
.../devicetree/bindings/mfd/rockchip,rk816.yaml | 10 +++-----
.../devicetree/bindings/mfd/rockchip,rk817.yaml | 5 ++--
.../devicetree/bindings/mfd/rockchip,rk818.yaml | 9 ++++---
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++---
.../bindings/mfd/samsung,s2mpg10-pmic.yaml | 7 ++---
.../devicetree/bindings/mfd/ti,tps65910.yaml | 6 +++--
.../devicetree/bindings/mfd/ti,tps6594.yaml | 7 ++---
Documentation/devicetree/bindings/mfd/ti,twl.yaml | 3 +--
.../devicetree/bindings/power/power-controller.txt | 17 ------------
.../bindings/power/power-controller.yaml | 30 ++++++++++++++++++++++
.../bindings/regulator/active-semi,act8600.yaml | 11 +++-----
.../bindings/regulator/active-semi,act8846.yaml | 11 +++-----
.../bindings/regulator/active-semi,act8865.yaml | 11 +++-----
.../bindings/regulator/active-semi,act8945a.yaml | 11 +++-----
.../devicetree/bindings/regulator/ti,tps65219.yaml | 8 ++----
.../devicetree/bindings/rtc/ingenic,rtc.yaml | 7 +----
.../bindings/soc/bcm/brcm,bcm2835-pm.yaml | 6 ++---
26 files changed, 107 insertions(+), 123 deletions(-)
---
base-commit: 5c9e55fecf9365890c64f14761a80f9413a3b1d1
change-id: 20260314-power-controller-56d6b4724146
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] rtc: ti-k3: Add support to resume from IO DDR low power mode
From: Raghavendra, Vignesh @ 2026-03-14 13:08 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, alexandre.belloni, linux-rtc,
linux-kernel
Cc: msp, vishalm, sebin.francis
In-Reply-To: <20260313111740.1492519-1-a-kaur@ti.com>
On 3/13/2026 4:47 PM, Akashdeep Kaur wrote:
> 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>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
> ---
>
> Tested deep sleep with rtcwake after IO DDR resume on AM62P-SK.
>
> Changes in v2:
> -Updated the commit message as suggested in review
> -Link to v1: https://lore.kernel.org/all/20260311070214.3589965-1-a-kaur@ti.com/
>
> ---
> 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
* [PATCH v1 0/2] rtc: cmos: Do not require IRQ if ACPI alarm is used
From: Rafael J. Wysocki @ 2026-03-14 12:09 UTC (permalink / raw)
To: linux-rtc; +Cc: LKML, Linux ACPI, Alexandre Belloni, Mario Limonciello
Hi All,
This series of patches allows the CMOS RTC alarm to be used on x86
systems that don't include a functional HPET and may not configure
an IRQ for the CMOS RTC, but have a functional ACPI RTC fixed event.
The first patch allows the ACPI RTC fixed event to be used on systems
without functional HPET because there is no fundamental dependency
between HPET and the ACPI RTC fixed event being hooked up to the CMOS
RTC.
The second patch changes the driver to stop requiring an IRQ to be
configured for the alarm functionality if the ACPI RTC fixed event
is use for signaling events because it require a separate IRQ to
be requested (the ACPI SCI is used for event signaling in that case).
Thanks!
^ permalink raw reply
* [PATCH v1 1/2] rtc: cmos: Enable ACPI alarm if advertised in ACPI FADT
From: Rafael J. Wysocki @ 2026-03-14 12:11 UTC (permalink / raw)
To: linux-rtc; +Cc: LKML, Linux ACPI, Alexandre Belloni, Mario Limonciello
In-Reply-To: <3964452.kQq0lBPeGt@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If the ACPI_FADT_FIXED_RTC flag is unset, the platform is declaring that
it supports the ACPI RTC fixed event which should be used instead of a
dedicated CMOS RTC IRQ. However, the driver only enables it when
is_hpet_enabled() returns true, which is questionable because there is
no clear connection between enabled HPET and signaling wakeup via the
ACPI RTC fixed event (for instance, the latter can be expected to work
on systems that don't include a functional HPET).
Moreover, since use_hpet_alarm() returns false if use_acpi_alarm is set,
the ACPI RTC fixed event is effectively used instead of the HPET alarm
if the latter is functional, but there is no particular reason why it
could not be used otherwise.
Accordingly, on x86 systems with ACPI, set use_acpi_alarm if
ACPI_FADT_FIXED_RTC is unset without looking at whether or not HPET is
enabled.
Also, do the ACPI FADT check in use_acpi_alarm_quirks() before the DMI
BIOS year checks which are more expensive and it's better to skip them
if ACPI_FADT_FIXED_RTC is set.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/rtc/rtc-cmos.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -817,6 +817,9 @@ static void rtc_wake_off(struct device *
#ifdef CONFIG_X86
static void use_acpi_alarm_quirks(void)
{
+ if (acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)
+ return;
+
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_INTEL:
if (dmi_get_bios_year() < 2015)
@@ -830,8 +833,6 @@ static void use_acpi_alarm_quirks(void)
default:
return;
}
- if (!is_hpet_enabled())
- return;
use_acpi_alarm = true;
}
^ permalink raw reply
* [PATCH v1 2/2] rtc: cmos: Do not require IRQ if ACPI alarm is used
From: Rafael J. Wysocki @ 2026-03-14 12:12 UTC (permalink / raw)
To: linux-rtc; +Cc: LKML, Linux ACPI, Alexandre Belloni, Mario Limonciello
In-Reply-To: <3964452.kQq0lBPeGt@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If the ACPI RTC fixed event is used, a dedicated IRQ is not required
for the CMOS RTC alarm to work, so allow the driver to use the alarm
without a valid IRQ in that case.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/rtc/rtc-cmos.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -216,6 +216,11 @@ static inline void cmos_write_bank2(unsi
/*----------------------------------------------------------------*/
+static bool cmos_no_alarm(struct cmos_rtc *cmos)
+{
+ return !is_valid_irq(cmos->irq) && !cmos_use_acpi_alarm();
+}
+
static int cmos_read_time(struct device *dev, struct rtc_time *t)
{
int ret;
@@ -287,7 +292,7 @@ static int cmos_read_alarm(struct device
};
/* This not only a rtc_op, but also called directly */
- if (!is_valid_irq(cmos->irq))
+ if (cmos_no_alarm(cmos))
return -ETIMEDOUT;
/* Basic alarms only support hour, minute, and seconds fields.
@@ -520,7 +525,7 @@ static int cmos_set_alarm(struct device
int ret;
/* This not only a rtc_op, but also called directly */
- if (!is_valid_irq(cmos->irq))
+ if (cmos_no_alarm(cmos))
return -EIO;
ret = cmos_validate_alarm(dev, t);
@@ -1096,7 +1101,7 @@ cmos_do_probe(struct device *dev, struct
dev_dbg(dev, "IRQ %d is already in use\n", rtc_irq);
goto cleanup1;
}
- } else {
+ } else if (!cmos_use_acpi_alarm()) {
clear_bit(RTC_FEATURE_ALARM, cmos_rtc.rtc->features);
}
@@ -1121,7 +1126,7 @@ cmos_do_probe(struct device *dev, struct
acpi_rtc_event_setup(dev);
dev_info(dev, "%s%s, %d bytes nvram%s\n",
- !is_valid_irq(rtc_irq) ? "no alarms" :
+ cmos_no_alarm(&cmos_rtc) ? "no alarms" :
cmos_rtc.mon_alrm ? "alarms up to one year" :
cmos_rtc.day_alrm ? "alarms up to one month" :
"alarms up to one day",
@@ -1147,7 +1152,7 @@ cleanup0:
static void cmos_do_shutdown(int rtc_irq)
{
spin_lock_irq(&rtc_lock);
- if (is_valid_irq(rtc_irq))
+ if (!cmos_no_alarm(&cmos_rtc))
cmos_irq_disable(&cmos_rtc, RTC_IRQMASK);
spin_unlock_irq(&rtc_lock);
}
^ permalink raw reply
* Re: [PATCH v3 09/13] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Kaustabh Chakraborty @ 2026-03-13 20:33 UTC (permalink / raw)
To: Lee Jones, Kaustabh Chakraborty
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260310113835.GG183676@google.com>
On 2026-03-10 11:38 +00:00, Lee Jones wrote:
> On Wed, 25 Feb 2026, Kaustabh Chakraborty wrote:
>
>> Add support for flash LEDs found in certain Samsung S2M series PMICs.
>> The device has two channels for LEDs, typically for the back and front
>> cameras in mobile devices. Both channels can be independently
>> controlled, and can be operated in torch or flash modes.
>>
>> The driver includes initial support for the S2MU005 PMIC flash LEDs.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> drivers/leds/flash/Kconfig | 12 +
>> drivers/leds/flash/Makefile | 1 +
>> drivers/leds/flash/leds-s2m-flash.c | 429 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 442 insertions(+)
>>
>> diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
>> index 5e08102a67841..be62e05277429 100644
>> --- a/drivers/leds/flash/Kconfig
>> +++ b/drivers/leds/flash/Kconfig
>> @@ -114,6 +114,18 @@ config LEDS_RT8515
>> To compile this driver as a module, choose M here: the module
>> will be called leds-rt8515.
>>
>> +config LEDS_S2M_FLASH
>> + tristate "Samsung S2M series PMICs flash/torch LED support"
>> + depends on LEDS_CLASS
>> + depends on MFD_SEC_CORE
>> + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
>> + select REGMAP_IRQ
>> + help
>> + This option enables support for the flash/torch LEDs found in
>> + certain Samsung S2M series PMICs, such as the S2MU005. It has
>> + a LED channel dedicated for every physical LED. The LEDs can
>> + be controlled in flash and torch modes.
>> +
>> config LEDS_SGM3140
>> tristate "LED support for the SGM3140"
>> depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
>> diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
>> index 712fb737a428e..44e6c1b4beb37 100644
>> --- a/drivers/leds/flash/Makefile
>> +++ b/drivers/leds/flash/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
>> obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
>> obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
>> obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
>> +obj-$(CONFIG_LEDS_S2M_FLASH) += leds-s2m-flash.o
>> obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
>> obj-$(CONFIG_LEDS_SY7802) += leds-sy7802.o
>> obj-$(CONFIG_LEDS_TPS6131X) += leds-tps6131x.o
>> diff --git a/drivers/leds/flash/leds-s2m-flash.c b/drivers/leds/flash/leds-s2m-flash.c
>> new file mode 100644
>> index 0000000000000..536a529889a9c
>> --- /dev/null
>> +++ b/drivers/leds/flash/leds-s2m-flash.c
>> @@ -0,0 +1,429 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Flash and Torch LED Driver for Samsung S2M series PMICs.
>> + *
>> + * Copyright (c) 2015 Samsung Electronics Co., Ltd
>> + * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
>> + */
>> +
>> +#include <linux/container_of.h>
>> +#include <linux/led-class-flash.h>
>> +#include <linux/mfd/samsung/core.h>
>> +#include <linux/mfd/samsung/s2mu005.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <media/v4l2-flash-led-class.h>
>> +
>> +#define MAX_CHANNELS 2
>> +
>> +struct s2m_fled {
>
> This is not the fled, change this to _led and call pointers to it 'led'.
>
>> + struct device *dev;
>> + struct regmap *regmap;
>> + struct led_classdev_flash cdev;
>
> This is the 'fled'. Please change all pointer to it to 'fled'.
>
>> + struct v4l2_flash *v4l2_flash;
>> + /*
>> + * The mutex object prevents the concurrent access of flash control
>> + * registers by the LED and V4L2 subsystems.
>> + */
>> + struct mutex lock;
>> + const struct s2m_fled_spec *spec;
>
> This should not be in here.
>
>> + unsigned int reg_enable;
>> + u8 channel;
>> + u8 flash_brightness;
>> + u8 flash_timeout;
>> +};
>> +
>> +struct s2m_fled_spec {
>> + u8 nr_channels;
>> + u32 torch_max_brightness;
>> + u32 flash_min_current_ua;
>> + u32 flash_max_current_ua;
>> + u32 flash_min_timeout_us;
>> + u32 flash_max_timeout_us;
>> + int (*torch_brightness_set_blocking)(struct led_classdev *led_cdev,
>> + enum led_brightness brightness);
>
> I'm really not a fan of pointers to functions at the driver level.
>
> If there are differences between devices, which I cannot see here, store
> an identifier and use that to choose which call-back function is the
> most appropriate.
>
>> + const struct led_flash_ops *flash_ops;
>
> Why do we need to store these?
>
> The same principles apply to the function pointer above.
Yes, I have done exactly that. I have moved these values in
s2m_fled_init_channel() and renamed it s2mu005_fled_init_channel(). This
function will be chosen as a result of evaluation of a switch-block.
>> +};
>> +
>> +static struct led_classdev_flash *to_cdev_flash(struct led_classdev *cdev)
>> +{
>> + return container_of(cdev, struct led_classdev_flash, led_cdev);
>> +}
>> +
>> +static struct s2m_fled *to_led_priv(struct led_classdev_flash *cdev)
>
> There is nothing private about s2m_{f}led.
>
> 'led' is the most common nomenclature. So: led->channel, etc.
>
> Remove 'priv' throughout.
>
>> +{
>> + return container_of(cdev, struct s2m_fled, cdev);
>
> return container_of(fled, struct s2m_led, fled);
>
>> +}
>> +
>> +static int s2m_fled_flash_brightness_set(struct led_classdev_flash *cdev,
>> + u32 brightness)
>> +{
>> + struct s2m_fled *priv = to_led_priv(cdev);
>> + struct led_flash_setting *setting = &cdev->brightness;
>> +
>> + priv->flash_brightness = (brightness - setting->min) / setting->step;
>> +
>> + return 0;
>> +}
>> +
>> +static int s2m_fled_flash_timeout_set(struct led_classdev_flash *cdev,
>> + u32 timeout)
>> +{
>> + struct s2m_fled *priv = to_led_priv(cdev);
>> + struct led_flash_setting *setting = &cdev->timeout;
>> +
>> + priv->flash_timeout = (timeout - setting->min) / setting->step;
>> +
>> + return 0;
>> +}
>> +
>> +#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
>> +static int s2m_fled_flash_external_strobe_set(struct v4l2_flash *v4l2_flash,
>> + bool enable)
>> +{
>> + struct s2m_fled *priv = to_led_priv(v4l2_flash->fled_cdev);
>> +
>> + mutex_lock(&priv->lock);
>> +
>> + priv->cdev.ops->strobe_set(&priv->cdev, enable);
>> +
>> + mutex_unlock(&priv->lock);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct v4l2_flash_ops s2m_fled_v4l2_flash_ops = {
>> + .external_strobe_set = s2m_fled_flash_external_strobe_set,
>> +};
>> +#else
>> +static const struct v4l2_flash_ops s2m_fled_v4l2_flash_ops;
>> +#endif
>> +
>> +static void s2m_fled_v4l2_flash_release(void *v4l2_flash)
>> +{
>> + v4l2_flash_release(v4l2_flash);
>> +}
>> +
>> +static int s2mu005_fled_torch_brightness_set(struct led_classdev *cdev,
>> + enum led_brightness value)
>> +{
>> + struct s2m_fled *priv = to_led_priv(to_cdev_flash(cdev));
>> + struct regmap *regmap = priv->regmap;
>> + int ret;
>> +
>> + mutex_lock(&priv->lock);
>> +
>> + if (value == LED_OFF) {
>
> These defines are deprecated.
>
> From include/linux/leds.h:
>
> /* This is obsolete/useless. We now support variable maximum brightness. */
> enum led_brightness {
> LED_OFF = 0,
> LED_ON = 1,
> LED_HALF = 127,
> LED_FULL = 255,
> };
>
Let me know what am I supposed to use then. The
brightness_set_blocking() function is defined as such:
int (*brightness_set_blocking)(struct led_classdev *led_cdev,
enum led_brightness brightness);
Which has enum led_brightness as one of its params.
Do I just ignore the 'obsolete' param for now and replace ` == LED_OFF`
with a logical NOT?
>> + ret = regmap_clear_bits(regmap, priv->reg_enable,
>> + S2MU005_FLED_TORCH_EN(priv->channel));
>> + if (ret < 0)
>> + dev_err(priv->dev, "failed to disable torch LED\n");
>> + goto unlock;
>> + }
>> +
>> + ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL1(priv->channel),
> j> + S2MU005_FLED_TORCH_IOUT,
>> + FIELD_PREP(S2MU005_FLED_TORCH_IOUT, value - 1));
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to set torch current\n");
>> + goto unlock;
>> + }
>> +
>> + ret = regmap_set_bits(regmap, priv->reg_enable,
>> + S2MU005_FLED_TORCH_EN(priv->channel));
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to enable torch LED\n");
>> + goto unlock;
>> + }
>> +
>> +unlock:
>> + mutex_unlock(&priv->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static int s2mu005_fled_flash_strobe_set(struct led_classdev_flash *cdev,
>> + bool state)
>> +{
>> + struct s2m_fled *priv = to_led_priv(cdev);
>> + struct regmap *regmap = priv->regmap;
>> + int ret;
>> +
>> + mutex_lock(&priv->lock);
>> +
>> + ret = regmap_clear_bits(regmap, priv->reg_enable,
>> + S2MU005_FLED_FLASH_EN(priv->channel));
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to disable flash LED\n");
>> + goto unlock;
>> + }
>> +
>> + if (!state)
>> + goto unlock;
>> +
>> + ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL0(priv->channel),
>> + S2MU005_FLED_FLASH_IOUT,
>> + FIELD_PREP(S2MU005_FLED_FLASH_IOUT,
>> + priv->flash_brightness));
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to set flash brightness\n");
>> + goto unlock;
>> + }
>> +
>> + ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL3(priv->channel),
>> + S2MU005_FLED_FLASH_TIMEOUT,
>> + FIELD_PREP(S2MU005_FLED_FLASH_TIMEOUT,
>> + priv->flash_timeout));
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to set flash timeout\n");
>> + goto unlock;
>> + }
>> +
>> + ret = regmap_set_bits(regmap, priv->reg_enable,
>> + S2MU005_FLED_FLASH_EN(priv->channel));
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to enable flash LED\n");
>> + goto unlock;
>> + }
>> +
>> +unlock:
>> + mutex_unlock(&priv->lock);
>> +
>> + return 0;
>> +}
>> +
>> +static int s2mu005_fled_flash_strobe_get(struct led_classdev_flash *cdev,
>> + bool *state)
>> +{
>> + struct s2m_fled *priv = to_led_priv(cdev);
>> + struct regmap *regmap = priv->regmap;
>
> Since this is only used once, I don't see anything to gain from
> utilising a local variable here.
>
>> + u8 channel = priv->channel;
>
> Same here.
>
>> + u32 val;
>> + int ret;
>> +
>> + mutex_lock(&priv->lock);
>> +
>> + ret = regmap_read(regmap, S2MU005_REG_FLED_STATUS, &val);
>> + if (ret < 0) {
>> + dev_err(priv->dev, "failed to fetch LED status");
>> + goto unlock;
>> + }
>> +
>> + *state = !!(val & S2MU005_FLED_FLASH_STATUS(channel));
>> +
>> +unlock:
>> + mutex_unlock(&priv->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static const struct led_flash_ops s2mu005_fled_flash_ops = {
>> + .flash_brightness_set = s2m_fled_flash_brightness_set,
>> + .timeout_set = s2m_fled_flash_timeout_set,
>> + .strobe_set = s2mu005_fled_flash_strobe_set,
>> + .strobe_get = s2mu005_fled_flash_strobe_get,
>> +};
>> +
>> +static int s2mu005_fled_init(struct s2m_fled *priv)
>> +{
>> + unsigned int val;
>> + int ret;
>> +
>> + /* Enable the LED channels. */
>> + ret = regmap_set_bits(priv->regmap, S2MU005_REG_FLED_CTRL1,
>> + S2MU005_FLED_CH_EN);
>
> Feel free to use up to 100-char to eradicate these wraps.
>
>> + if (ret < 0)
>> + return dev_err_probe(priv->dev, ret, "failed to enable LED channels\n");
>> +
>> + /*
>> + * Get the LED enable register address. Revision EVT0 has the
>> + * register at CTRL4, while EVT1 and higher have it at CTRL6.
>> + */
>> + ret = regmap_read(priv->regmap, S2MU005_REG_ID, &val);
>> + if (ret < 0)
>> + return dev_err_probe(priv->dev, ret, "failed to read revision\n");
>> +
>> + if (FIELD_GET(S2MU005_ID_MASK, val) == 0)
>
> A comment above to explain what this means please.
A comment is right above the regmap read. I will shift it below. (Seems
also like its a bit incorrect, will fix that too.)
>
> And/or define the zero to something obvious.
>
>> + priv->reg_enable = S2MU005_REG_FLED_CTRL4;
>> + else
>> + priv->reg_enable = S2MU005_REG_FLED_CTRL6;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct s2m_fled_spec s2mu005_fled_spec = {
>> + .nr_channels = 2,
>> + .torch_max_brightness = 16,
>> + .flash_min_current_ua = 25000,
>> + .flash_max_current_ua = 375000, /* 400000 causes flickering */
>> + .flash_min_timeout_us = 62000,
>> + .flash_max_timeout_us = 992000,
>> + .torch_brightness_set_blocking = s2mu005_fled_torch_brightness_set,
>> + .flash_ops = &s2mu005_fled_flash_ops,
>> +};
>> +
>> +static int s2m_fled_init_channel(struct s2m_fled *priv,
>> + struct fwnode_handle *fwnp)
>
> Unwrap all of these that fit into 100-chars.
>
>> +{
>> + struct led_classdev *led = &priv->cdev.led_cdev;
>> + struct led_init_data init_data = {};
>> + struct v4l2_flash_config v4l2_cfg = {};
>> + int ret;
>> +
>> + led->max_brightness = priv->spec->torch_max_brightness;
>> + led->brightness_set_blocking = priv->spec->torch_brightness_set_blocking;
>> + led->flags |= LED_DEV_CAP_FLASH;
>> +
>> + priv->cdev.timeout.min = priv->spec->flash_min_timeout_us;
>> + priv->cdev.timeout.step = priv->spec->flash_min_timeout_us;
>> + priv->cdev.timeout.max = priv->spec->flash_max_timeout_us;
>> + priv->cdev.timeout.val = priv->spec->flash_max_timeout_us;
>> +
>> + priv->cdev.brightness.min = priv->spec->flash_min_current_ua;
>> + priv->cdev.brightness.step = priv->spec->flash_min_current_ua;
>> + priv->cdev.brightness.max = priv->spec->flash_max_current_ua;
>> + priv->cdev.brightness.val = priv->spec->flash_max_current_ua;
>
> Moving things around in priv/data tells me that something isn't right.
>
> I think the spec should be removed from what is currently called priv.
>
>> + s2m_fled_flash_timeout_set(&priv->cdev, priv->cdev.timeout.val);
>> + s2m_fled_flash_brightness_set(&priv->cdev, priv->cdev.brightness.val);
>> +
>> + priv->cdev.ops = priv->spec->flash_ops;
>> +
>> + init_data.fwnode = fwnp;
>> + ret = devm_led_classdev_flash_register_ext(priv->dev, &priv->cdev,
>> + &init_data);
>> + if (ret < 0)
>> + return dev_err_probe(priv->dev, ret, "failed to create LED flash device\n");
>> +
>> + v4l2_cfg.intensity.min = priv->spec->flash_min_current_ua;
>> + v4l2_cfg.intensity.step = priv->spec->flash_min_current_ua;
>> + v4l2_cfg.intensity.max = priv->spec->flash_max_current_ua;
>> + v4l2_cfg.intensity.val = priv->spec->flash_max_current_ua;
>> +
>> + v4l2_cfg.has_external_strobe = true;
>> +
>> + priv->v4l2_flash = v4l2_flash_init(priv->dev, fwnp, &priv->cdev,
>> + &s2m_fled_v4l2_flash_ops, &v4l2_cfg);
>> + if (IS_ERR(priv->v4l2_flash)) {
>> + v4l2_flash_release(priv->v4l2_flash);
>> + return dev_err_probe(priv->dev, PTR_ERR(priv->v4l2_flash),
>> + "failed to create V4L2 flash device\n");
>> + }
>> +
>> + ret = devm_add_action_or_reset(priv->dev, (void *)s2m_fled_v4l2_flash_release,
>> + priv->v4l2_flash);
>> + if (ret < 0)
>> + return dev_err_probe(priv->dev, ret, "failed to add cleanup action\n");
>
> v4l2_flash_release()?
Why would we call flash_release here? it should be called when the
driver is unloaded.
Regarding that, I have added an action which does exactly that. The
actual function is wrapped in s2m_fled_v4l2_flash_release() so as to not
make CFI unhappy.
>
>> + return 0;
>> +}
>> +
>> +static int s2m_fled_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct sec_pmic_dev *pmic_drvdata = dev_get_drvdata(dev->parent);
>
> s/pmic_drvdata/ddata/
>
>> + struct s2m_fled *priv;
>> + bool channel_initialized[MAX_CHANNELS] = { false };
>> + int ret;
>> +
>> + priv = devm_kzalloc(dev, sizeof(*priv) * MAX_CHANNELS, GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + platform_set_drvdata(pdev, priv);
>
> Where is this used?
>> + priv->dev = dev;
>
> This is already available to you in what is currently called:
>
> priv->cdev->led_cdev->dev
I am assuming priv->dev is to be removed so as to save space.
>
> Also, isn't this an array?
>
Yeah so, about that. It allocates n-many s2m_fled (now s2m_led) for
n-many LEDs. it does all allocations in the first struct here, and then
for subsequent LEDs it copies them over (that's the convoluted logic
below). Not the cleanest solution, maybe there's a better way to solve
it? [a solution discussed below]
>> + priv->regmap = pmic_drvdata->regmap_pmic;
>> +
>> + switch (platform_get_device_id(pdev)->driver_data) {
>> + case S2MU005:
>> + priv->spec = &s2mu005_fled_spec;
>> + ret = s2mu005_fled_init(priv);
>> + if (ret)
>> + return ret;
>> + break;
>> + default:
>> + return dev_err_probe(dev, -ENODEV,
>> + "device type %d is not supported by driver\n",
>> + pmic_drvdata->device_type);
>> + }
>> +
>> + if (priv->spec->nr_channels > MAX_CHANNELS)
>> + return dev_err_probe(dev, -EINVAL,
>> + "number of channels specified (%u) exceeds the limit (%u)\n",
>> + priv->spec->nr_channels, MAX_CHANNELS);
>> +
>> + device_for_each_child_node_scoped(dev, child) {
>> + u32 reg;
>> +
>> + if (fwnode_property_read_u32(child, "reg", ®))
>> + continue;
>> +
>> + if (reg >= priv->spec->nr_channels) {
>> + dev_warn(dev, "channel %d is non-existent\n", reg);
>> + continue;
>> + }
>> +
>> + if (channel_initialized[reg]) {
>
> Do you really need a whole variable just for this?
>
> If this a risk? If it really is, why not check (priv[reg].dev)?
Your above comment suggests an alternative approach to get dev from
priv. Assuming you implied that priv->dev be removed, doesn't this come
in conflict?
The same thing however can be done with regmap, so that's a possibility.
I will move over the `priv->regmap = pmic_drvdata->regmap_pmic` from
above and add it only if the channel is initialized.
As a bonus this also removes "setting pointers to the first element and
copying them over" procedure, that would be a cleaner solution as well.
>> + dev_warn(dev, "duplicate node for channel %d\n", reg);
>> + continue;
>> + }
>> +
>> + priv[reg].dev = priv->dev;
>
> What on earth is going on here?
>
>> + priv[reg].regmap = priv->regmap;
>> + priv[reg].spec = priv->spec;
>> + priv[reg].reg_enable = priv->reg_enable;
>
> And why do you need ${reg} copies of the same data?
>
> Sounds like a waste of resources, no?
>
>> + priv[reg].channel = (u8)reg;
>> +
>> + ret = devm_mutex_init(dev, &priv[reg].lock);
>
> Why not just look the whole device? Rather than per channel?
>
> To channels have no shared resources?
No, they are independent as far as I can tell.
>> + if (ret)
>> + return dev_err_probe(dev, ret, "failed to create mutex lock\n");
>
> You can drop the ' lock' part.
>
>> +
>> + ret = s2m_fled_init_channel(priv + reg, child);
>> + if (ret < 0)
>> + return ret;
>> +
>> + channel_initialized[reg] = true;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static const struct platform_device_id s2m_fled_id_table[] = {
>> + { "s2mu005-flash", S2MU005 },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(platform, s2m_fled_id_table);
>> +
>> +/*
>> + * Device is instantiated through parent MFD device and device matching
>> + * is done through platform_device_id.
>> + *
>> + * However if device's DT node contains proper compatible and driver is
>> + * built as a module, then the *module* matching will be done through DT
>> + * aliases. This requires of_device_id table. In the same time this will
>> + * not change the actual *device* matching so do not add .of_match_table.
>> + */
>
> All of this is already implied.
>
> No need to have this comment on all MFD sub-devices.
>
>> +static const struct of_device_id s2m_fled_of_match_table[] = {
>> + {
>> + .compatible = "samsung,s2mu005-flash",
>> + .data = (void *)S2MU005,
>
> These usually fit on a single line.
>
>> + }, {
>> + /* sentinel */
>> + },
>> +};
>> +MODULE_DEVICE_TABLE(of, s2m_fled_of_match_table);
>> +
>> +static struct platform_driver s2m_fled_driver = {
>> + .driver = {
>> + .name = "s2m-flash",
>> + },
>> + .probe = s2m_fled_probe,
>> + .id_table = s2m_fled_id_table,
>> +};
>> +module_platform_driver(s2m_fled_driver);
>> +
>> +MODULE_DESCRIPTION("Flash/Torch LED Driver For Samsung S2M Series PMICs");
>> +MODULE_AUTHOR("Kaustabh Chakraborty <kauschluss@disroot.org>");
>> +MODULE_LICENSE("GPL");
>>
>> --
>> 2.52.0
>>
^ permalink raw reply
* [PATCH v2] 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: praneeth, nm, vigneshr, alexandre.belloni, linux-rtc,
linux-kernel
Cc: msp, vishalm, sebin.francis, a-kaur
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.
Changes in v2:
-Updated the commit message as suggested in review
-Link to v1: https://lore.kernel.org/all/20260311070214.3589965-1-a-kaur@ti.com/
---
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);
--
2.34.1
^ permalink raw reply related
* 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
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