* [PATCH v3 3/6] dt-bindings: gpio: trivial-gpio: remove max77620 compatible
From: Svyatoslav Ryhel @ 2026-03-06 13:33 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: <20260306133351.31589-1-clamor95@gmail.com>
Binding for MAX77620 GPIO function is covered by the MAX77620 schema. 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>
---
Documentation/devicetree/bindings/gpio/trivial-gpio.yaml | 2 --
1 file changed, 2 deletions(-)
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
--
2.51.0
^ permalink raw reply related
* [PATCH v3 2/6] dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-06 13:33 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: <20260306133351.31589-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..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_]+$":
+ type: object
+
+ properties:
+ pins:
+ enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ]
+ minItems: 1
+ maxItems: 8
+
+ function:
+ 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 v3 1/6] regulator: dt-binding: regulator-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-06 13:33 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: <20260306133351.31589-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>
---
.../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..e8c374cfaef9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: GPL-2.0
+%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 v3 0/6] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-03-06 13:33 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 v3
- max77620 files converted to DT schema.
Changes in v2
- dropped patch that changes max77686 and adjusted max77620 where max77663
is described.
---
Svyatoslav Ryhel (6):
regulator: dt-binding: regulator-max77620: convert to DT schema
dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
dt-bindings: gpio: trivial-gpio: remove max77620 compatible
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 | 442 ++++++++++++++++++
.../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, 650 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 1/5] clk: renesas: r9a09g056: Fix ordering of module clocks array
From: Geert Uytterhoeven @ 2026-03-06 12:35 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <CAMuHMdWZKUjptQCqe_DK3C_g5d9Zhp3r3j6+dAfE1g==NH+ofw@mail.gmail.com>
On Mon, 26 Jan 2026 at 16:27, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, 25 Jan 2026 at 20:27, Ovidiu Panait
> <ovidiu.panait.rb@renesas.com> wrote:
> > The r9a09g056_mod_clks array is sorted by CPG_CLKON register number and
> > bit position. Move the RSPI 0/1/2 module clock entries to their correct
> > position to restore the array sort order.
> >
> > Fixes: 1f76689d1715 ("clk: renesas: r9a09g056: Add entries for RSCIs")
> > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-clk for v6.21.
Promoting to renesas-clk-fixes for v7.0, as I have other fixes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal
From: Alexandre Belloni @ 2026-03-06 11:13 UTC (permalink / raw)
To: Tomas Melin
Cc: Takumi Ando, linux-rtc, michal.simek, Yasushi SHOJI, kanta tamura
In-Reply-To: <9ed6823e-b381-4de5-b1cf-98f5dc54bb7c@vaisala.com>
On 06/03/2026 12:09:40+0200, Tomas Melin wrote:
> > On Zynq UltraScale+ Devices Register Reference (UG1087) [2],
> > CALIB_RD resets to 0, so the current logic works correctly there.
> > However, this assumption does not appear to hold for Versal.
>
> For Ultrascale+ the calibration register also gives random values after
> reset, perhaps you have noticed this:
> https://adaptivesupport.amd.com/s/article/000036886?language=en_US. Maybe
> the same can occur also on Versal.
>
> AFAIK there is no way of knowing if the value is correct or not after reset,
> so user space helpers might be needed to maintain the calibration value at a
> desired value.
>
Userspace is always needed to put the proper calibration, there is no
way for the kernel to know what value to put there. In the support case
above, the crystal will never be exactly 32768Hz and this value will
change over time and also depends on the temperature. The value always
needs to be computed, if your device can do NTP, chrony will provide the
proper offsets. If you don't have a way to measure the deviation, then
userspace can always forcefully set /sys/class/rtc/rtcX/offset if it
doesn't hold the correct value.
There is no need for devmem here.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal
From: Tomas Melin @ 2026-03-06 10:09 UTC (permalink / raw)
To: Takumi Ando, linux-rtc
Cc: alexandre.belloni, michal.simek, Yasushi SHOJI, kanta tamura
In-Reply-To: <CAJACUaoFK-GiBN_hfkNajDUygnSZc29U_jdeQ_rKtXS7P1f-nw@mail.gmail.com>
Hi,
On 05/03/2026 11:24, Takumi Ando wrote:
> [You don't often get email from takumi@spacecubics.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi,
>
> I have a question about the initialization logic in the zynqmp RTC
> driver(drivers/rtc/rtc-zynqmp.c).
>
> Currently the driver programs CALIB_WRITE only when CALIB_READ returns 0:
>
> ret = readl(... + RTC_CALIB_RD);
> if (!ret)
> writel(freq, ... + RTC_CALIB_WR);
>
> My understanding is that this was designed to avoid overwriting an
> existing calibration value. Since the RTC may continue running from the
> battery domain even when Linux is not running, the calibration value may
> have been configured previously and should be preserved.
>
> However, according to the Versal Adaptive SoC Register Reference (AM012) [1],
> the value returned by CALIB_RD after reset can be undefined.
> In practice, on Versal hardware we observe non-zero values even before
> any calibration has been programmed. Because of this, the current logic
> may skip programming CALIB_WR and leave the Max_Tick field uninitialized.
>
> On Zynq UltraScale+ Devices Register Reference (UG1087) [2],
> CALIB_RD resets to 0, so the current logic works correctly there.
> However, this assumption does not appear to hold for Versal.
For Ultrascale+ the calibration register also gives random values after
reset, perhaps you have noticed this:
https://adaptivesupport.amd.com/s/article/000036886?language=en_US.
Maybe the same can occur also on Versal.
AFAIK there is no way of knowing if the value is correct or not after
reset, so user space helpers might be needed to maintain the calibration
value at a desired value.
thanks,
Tomas
>
> If there is a register or mechanism that indicates whether the RTC has
> already been calibrated, the driver could use that instead. However,
> I could not find such an indicator in the documentation.
>
> Am I missing something here? Is there a recommended way to detect whether
> RTC calibration has already been configured?
>
> Alternatively, would it be acceptable for the driver to always program
> Max_Tick while preserving the fractional calibration bits already stored
> in hardware?
>
> Best regards,
>
> [1] https://docs.amd.com/r/en-US/am012-versal-register-reference/CALIB_READ-PMC_RTC-Register
> [2] https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
>
> --
> Takumi Ando
> Space Cubics Inc.
>
^ permalink raw reply
* Re: [PATCH v3 07/13] mfd: sec: set DMA coherent mask
From: André Draszik @ 2026-03-06 7:03 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <20260225-s2mu005-pmic-v3-7-b4afee947603@disroot.org>
On Wed, 2026-02-25 at 00:45 +0530, Kaustabh Chakraborty wrote:
> Kernel logs are filled with "DMA mask not set" messages for every
> sub-device. The device does not use DMA for communication, so these
> messages are useless. Disable the coherent DMA mask for the PMIC device,
> which is also propagated to sub-devices.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> drivers/mfd/sec-i2c.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mfd/sec-i2c.c b/drivers/mfd/sec-i2c.c
> index d8609886fcc80..9fa1449a4f6eb 100644
> --- a/drivers/mfd/sec-i2c.c
> +++ b/drivers/mfd/sec-i2c.c
> @@ -177,6 +177,9 @@ static int sec_pmic_i2c_probe(struct i2c_client *client)
> return dev_err_probe(&client->dev, PTR_ERR(regmap_pmic),
> "regmap init failed\n");
>
> + client->dev.coherent_dma_mask = 0;
> + client->dev.dma_mask = &client->dev.coherent_dma_mask;
> +
This should probably move into sec-common.c as it should apply to all
transports.
Cheers,
A.
^ permalink raw reply
* Re: [PATCH v3 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Rob Herring @ 2026-03-06 0:50 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Krzysztof Kozlowski, Lee Jones, Pavel Machek, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
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: <DGPTBRX09EU5.1D1ZSR7EUV7AT@disroot.org>
On Fri, Feb 27, 2026 at 07:56:58PM +0530, Kaustabh Chakraborty wrote:
> On 2026-02-25 11:44 +01:00, Krzysztof Kozlowski wrote:
> > On Wed, Feb 25, 2026 at 12:45:06AM +0530, Kaustabh Chakraborty wrote:
> >> +
> >> + This is a part of device tree bindings for S2M and S5M family of Power
> >> + Management IC (PMIC).
> >> +
> >> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
> >> + additional information and example.
> >> +
> >> +allOf:
> >> + - $ref: power-supply.yaml#
> >> +
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - samsung,s2mu005-charger
> >
> > Review from v1 still applies. I think you ignored several reviews, so I
> > will mark entire patchset as changes requested.
>
> Somehow I missed this one... anyways I address them here:
>
> Why do you need a dedicated child node for this? It's got one property,
> other than the compatible, that you're using. It could easily just go
> in the parent without a dedicated node etc.
>
> The dt node also references a simple-battery node, that's why it's
> required.
That can go in the parent.
Rob
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: input: mtk-pmic-keys: add MT6392 binding definition
From: Rob Herring (Arm) @ 2026-03-06 0:29 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Louis-Alexis Eyraud, AngeloGioacchino Del Regno, linux-input,
Matthias Brugger, Sen Chu, Liam Girdwood, Sean Wang,
Alexandre Belloni, Julien Massot, linux-arm-kernel, Eddie Huang,
linux-kernel, Conor Dooley, Gary Bisson, Lee Jones,
Krzysztof Kozlowski, Fabien Parent, Val Packett, Macpaul Lin,
linux-rtc, devicetree, Dmitry Torokhov, linux-mediatek,
Mark Brown, linux-pm, Chen Zhong
In-Reply-To: <056cbc09fcbb4a2845cece69209a2a564d993ac5.1771865015.git.l.scorcia@gmail.com>
On Mon, 23 Feb 2026 17:12:42 +0000, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the binding documentation of the mtk-pmic-keys for the MT6392 PMICs.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: regulator: add support for MT6392
From: Rob Herring (Arm) @ 2026-03-06 0:28 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Mark Brown, Chen Zhong, Macpaul Lin, linux-pm,
Krzysztof Kozlowski, Lee Jones, linux-kernel, Dmitry Torokhov,
Louis-Alexis Eyraud, devicetree, linux-mediatek, Julien Massot,
Liam Girdwood, Alexandre Belloni, Fabien Parent, linux-input,
linux-rtc, Matthias Brugger, Val Packett, Sen Chu, Conor Dooley,
linux-arm-kernel, AngeloGioacchino Del Regno, Gary Bisson,
Eddie Huang, Sean Wang
In-Reply-To: <b7664f4d9a7b038b0603b6bba79cfab4e18cbdd6.1771865015.git.l.scorcia@gmail.com>
On Mon, 23 Feb 2026 17:12:41 +0000, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add binding documentation of the regulator for MT6392 SoCs.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mfd: max77620: document optional RTC address for max77663
From: Rob Herring @ 2026-03-05 23:56 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Conor Dooley,
Alexandre Belloni, linux-kernel, devicetree, linux-rtc
In-Reply-To: <20260223064343.12516-2-clamor95@gmail.com>
On Mon, Feb 23, 2026 at 08:43:42AM +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.
No changes to .txt bindings. Convert to schema first if you have
additions.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/devicetree/bindings/mfd/max77620.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
> index 5a642a51d58e..0bbb42e5dcfe 100644
> --- a/Documentation/devicetree/bindings/mfd/max77620.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77620.txt
> @@ -6,10 +6,12 @@ Required properties:
> "maxim,max77620"
> "maxim,max20024"
> "maxim,max77663"
> -- reg: I2C device address.
> +- reg: I2C device address. In case of MAX77663 there can be 2 addresses,
> + second one specifies position of RTC.
>
> Optional properties:
> -------------------
> +- reg-names: If 2 addresses are specified then, must be "pmic", "rtc"
> - interrupts: The interrupt on the parent the controller is
> connected to.
> - interrupt-controller: Marks the device node as an interrupt controller.
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH 3/6] regulator: dt-bindings: sc2731: Deprecate compatible property
From: Rob Herring (Arm) @ 2026-03-05 23:53 UTC (permalink / raw)
To: Otto Pflüger
Cc: linux-pm, Lee Jones, Liam Girdwood, Chunyan Zhang,
Krzysztof Kozlowski, Mark Brown, Conor Dooley, linux-kernel,
linux-rtc, Alexandre Belloni, Pavel Machek, Sebastian Reichel,
devicetree, Orson Zhai, Baolin Wang, linux-leds
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-3-69526fe74c77@abscue.de>
On Sun, 22 Feb 2026 14:16:47 +0100, Otto Pflüger wrote:
> The node containing the regulators is always a child of the main PMIC
> node, which already has a compatible property identifying the type of
> PMIC. This makes the compatible in the child node redundant. Mark it
> as deprecated and remove it from the required property list and the
> examples.
>
> Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> ---
> Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml | 2 --
> .../devicetree/bindings/regulator/sprd,sc2731-regulator.yaml | 4 +---
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: rtc: sc2731: Add compatible for SC2730
From: Rob Herring (Arm) @ 2026-03-05 23:51 UTC (permalink / raw)
To: Otto Pflüger
Cc: Chunyan Zhang, devicetree, Krzysztof Kozlowski, Sebastian Reichel,
linux-leds, Lee Jones, Conor Dooley, Liam Girdwood, linux-rtc,
Mark Brown, Alexandre Belloni, Pavel Machek, linux-pm,
Baolin Wang, linux-kernel, Orson Zhai
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-1-69526fe74c77@abscue.de>
On Sun, 22 Feb 2026 14:16:45 +0100, Otto Pflüger wrote:
> The RTC block found in the SC2730 PMIC is compatible with the one found
> in the SC2731 PMIC.
>
> Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> ---
> Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: leds: sc2731: Add compatible for SC2730
From: Rob Herring (Arm) @ 2026-03-05 23:51 UTC (permalink / raw)
To: Otto Pflüger
Cc: Krzysztof Kozlowski, Chunyan Zhang, Sebastian Reichel, devicetree,
Alexandre Belloni, Orson Zhai, linux-kernel, Liam Girdwood,
Pavel Machek, Mark Brown, linux-rtc, linux-leds, Lee Jones,
Conor Dooley, linux-pm, Baolin Wang
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-2-69526fe74c77@abscue.de>
On Sun, 22 Feb 2026 14:16:46 +0100, Otto Pflüger wrote:
> The LED controller found in the SC2730 PMIC is compatible with the one
> found in the SC2731 PMIC.
>
> Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> ---
> Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/6] Remove use of i2c_match_id in RTC
From: Alexandre Belloni @ 2026-03-05 23:07 UTC (permalink / raw)
To: Andrew Davis; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
On 05/03/2026 13:35:39-0600, Andrew Davis wrote:
> Hello all,
>
> 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.
Do you mean that you intend to remove i2c_match_id from the kernel?
>
> Thanks,
> Andrew
>
> Andrew Davis (6):
> rtc: abx80x: Remove use of i2c_match_id()
> rtc: m41t80: Remove use of i2c_match_id()
> rtc: pcf2127: Remove use of i2c_match_id()
> rtc: rs5c372: Remove use of i2c_match_id()
> rtc: rv8803: Remove use of i2c_match_id()
> rtc: rx8025: Remove use of i2c_match_id()
>
> drivers/rtc/rtc-abx80x.c | 3 +--
> drivers/rtc/rtc-m41t80.c | 8 +-------
> drivers/rtc/rtc-pcf2127.c | 23 +++++++----------------
> drivers/rtc/rtc-rs5c372.c | 7 +------
> drivers/rtc/rtc-rv8803.c | 8 +-------
> drivers/rtc/rtc-rx8025.c | 4 +---
> 6 files changed, 12 insertions(+), 41 deletions(-)
>
> --
> 2.39.2
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 4/6] rtc: rs5c372: Remove use of i2c_match_id()
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/rtc/rtc-rs5c372.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index f8fab0205f8cc..936f4f05c8c7a 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -825,12 +825,7 @@ static int rs5c372_probe(struct i2c_client *client)
rs5c372->client = client;
i2c_set_clientdata(client, rs5c372);
- if (client->dev.of_node) {
- rs5c372->type = (uintptr_t)of_device_get_match_data(&client->dev);
- } else {
- const struct i2c_device_id *id = i2c_match_id(rs5c372_id, client);
- rs5c372->type = id->driver_data;
- }
+ rs5c372->type = (uintptr_t)i2c_get_match_data(client);
/* we read registers 0x0f then 0x00-0x0f; skip the first one */
rs5c372->regs = &rs5c372->buf[1];
--
2.39.2
^ permalink raw reply related
* [PATCH v2 3/6] rtc: pcf2127: Remove use of i2c_match_id()
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/rtc/rtc-pcf2127.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index bb4fe81d3d62c..e4785c5a55d03 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -1449,10 +1449,10 @@ static const struct regmap_bus pcf2127_i2c_regmap = {
static struct i2c_driver pcf2127_i2c_driver;
static const struct i2c_device_id pcf2127_i2c_id[] = {
- { "pcf2127", PCF2127 },
- { "pcf2129", PCF2129 },
- { "pca2129", PCF2129 },
- { "pcf2131", PCF2131 },
+ { "pcf2127", (kernel_ulong_t)&pcf21xx_cfg[PCF2127] },
+ { "pcf2129", (kernel_ulong_t)&pcf21xx_cfg[PCF2129] },
+ { "pca2129", (kernel_ulong_t)&pcf21xx_cfg[PCF2129] },
+ { "pcf2131", (kernel_ulong_t)&pcf21xx_cfg[PCF2131] },
{ }
};
MODULE_DEVICE_TABLE(i2c, pcf2127_i2c_id);
@@ -1469,18 +1469,9 @@ static int pcf2127_i2c_probe(struct i2c_client *client)
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
- if (client->dev.of_node) {
- variant = of_device_get_match_data(&client->dev);
- if (!variant)
- return -ENODEV;
- } else {
- enum pcf21xx_type type =
- i2c_match_id(pcf2127_i2c_id, client)->driver_data;
-
- if (type >= PCF21XX_LAST_ID)
- return -ENODEV;
- variant = &pcf21xx_cfg[type];
- }
+ variant = i2c_get_match_data(client);
+ if (!variant)
+ return -ENODEV;
config.max_register = variant->max_register,
--
2.39.2
^ permalink raw reply related
* [PATCH v2 5/6] rtc: rv8803: Remove use of i2c_match_id()
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/rtc/rtc-rv8803.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-rv8803.c b/drivers/rtc/rtc-rv8803.c
index 4e9e04cbec89a..2bf988a89fd7b 100644
--- a/drivers/rtc/rtc-rv8803.c
+++ b/drivers/rtc/rtc-rv8803.c
@@ -667,13 +667,7 @@ static int rv8803_probe(struct i2c_client *client)
mutex_init(&rv8803->flags_lock);
rv8803->client = client;
- if (client->dev.of_node) {
- rv8803->type = (uintptr_t)of_device_get_match_data(&client->dev);
- } else {
- const struct i2c_device_id *id = i2c_match_id(rv8803_id, client);
-
- rv8803->type = id->driver_data;
- }
+ rv8803->type = (uintptr_t)i2c_get_match_data(client);
i2c_set_clientdata(client, rv8803);
flags = rv8803_read_reg(client, RV8803_FLAG);
--
2.39.2
^ permalink raw reply related
* [PATCH v2 6/6] rtc: rx8025: Remove use of i2c_match_id()
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/rtc/rtc-rx8025.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-rx8025.c b/drivers/rtc/rtc-rx8025.c
index ced6e7adfe8d0..c57081f9e02b4 100644
--- a/drivers/rtc/rtc-rx8025.c
+++ b/drivers/rtc/rtc-rx8025.c
@@ -522,7 +522,6 @@ static const struct attribute_group rx8025_attr_group = {
static int rx8025_probe(struct i2c_client *client)
{
- const struct i2c_device_id *id = i2c_match_id(rx8025_id, client);
struct i2c_adapter *adapter = client->adapter;
struct rx8025_data *rx8025;
int err = 0;
@@ -540,8 +539,7 @@ static int rx8025_probe(struct i2c_client *client)
i2c_set_clientdata(client, rx8025);
- if (id)
- rx8025->model = id->driver_data;
+ rx8025->model = (uintptr_t)i2c_get_match_data(client);
err = rx8025_init_client(client);
if (err)
--
2.39.2
^ permalink raw reply related
* [PATCH v2 0/6] Remove use of i2c_match_id in RTC
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
Hello all,
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
Andrew Davis (6):
rtc: abx80x: Remove use of i2c_match_id()
rtc: m41t80: Remove use of i2c_match_id()
rtc: pcf2127: Remove use of i2c_match_id()
rtc: rs5c372: Remove use of i2c_match_id()
rtc: rv8803: Remove use of i2c_match_id()
rtc: rx8025: Remove use of i2c_match_id()
drivers/rtc/rtc-abx80x.c | 3 +--
drivers/rtc/rtc-m41t80.c | 8 +-------
drivers/rtc/rtc-pcf2127.c | 23 +++++++----------------
drivers/rtc/rtc-rs5c372.c | 7 +------
drivers/rtc/rtc-rv8803.c | 8 +-------
drivers/rtc/rtc-rx8025.c | 4 +---
6 files changed, 12 insertions(+), 41 deletions(-)
--
2.39.2
^ permalink raw reply
* [PATCH v2 2/6] rtc: m41t80: Remove use of i2c_match_id()
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/rtc/rtc-m41t80.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
index 740cab013f590..b26afef37d9cf 100644
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -924,13 +924,7 @@ static int m41t80_probe(struct i2c_client *client)
return -ENOMEM;
m41t80_data->client = client;
- if (client->dev.of_node) {
- m41t80_data->features = (unsigned long)
- of_device_get_match_data(&client->dev);
- } else {
- const struct i2c_device_id *id = i2c_match_id(m41t80_id, client);
- m41t80_data->features = id->driver_data;
- }
+ m41t80_data->features = (unsigned long)i2c_get_match_data(client);
i2c_set_clientdata(client, m41t80_data);
m41t80_data->rtc = devm_rtc_allocate_device(&client->dev);
--
2.39.2
^ permalink raw reply related
* [PATCH v2 1/6] rtc: abx80x: Remove use of i2c_match_id()
From: Andrew Davis @ 2026-03-05 19:35 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Andrew Davis
In-Reply-To: <20260305193545.796294-1-afd@ti.com>
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/rtc/rtc-abx80x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
index 3fee27914ba80..eca09872ea971 100644
--- a/drivers/rtc/rtc-abx80x.c
+++ b/drivers/rtc/rtc-abx80x.c
@@ -772,8 +772,7 @@ static int abx80x_probe(struct i2c_client *client)
struct abx80x_priv *priv;
int i, data, err, trickle_cfg = -EINVAL;
char buf[7];
- const struct i2c_device_id *id = i2c_match_id(abx80x_id, client);
- unsigned int part = id->driver_data;
+ unsigned int part = (uintptr_t)i2c_get_match_data(client);
unsigned int partnumber;
unsigned int majrev, minrev;
unsigned int lot;
--
2.39.2
^ permalink raw reply related
* [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal
From: Takumi Ando @ 2026-03-05 9:24 UTC (permalink / raw)
To: linux-rtc; +Cc: alexandre.belloni, michal.simek, Yasushi SHOJI, kanta tamura
Hi,
I have a question about the initialization logic in the zynqmp RTC
driver(drivers/rtc/rtc-zynqmp.c).
Currently the driver programs CALIB_WRITE only when CALIB_READ returns 0:
ret = readl(... + RTC_CALIB_RD);
if (!ret)
writel(freq, ... + RTC_CALIB_WR);
My understanding is that this was designed to avoid overwriting an
existing calibration value. Since the RTC may continue running from the
battery domain even when Linux is not running, the calibration value may
have been configured previously and should be preserved.
However, according to the Versal Adaptive SoC Register Reference (AM012) [1],
the value returned by CALIB_RD after reset can be undefined.
In practice, on Versal hardware we observe non-zero values even before
any calibration has been programmed. Because of this, the current logic
may skip programming CALIB_WR and leave the Max_Tick field uninitialized.
On Zynq UltraScale+ Devices Register Reference (UG1087) [2],
CALIB_RD resets to 0, so the current logic works correctly there.
However, this assumption does not appear to hold for Versal.
If there is a register or mechanism that indicates whether the RTC has
already been calibrated, the driver could use that instead. However,
I could not find such an indicator in the documentation.
Am I missing something here? Is there a recommended way to detect whether
RTC calibration has already been configured?
Alternatively, would it be acceptable for the driver to always program
Max_Tick while preserving the fractional calibration bits already stored
in hardware?
Best regards,
[1] https://docs.amd.com/r/en-US/am012-versal-register-reference/CALIB_READ-PMC_RTC-Register
[2] https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
--
Takumi Ando
Space Cubics Inc.
^ permalink raw reply
* Re: [PATCH] rtc: armada38x: zalloc + calloc to single allocation
From: Rosen Penev @ 2026-03-05 8:51 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-rtc, Andrew Lunn, Sebastian Hesselbarth, Alexandre Belloni,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <871phyfz34.fsf@BLaptop.bootlin.com>
On Thu, Mar 5, 2026 at 12:41 AM Gregory CLEMENT
<gregory.clement@bootlin.com> wrote:
>
> Rosen Penev <rosenp@gmail.com> writes:
>
> > Use a flexible array member to simplify allocation.
> >
>
> I must admit that I didn't know struct_size(), it is a nice helper!
There's kzalloc_flex that's even nicer. Has no devm version yet.
>
> Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
>
> Thanks,
>
> Gregory
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/rtc/rtc-armada38x.c | 9 ++-------
> > 1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
> > index 713fa0d077cd..245290ae1a8d 100644
> > --- a/drivers/rtc/rtc-armada38x.c
> > +++ b/drivers/rtc/rtc-armada38x.c
> > @@ -72,8 +72,8 @@ struct armada38x_rtc {
> > spinlock_t lock;
> > int irq;
> > bool initialized;
> > - struct value_to_freq *val_to_freq;
> > const struct armada38x_rtc_data *data;
> > + struct value_to_freq val_to_freq[];
> > };
> >
> > #define ALARM1 0
> > @@ -490,18 +490,13 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
> > {
> > struct armada38x_rtc *rtc;
> >
> > - rtc = devm_kzalloc(&pdev->dev, sizeof(struct armada38x_rtc),
> > + rtc = devm_kzalloc(&pdev->dev, struct_size(rtc, val_to_freq, SAMPLE_NR),
> > GFP_KERNEL);
> > if (!rtc)
> > return -ENOMEM;
> >
> > rtc->data = of_device_get_match_data(&pdev->dev);
> >
> > - rtc->val_to_freq = devm_kcalloc(&pdev->dev, SAMPLE_NR,
> > - sizeof(struct value_to_freq), GFP_KERNEL);
> > - if (!rtc->val_to_freq)
> > - return -ENOMEM;
> > -
> > spin_lock_init(&rtc->lock);
> >
> > rtc->regs = devm_platform_ioremap_resource_byname(pdev, "rtc");
> > --
> > 2.53.0
> >
>
> --
> Grégory CLEMENT, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ 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