* Re: [PATCH 2/4] drm/bridge: display-connector: Fix I2C adapter resource leak
From: Laurent Pinchart @ 2026-07-17 18:28 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Johan Hovold, dri-devel, devicetree, Thuan Nguyen,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, linux-renesas-soc, stable
In-Reply-To: <DK0Y5JTE66EA.111RUXTL6W8FA@bootlin.com>
On Fri, Jul 17, 2026 at 05:21:11PM +0200, Luca Ceresoli wrote:
> On Fri Jul 17, 2026 at 5:03 PM CEST, Johan Hovold wrote:
> > On Mon, Jul 06, 2026 at 12:35:40AM +0300, Laurent Pinchart wrote:
> >> If the probe function returns an error after getting the I2C adapter for
> >> DDC, the reference to the adapter is never released. Fix it by releasing
> >> it in the bridge .destroy() handler.
> >>
> >> There is no need to test the ddc pointer with !IS_ERR(), as
> >> of_get_i2c_adapter_by_node() returns NULL on error.
> >
> > I stumbled over this this morning as well and posted a fix here (which
> > releases the adapter on driver unbind as is currently done):
> >
> > https://lore.kernel.org/lkml/20260717085716.1619275-1-johan@kernel.org/
> >
> >> Fixes: 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio support")
> >
> > I believe this issue was first introduced by commit 2e2bf3a5584d
> > ("drm/bridge: display-connector: add DP support") a few releases
> > earlier.
> >
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >
> > Reviewed-by: Johan Hovold <johan@kernel.org>
>
> While Johan's patch has the benefit of putting the i2c adapter at remove
> time (as opposed to destroy time, which is potentially a long time later),
> it is also more complex. So I'd say this patch is fine.
In this case putting the I2C adapter early is probably fine, but in
general I really prefer reference-counting and releasing references at
destroy time. This ensures that the resources stay available if they
need to be accessed between .remove() and destruction (for instance in a
.release() handler following a close() or munmap() from userspace). I
think late release should be the default, as it's safer, and early
release should be carefully reviewed when it's required.
> Maybe we should have a devm version of of_get_i2c_adapter_by_node() to make
> it all simpler.
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: ti,da850-pll: Convert to DT schema
From: sashiko-bot @ 2026-07-17 18:28 UTC (permalink / raw)
To: Bhargav Joshi; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260717-ti-pll-v1-1-f6f9ba8c9b5e@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The device tree schema example contains undefined phandle references (`&ref_clk` and `&pll1_sysclk`), which causes `dt_binding_check` to fail with compilation errors.
- [Medium] The schema fails to enforce strict bounds on `clocks` and `clock-names` inside conditional blocks, allowing invalid configurations to pass validation.
--
--- Patch [1]: [PATCH] dt-bindings: clock: ti,da850-pll: Convert to DT schema ---
commit d9fe4826c7bdb546d8ecd3e9ca8ac0454b95166c
Author: Bhargav Joshi <j.bhargav.u@gmail.com>
dt-bindings: clock: ti,da850-pll: Convert to DT schema
Convert TI da850-pll binding from legacy text to dt schema.
No functional change is introduced during conversion.
> diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml b/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml
> new file mode 100644
> index 0000000000000..5e4109567b75d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml
[ ... ]
> @@ -0,0 +1,177 @@
[ ... ]
> +allOf:
> + - if:
> + properties:
> + compatible:
> + const: ti,da850-pll0
> + then:
> + properties:
> + clocks:
> + items:
> + - description: Primary reference clock input
> + - description: External clock source
[Severity: Medium]
Since the global clocks property specifies minItems: 1 and maxItems: 2, does
this ti,da850-pll0 block also need minItems: 2?
Without it, a device tree node with only 1 clock could silently pass validation
by falling back to the global limits.
> + clock-names:
> + items:
> + - const: clksrc
> + - const: extclksrc
> +
> + - if:
> + properties:
> + compatible:
> + const: ti,da850-pll1
> + then:
> + properties:
> + clocks:
> + maxItems: 1
> + clock-names:
> + items:
> + - const: clksrc
[Severity: Medium]
Does this block need maxItems: 1 for clock-names?
Since the global clock-names property allows maxItems: 2, a node with two
clock-names might pass validation for the ti,da850-pll1 variant.
> + ti,clkmode-square-wave: false
> + auxclk: false
> +
> +examples:
> + - |
> + clock-controller@11000 {
> + compatible = "ti,da850-pll0";
> + reg = <0x11000 0x1000>;
> + clocks = <&ref_clk>, <&pll1_sysclk 3>;
[Severity: Medium]
Will this cause make dt_binding_check to fail?
The &ref_clk and &pll1_sysclk phandles are not defined in this example, which
usually causes dtc compilation errors (Reference to non-existent node or label)
during validation workflows.
> + clock-names = "clksrc", "extclksrc";
> + ti,clkmode-square-wave;
[ ... ]
> + - |
> + clock-controller@21a000 {
> + compatible = "ti,da850-pll1";
> + reg = <0x21a000 0x1000>;
> + clocks = <&ref_clk>;
[Severity: Medium]
Similar to the first example, this references &ref_clk without defining it.
Could this lead to a dtc compilation error during make dt_binding_check?
> + clock-names = "clksrc";
> +
> + sysclk {
> + #clock-cells = <1>;
> + };
> +
> + obsclk {
> + #clock-cells = <0>;
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-ti-pll-v1-1-f6f9ba8c9b5e@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: ti,dm816-fapll-clock: Convert to DT schema
From: sashiko-bot @ 2026-07-17 18:23 UTC (permalink / raw)
To: Bhargav Joshi; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260717-ti-fapll-clock-v1-1-1b684cb2543b@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Operator precedence bug causes an undersized array allocation leading to an out-of-bounds write
- [High] Incorrect array bounds tracking breaks clock lookup for sparse clock configurations
--
--- Patch [1]: [PATCH] dt-bindings: clock: ti,dm816-fapll-clock: Convert to DT schema ---
commit 87daba9f6927df76d909d0fe50168fefb82110f5
Author: Bhargav Joshi <j.bhargav.u@gmail.com>
dt-bindings: clock: ti,dm816-fapll-clock: Convert to DT schema
Convert the Texas Instruments DM816 FAPLL clock binding from plain text
to YAML DT schema. The schema now strictly enforces #clock-cells = <1>,
and adds clock-indices and clock-output-names as required properties.
> diff --git a/Documentation/devicetree/bindings/clock/ti/ti,dm816-fapll-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,dm816-fapll-clock.yaml
> new file mode 100644
> index 0000000000000..9b6b824faa305
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/ti,dm816-fapll-clock.yaml
[ ... ]
> + clock-indices:
> + description:
> + Maps child synthesizers to physical indices 1-7. Index 0 is physically
> + reserved for the Master PLL.
> + minItems: 1
> + maxItems: 7
> + items:
> + minimum: 1
> + maximum: 7
[Severity: Critical]
This is a pre-existing issue, but by officially documenting 7 as the maximum
index, this binding exposes an out-of-bounds write in the driver.
In the driver code:
drivers/clk/ti/fapll.c:ti_fapll_setup() {
...
fd->outputs.clks = kzalloc(sizeof(struct clk *) *
MAX_FAPLL_OUTPUTS + 1,
GFP_KERNEL);
...
}
Due to C operator precedence, this evaluates to (8 * 7) + 1 = 57 bytes on
64-bit architectures, rather than the intended 8 * (7 + 1) = 64 bytes.
If a device tree uses a clock index of 7 (the maximum allowed, as demonstrated
in the DT bindings example), the driver writes to fd->outputs.clks[7]. This
pointer write covers bytes 56 through 63, overflowing the 57-byte allocation by
7 bytes, which can cause memory corruption and a KASAN splat.
Could we fix the operator precedence in the driver by adding parentheses around
MAX_FAPLL_OUTPUTS + 1?
[Severity: High]
This isn't a bug introduced by this patch, but there's a pre-existing issue in
how the driver handles the sparse indices allowed by this binding.
drivers/clk/ti/fapll.c:ti_fapll_setup() {
...
fd->outputs.clks[output_instance] = synth_clk;
fd->outputs.clk_num++;
...
}
If the device tree specifies sparse indices (e.g., <1> and <5>), clk_num is
incremented to 3 instead of tracking the maximum index + 1.
When of_clk_src_onecell_get() performs a lookup for index 5, it checks
if (idx >= clk_data->clk_num) (i.e., 5 >= 3), which incorrectly rejects the
valid lookup and returns -EINVAL.
Can the driver be updated to set clk_num to the maximum index + 1 instead of
just counting the number of registered clocks?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-ti-fapll-clock-v1-1-1b684cb2543b@gmail.com?part=1
^ permalink raw reply
* [PATCH] dt-bindings: clock: ti,da850-pll: Convert to DT schema
From: Bhargav Joshi @ 2026-07-17 18:21 UTC (permalink / raw)
To: David Lechner, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-clk, devicetree, linux-kernel, goledhruva, m-chawdhry,
daniel.baluta, simona.toaca, j.bhargav.u
Convert TI da850-pll binding from legacy text to dt schema.
No functional change is introduced during conversion.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
.../devicetree/bindings/clock/ti/davinci/pll.txt | 96 -----------
.../bindings/clock/ti/davinci/ti,da850-pll.yaml | 177 +++++++++++++++++++++
2 files changed, 177 insertions(+), 96 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt b/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
deleted file mode 100644
index c9894538315b..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
+++ /dev/null
@@ -1,96 +0,0 @@
-Binding for TI DaVinci PLL Controllers
-
-The PLL provides clocks to most of the components on the SoC. In addition
-to the PLL itself, this controller also contains bypasses, gates, dividers,
-an multiplexers for various clock signals.
-
-Required properties:
-- compatible: shall be one of:
- - "ti,da850-pll0" for PLL0 on DA850/OMAP-L138/AM18XX
- - "ti,da850-pll1" for PLL1 on DA850/OMAP-L138/AM18XX
-- reg: physical base address and size of the controller's register area.
-- clocks: phandles corresponding to the clock names
-- clock-names: names of the clock sources - depends on compatible string
- - for "ti,da850-pll0", shall be "clksrc", "extclksrc"
- - for "ti,da850-pll1", shall be "clksrc"
-
-Optional properties:
-- ti,clkmode-square-wave: Indicates that the board is supplying a square
- wave input on the OSCIN pin instead of using a crystal oscillator.
- This property is only valid when compatible = "ti,da850-pll0".
-
-
-Optional child nodes:
-
-pllout
- Describes the main PLL clock output (before POSTDIV). The node name must
- be "pllout".
-
- Required properties:
- - #clock-cells: shall be 0
-
-sysclk
- Describes the PLLDIVn divider clocks that provide the SYSCLKn clock
- domains. The node name must be "sysclk". Consumers of this node should
- use "n" in "SYSCLKn" as the index parameter for the clock cell.
-
- Required properties:
- - #clock-cells: shall be 1
-
-auxclk
- Describes the AUXCLK output of the PLL. The node name must be "auxclk".
- This child node is only valid when compatible = "ti,da850-pll0".
-
- Required properties:
- - #clock-cells: shall be 0
-
-obsclk
- Describes the OBSCLK output of the PLL. The node name must be "obsclk".
-
- Required properties:
- - #clock-cells: shall be 0
-
-
-Examples:
-
- pll0: clock-controller@11000 {
- compatible = "ti,da850-pll0";
- reg = <0x11000 0x1000>;
- clocks = <&ref_clk>, <&pll1_sysclk 3>;
- clock-names = "clksrc", "extclksrc";
- ti,clkmode-square-wave;
-
- pll0_pllout: pllout {
- #clock-cells = <0>;
- };
-
- pll0_sysclk: sysclk {
- #clock-cells = <1>;
- };
-
- pll0_auxclk: auxclk {
- #clock-cells = <0>;
- };
-
- pll0_obsclk: obsclk {
- #clock-cells = <0>;
- };
- };
-
- pll1: clock-controller@21a000 {
- compatible = "ti,da850-pll1";
- reg = <0x21a000 0x1000>;
- clocks = <&ref_clk>;
- clock-names = "clksrc";
-
- pll0_sysclk: sysclk {
- #clock-cells = <1>;
- };
-
- pll0_obsclk: obsclk {
- #clock-cells = <0>;
- };
- };
-
-Also see:
-- Documentation/devicetree/bindings/clock/clock-bindings.txt
diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml b/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml
new file mode 100644
index 000000000000..5e4109567b75
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/davinci/ti,da850-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DaVinci PLL Controllers
+
+maintainers:
+ - David Lechner <david@lechnology.com>
+ - Bhargav Joshi <j.bhargav.u@gmail.com>
+
+description:
+ The PLL provides clocks to most of the components on the SoC. In addition to
+ the PLL itself, this controller also contains bypasses, gates, dividers, an
+ multiplexers for various clock signals.
+
+properties:
+ compatible:
+ enum:
+ - ti,da850-pll0
+ - ti,da850-pll1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ ti,clkmode-square-wave:
+ type: boolean
+ description:
+ Indicates that the board is supplying a square wave input on the OSCIN
+ pin instead of using a crystal oscillator.
+
+ pllout:
+ type: object
+ description:
+ Main PLL clock output before POSTDIV.
+
+ properties:
+ '#clock-cells':
+ const: 0
+
+ required:
+ - '#clock-cells'
+
+ additionalProperties: false
+
+ sysclk:
+ type: object
+ description:
+ PLLDIVn divider clocks that provide the SYSCLKn clock domains. Consumers
+ of this node should use "n" in "SYSCLKn" as the index parameter for the
+ clock cell.
+
+ properties:
+ '#clock-cells':
+ const: 1
+
+ required:
+ - '#clock-cells'
+
+ additionalProperties: false
+
+ auxclk:
+ type: object
+ description:
+ AUXCLK output of the PLL
+
+ properties:
+ '#clock-cells':
+ const: 0
+
+ required:
+ - '#clock-cells'
+
+ additionalProperties: false
+
+ obsclk:
+ type: object
+ description:
+ the OBSCLK output of the PLL.
+
+ properties:
+ '#clock-cells':
+ const: 0
+
+ required:
+ - '#clock-cells'
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: ti,da850-pll0
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Primary reference clock input
+ - description: External clock source
+ clock-names:
+ items:
+ - const: clksrc
+ - const: extclksrc
+
+ - if:
+ properties:
+ compatible:
+ const: ti,da850-pll1
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: clksrc
+ ti,clkmode-square-wave: false
+ auxclk: false
+
+examples:
+ - |
+ clock-controller@11000 {
+ compatible = "ti,da850-pll0";
+ reg = <0x11000 0x1000>;
+ clocks = <&ref_clk>, <&pll1_sysclk 3>;
+ clock-names = "clksrc", "extclksrc";
+ ti,clkmode-square-wave;
+
+ pllout {
+ #clock-cells = <0>;
+ };
+
+ sysclk {
+ #clock-cells = <1>;
+ };
+
+ auxclk {
+ #clock-cells = <0>;
+ };
+
+ obsclk {
+ #clock-cells = <0>;
+ };
+ };
+
+ - |
+ clock-controller@21a000 {
+ compatible = "ti,da850-pll1";
+ reg = <0x21a000 0x1000>;
+ clocks = <&ref_clk>;
+ clock-names = "clksrc";
+
+ sysclk {
+ #clock-cells = <1>;
+ };
+
+ obsclk {
+ #clock-cells = <0>;
+ };
+ };
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260630-ti-pll-94f8eb9918c8
Best regards,
--
Bhargav
^ permalink raw reply related
* Re: [PATCH] regulator: dt-bindigs: ti,pbias-omap: Convert to DT schema
From: sashiko-bot @ 2026-07-17 18:15 UTC (permalink / raw)
To: Bhargav Joshi; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260717-ti-pbias-omap-v1-1-527848131801@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Top-level `$ref: regulator.yaml#` incorrectly applies standard regulator constraints to the parent container node.
- [Medium] The schema incorrectly uses `oneOf` to restrict the parent node to exactly one regulator subnode, which prevents valid configurations like OMAP3 from defining both MMC and SIM regulators.
--
--- Patch [1]: [PATCH] regulator: dt-bindigs: ti,pbias-omap: Convert to DT schema ---
commit e24c9bc6e58ceda1b221ec8e8ce86f428408d847
Author: Bhargav Joshi <j.bhargav.u@gmail.com>
regulator: dt-bindigs: ti,pbias-omap: Convert to DT schema
Convert Texas Instruments PBIAS internal regulator from text to DT
schema. No Functional changes are introduced.
> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-omap.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-omap.yaml
> new file mode 100644
> index 0000000000000..61a4dc87c48c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-omap.yaml
[ ... ]
> +required:
> + - compatible
> + - reg
> + - syscon
> +
> +oneOf:
> + - required:
> + - pbias_mmc_omap2430
> + - required:
> + - pbias_sim_omap3
> + - required:
> + - pbias_mmc_omap4
> + - required:
> + - pbias_mmc_omap5
[Severity: Medium]
Will this reject valid configurations that define more than one child
regulator?
The JSON schema oneOf keyword requires exactly one condition to match. Since
OMAP3 SoCs can have both MMC and SIM PBIAS regulators, and the driver
supports them concurrently, having both defined would cause oneOf to fail.
Should this use anyOf instead?
> +
> +allOf:
> + - $ref: regulator.yaml#
[Severity: Medium]
Does applying the standard regulator schema to the top-level parent node
neutralize validation?
This allows a device tree author to mistakenly place properties like
regulator-min-microvolt directly on the parent node instead of the
subnodes. Such properties would be ignored by the kernel but silently pass
the schema check.
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ti,pbias-omap2
> + then:
> + required:
> + - pbias_mmc_omap2430
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,pbias-omap3
> + then:
> + oneOf:
> + - required:
> + - pbias_mmc_omap2430
> + - required:
> + - pbias_sim_omap3
[Severity: Medium]
Similarly, does this restrict OMAP3 to exactly one regulator subnode?
This would prevent valid hardware configurations from using both the MMC and
SIM regulators simultaneously. Should this also use anyOf?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-ti-pbias-omap-v1-1-527848131801@gmail.com?part=1
^ permalink raw reply
* [PATCH] dt-bindings: clock: ti,dm816-fapll-clock: Convert to DT schema
From: Bhargav Joshi @ 2026-07-17 18:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tony Lindgren, Tero Kristo
Cc: linux-clk, devicetree, linux-kernel, goledhruva, m-chawdhry,
daniel.baluta, simona.toaca, j.bhargav.u
Convert the Texas Instruments DM816 FAPLL clock binding from plain text
to YAML DT schema.
The text documented #clock-cells to be set as 0, while the example and
existing dt and driver require it to be 1. The schema now strictly
enforces #clock-cells = <1>.
Properties clock-indices and clock-output-names are documented in the
binding and added as required as driver strictly requires it and existing
dt already use this property.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
.../devicetree/bindings/clock/ti/fapll.txt | 31 ----------
.../bindings/clock/ti/ti,dm816-fapll-clock.yaml | 72 ++++++++++++++++++++++
2 files changed, 72 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/ti/fapll.txt b/Documentation/devicetree/bindings/clock/ti/fapll.txt
deleted file mode 100644
index 88986ef39ddd..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/fapll.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Binding for Texas Instruments FAPLL clock.
-
-This binding uses the common clock binding[1]. It assumes a
-register-mapped FAPLL with usually two selectable input clocks
-(reference clock and bypass clock), and one or more child
-syntesizers.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "ti,dm816-fapll-clock"
-- #clock-cells : from common clock binding; shall be set to 0.
-- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
-- reg : address and length of the register set for controlling the FAPLL.
-
-Examples:
- main_fapll: main_fapll {
- #clock-cells = <1>;
- compatible = "ti,dm816-fapll-clock";
- reg = <0x400 0x40>;
- clocks = <&sys_clkin_ck &sys_clkin_ck>;
- clock-indices = <1>, <2>, <3>, <4>, <5>,
- <6>, <7>;
- clock-output-names = "main_pll_clk1",
- "main_pll_clk2",
- "main_pll_clk3",
- "main_pll_clk4",
- "main_pll_clk5",
- "main_pll_clk6",
- "main_pll_clk7";
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,dm816-fapll-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,dm816-fapll-clock.yaml
new file mode 100644
index 000000000000..9b6b824faa30
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,dm816-fapll-clock.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,dm816-fapll-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments FAPLL clock
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+ - Tero Kristo <kristo@kernel.org>
+
+description:
+ This binding uses the common clock binding. It assumes a register-mapped
+ FAPLL with usually two selectable input clocks (reference clock and bypass
+ clock), and one or more child synthesizers.
+
+properties:
+ compatible:
+ const: ti,dm816-fapll-clock
+
+ "#clock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: phandle for parent clock clk-ref
+ - description: phandle for parent clock clk-bypass
+
+ clock-indices:
+ description:
+ Maps child synthesizers to physical indices 1-7. Index 0 is physically
+ reserved for the Master PLL.
+ minItems: 1
+ maxItems: 7
+ items:
+ minimum: 1
+ maximum: 7
+
+ clock-output-names:
+ description:
+ Names of the child synthesizer outputs. The length of this array must
+ match clock-indices.
+ minItems: 1
+ maxItems: 7
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+ - clock-indices
+ - clock-output-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@400 {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x400 0x40>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>, <5>, <6>, <7>;
+ clock-output-names = "main_pll_clk1", "main_pll_clk2", "main_pll_clk3",
+ "main_pll_clk4", "main_pll_clk5", "main_pll_clk6",
+ "main_pll_clk7";
+
+ };
---
base-commit: 0716f9b9338a86dd27796e00ed0fd560c653323a
change-id: 20260629-ti-fapll-clock-57a02c264e60
Best regards,
--
Bhargav
^ permalink raw reply related
* Re: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support
From: Andy Shevchenko @ 2026-07-17 18:11 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君]
Cc: Michael Walle, Michael.Hennerich@analog.com, afaerber@suse.com,
andy@kernel.org, brgl@kernel.org, conor+dt@kernel.org,
CY_Huang[黃鉦晏], devicetree@vger.kernel.org,
dlechner@baylibre.com, James Tai [戴志峰],
jic23@kernel.org, krzk+dt@kernel.org, lars@metafoo.de,
linus.walleij@linaro.org, linusw@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-realtek-soc@lists.infradead.org,
mathieu.dubois-briand@bootlin.com, nuno.sa@analog.com,
robh@kernel.org, Stanley Chang[昌育德],
TY_Chang[張子逸], wbg@kernel.org
In-Reply-To: <82f3f73764ac4553a8e2743bbebd90e8@realtek.com>
On Fri, Jul 17, 2026 at 03:38:35PM +0000, Yu-Chun Lin [林祐君] wrote:
> > On Thu, Jul 16, 2026 at 12:55:37PM +0200, Michael Walle wrote:
> > > On Thu Jul 16, 2026 at 11:40 AM CEST, Andy Shevchenko wrote:
> > > > On Thu, Jul 16, 2026 at 11:08:55AM +0200, Michael Walle wrote:
> > > >> On Thu Jul 16, 2026 at 10:27 AM CEST, Andy Shevchenko wrote:
> > > >> > On Thu, Jul 16, 2026 at 02:26:14PM +0800, Yu-Chun Lin wrote:
...
> > > >> > From the above list I tend to the approach 2, but this might
> > > >> > require to have GPIO regmap level of locking. I'm a bit lost in
> > > >> > the context, though. I assume we need a fresh start, id est issue
> > > >> > a v6 with approach 2 or 3 in place and summarize the choices in
> > > >> > the cover letter, so we can understand what has been considered.
> > > >>
> > > >> I don't really like approach 3. You'd need to check if the regs of
> > > >> both xlate calls are the same. With the sample code above, you
> > > >> silently drop the first xlate'd reg.
> > > >
> > > > If I rank the proposals, the worst is #1, the best is #2.
> > > >
> > > >> And honestly, it really seems like a one-off. What controllers, are
> > > >> there that need a write enable bit. The real problem seems to be
> > > >> the assumption that we operate on just one bit. IOW we either set
> > > >> mask or don't set mask in gpio_regmap_set().
> > > >
> > > > Yes, we should KISS.
> > >
> > > But IMHO #2 and #3 are not KISS. Approach 2 is just a way of adding
> > > some kind of pre op to a gpio set. Just tying it to a write enable
> > > feature. That kinda bothers me. It might also be useful for other
> > > things, too. So don't tie it to just write enable. And who is doing a
> > > write disable if it's not self clearing for example. Probably Some
> > > kind of post op :)
> > >
> > > Approach 3 is a way to change the value of the written value - in a
> > > restricted way, as is is just doing a OR with both values.
> > >
> > > Also approach 2 might not even work if the hardware requires the write
> > > enable bit set in the *same* write as the gpio set bit. Thus, we might
> > > need both anyway in the future.
> > >
> > > >> For a more generic solution, we should be able to control the
> > > >> written value. We could add another .value_xlate().
> > > >
> > > > Maybe not now?
> > >
> > > But if not now, then when? I wouldn't add the write enable feature and
> > > later a more generic solution which also covers the write enable
> > > feature.
> >
> > Taking into account how it's done in HW, I think the whole approach can be
> > folded to just a boolean flag (or a simply bit shift) in the config.
> > Wouldn't it work?
>
> To respect Michael's perspective on keeping WREN-specific code out of the
> framework, I think adding a value_xlate callback in the config is a cleaner
> approach. It allows us to wrap this hardware quirk within the callback and let
> the consumer driver handle it entirely.
>
> To ensure it is truly generic, I will not introduce any WREN-specific operation
> flags. Instead, value_xlate will reuse the gpio_regmap_operation enum
> (e.g., GPIO_REGMAP_OP_SET, GPIO_REGMAP_OP_SET_DIR).
OK! But don't forget add a good documentation that users will understand
the logic behind it.
> > > > As per IPs, Synopsys IPs (not exactly GPIO) likes to have that kind
> > > > of "protection". So, from HW perspective it's kinda pattern, and it
> > > > might be possible to see more IPs (including GPIO) that follow it in
> > > > some cases.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] regulator: dt-bindigs: ti,pbias-omap: Convert to DT schema
From: Bhargav Joshi @ 2026-07-17 18:06 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren
Cc: linux-kernel, devicetree, goledhruva, m-chawdhry, daniel.baluta,
simona.toaca, j.bhargav.u
Convert Texas Instruments PBIAS internal regulator from text to DT
schema. No Functional changes are introduced.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
.../bindings/regulator/pbias-regulator.txt | 32 -----
.../bindings/regulator/ti,pbias-omap.yaml | 152 +++++++++++++++++++++
2 files changed, 152 insertions(+), 32 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
deleted file mode 100644
index acbcb452a69a..000000000000
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
-
-Required properties:
-- compatible:
- - should be "ti,pbias-dra7" for DRA7
- - should be "ti,pbias-omap2" for OMAP2
- - should be "ti,pbias-omap3" for OMAP3
- - should be "ti,pbias-omap4" for OMAP4
- - should be "ti,pbias-omap5" for OMAP5
- - "ti,pbias-omap" is deprecated
-- reg: pbias register offset from syscon base and size of pbias register.
-- syscon : phandle of the system control module
-- regulator-name : should be
- pbias_mmc_omap2430 for OMAP2430, OMAP3 SoCs
- pbias_sim_omap3 for OMAP3 SoCs
- pbias_mmc_omap4 for OMAP4 SoCs
- pbias_mmc_omap5 for OMAP5 and DRA7 SoC
-
-Optional properties:
-- Any optional property defined in bindings/regulator/regulator.txt
-
-Example:
-
- pbias_regulator: pbias_regulator {
- compatible = "ti,pbias-omap";
- reg = <0 0x4>;
- syscon = <&omap5_padconf_global>;
- pbias_mmc_reg: pbias_mmc_omap5 {
- regulator-name = "pbias_mmc_omap5";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- };
diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-omap.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-omap.yaml
new file mode 100644
index 000000000000..61a4dc87c48c
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti,pbias-omap.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/ti,pbias-omap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PBIAS internal regulator.
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ti,pbias-dra7
+ - ti,pbias-omap2
+ - ti,pbias-omap3
+ - ti,pbias-omap4
+ - ti,pbias-omap5
+ - const: ti,pbias-omap
+
+ reg:
+ maxItems: 1
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of the system control module
+
+ pbias_mmc_omap2430:
+ type: object
+ $ref: regulator.yaml#
+
+ properties:
+ regulator-name:
+ const: pbias_mmc_omap2430
+
+ required:
+ - regulator-name
+
+ unevaluatedProperties: false
+
+ pbias_sim_omap3:
+ type: object
+ $ref: regulator.yaml#
+
+ properties:
+ regulator-name:
+ const: pbias_sim_omap3
+
+ required:
+ - regulator-name
+
+ unevaluatedProperties: false
+
+ pbias_mmc_omap4:
+ type: object
+ $ref: regulator.yaml#
+
+ properties:
+ regulator-name:
+ const: pbias_mmc_omap4
+
+ required:
+ - regulator-name
+
+ unevaluatedProperties: false
+
+ pbias_mmc_omap5:
+ type: object
+ $ref: regulator.yaml#
+
+ properties:
+ regulator-name:
+ const: pbias_mmc_omap5
+
+ required:
+ - regulator-name
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - syscon
+
+oneOf:
+ - required:
+ - pbias_mmc_omap2430
+ - required:
+ - pbias_sim_omap3
+ - required:
+ - pbias_mmc_omap4
+ - required:
+ - pbias_mmc_omap5
+
+allOf:
+ - $ref: regulator.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pbias-omap2
+ then:
+ required:
+ - pbias_mmc_omap2430
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,pbias-omap3
+ then:
+ oneOf:
+ - required:
+ - pbias_mmc_omap2430
+ - required:
+ - pbias_sim_omap3
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,pbias-omap4
+ then:
+ required:
+ - pbias_mmc_omap4
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pbias-omap5
+ - ti,pbias-dra7
+ then:
+ required:
+ - pbias_mmc_omap5
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pbias_regulator: pbias_regulator@0 {
+ compatible = "ti,pbias-omap5", "ti,pbias-omap";
+ reg = <0 0x4>;
+ syscon = <&omap5_padconf_global>;
+ pbias_mmc_reg: pbias_mmc_omap5 {
+ regulator-name = "pbias_mmc_omap5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ };
+ };
---
base-commit: 1e9cdc2ea15adf4a821eefedabf6c0c8cf0b6a55
change-id: 20260704-ti-pbias-omap-508cc9576c91
Best regards,
--
Bhargav
^ permalink raw reply related
* [PATCH v2 2/2] mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability
From: Kamal Dasu @ 2026-07-17 18:05 UTC (permalink / raw)
To: Ulf Hansson
Cc: Kamal Dasu, Florian Fainelli, Wolfram Sang, Oleksij Rempel,
Avri Altman, Pedro Demarchi Gomes, Erick Shepherd, Adrian Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
devicetree, linux-kernel
In-Reply-To: <20260717180536.1757204-1-kamal.dasu@broadcom.com>
Some (e)MMC devices take longer to exit the SLEEP (CMD5) state than
their advertised S_A_TIMEOUT allows for. On platforms where a boot
ROM sends CMD0 and reads boot code from the card immediately on
resume, a card still asleep at that point causes the ROM to treat
it as fatal and reset.
Add MMC_CAP2_NO_SLEEP_CMD, settable via the new "no-mmc-sleep" DT
property, so affected hosts can tell mmc_card_can_sleep() to never
put the card to sleep, regardless of ext_csd revision. This is a
host-level capability rather than a card quirk so it also covers
cards whose bug can't be identified by CID/ext_csd matching alone,
and it is resolved before the card even exists, avoiding any
ordering dependency on when a card-quirk table would be applied.
Reported-by: Florian Fainelli <florian.fainelli@broadcom.com>
Closes: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli@broadcom.com/
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
---
Changes in v2:
- Replaced the card-level MMC_QUIRK_BROKEN_SLEEP quirk (keyed off
CID) with a host capability, MMC_CAP2_NO_SLEEP_CMD, set from the
new "no-mmc-sleep" DT property, per Ulf's suggestion that this
generalize beyond one device's CID.
- Resolving the capability in mmc_of_parse(), before any card
exists, also addresses Oleksij's concern that a quirk registered
in mmc_blk_fixups[] (applied at mmc_block probe time) could lose
a race against an earlier SLEEP/poweroff on an under-voltage
path.
- Added Reported-by/Closes tags crediting Florian for the original
bug report.
drivers/mmc/core/host.c | 2 ++
drivers/mmc/core/mmc.c | 3 +++
include/linux/mmc/host.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index b7ce3137d452..3bc19645ea96 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -400,6 +400,8 @@ int mmc_of_parse(struct mmc_host *host)
if (device_property_read_bool(dev, "no-mmc-hs400"))
host->caps2 &= ~(MMC_CAP2_HS400_1_8V | MMC_CAP2_HS400_1_2V |
MMC_CAP2_HS400_ES);
+ if (device_property_read_bool(dev, "no-mmc-sleep"))
+ host->caps2 |= MMC_CAP2_NO_SLEEP_CMD;
/* Must be after "non-removable" check */
if (device_property_read_u32(dev, "fixed-emmc-driver-type", &drv_type) == 0) {
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 05444ecf3909..5e80fa5c1a28 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1972,6 +1972,9 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
static bool mmc_card_can_sleep(struct mmc_card *card)
{
+ if (card->host->caps2 & MMC_CAP2_NO_SLEEP_CMD)
+ return false;
+
return card->ext_csd.rev >= 3;
}
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba84f02c2a10..0447a8efed50 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -463,6 +463,7 @@ struct mmc_host {
#define MMC_CAP2_CRYPTO 0
#endif
#define MMC_CAP2_ALT_GPT_TEGRA (1 << 28) /* Host with eMMC that has GPT entry at a non-standard location */
+#define MMC_CAP2_NO_SLEEP_CMD (1 << 29) /* Card can't reliably wake from CMD5 SLEEP */
bool uhs2_sd_tran; /* UHS-II flag for SD_TRAN state */
bool uhs2_app_cmd; /* UHS-II flag for APP command */
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: mmc: Document no-mmc-sleep property
From: Kamal Dasu @ 2026-07-17 18:05 UTC (permalink / raw)
To: Ulf Hansson
Cc: Kamal Dasu, Florian Fainelli, Wolfram Sang, Oleksij Rempel,
Avri Altman, Pedro Demarchi Gomes, Erick Shepherd, Adrian Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
devicetree, linux-kernel
In-Reply-To: <20260717180536.1757204-1-kamal.dasu@broadcom.com>
Some (e)MMC devices cannot reliably resume from the SLEEP (CMD5)
state within their advertised S_A_TIMEOUT, which can be problematic
on systems that resume from Suspend-to-DRAM by first pulling boot
code from eMMC using hard wired logic that is not field updatable.
Add a no-mmc-sleep flag property so affected boards can tell the
mmc core to never put the card to sleep.
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
---
Changes in v2:
- New patch. v1 used a card-level MMC_QUIRK_BROKEN_SLEEP quirk
instead of a DT property; this documents the DT property backing
the host capability added in patch 2, per Ulf's suggestion.
- Reworded the rationale in the commit message and the binding
description per Florian's review.
.../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 3d7195e9461c..11df0524530c 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -232,6 +232,14 @@ properties:
description:
All eMMC HS400 modes are not supported.
+ no-mmc-sleep:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The attached (e)MMC card cannot reliably resume from the SLEEP
+ (CMD5) state within its advertised S_A_TIMEOUT, so the
+ controller must not put it to sleep during suspend or power
+ off.
+
dsr:
description:
Value the card Driver Stage Register (DSR) should be programmed
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] mmc: core: Add a host capability to skip SLEEP for cards with a broken resume
From: Kamal Dasu @ 2026-07-17 18:05 UTC (permalink / raw)
To: Ulf Hansson
Cc: Kamal Dasu, Florian Fainelli, Wolfram Sang, Oleksij Rempel,
Avri Altman, Pedro Demarchi Gomes, Erick Shepherd, Adrian Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
devicetree, linux-kernel
This is v2 of Florian's original patch:
Link: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli@broadcom.com/
Background: the Kioxia 016G01 eMMC takes ~10ms to exit SLEEP (CMD5)
instead of the ~1ms it advertises via S_A_TIMEOUT, which can be
problematic on systems that resume from Suspend-to-DRAM by first
pulling boot code from eMMC using hard wired logic that is not field
updatable -- if the card is still asleep when that logic reads it, it
resets the board. The device stays powered throughout suspend-to-
DRAM (no software-controlled VCC/VCCQ regulator toggling on this
path), and the CMD0-before-resume sequence follows the JEDEC boot
spec, so this isn't something the kernel's resume ordering can fix
on its own.
v1 addressed this with a card-level MMC_QUIRK_BROKEN_SLEEP quirk
keyed off the device CID. Ulf pointed out that a device-specific
quirk doesn't generalize well and suggested a host capability bit
instead, settable from DT (or derived from a compatible string),
mirroring the existing no-sdio/no-sd/no-mmc properties. Oleksij
separately noted that quirks registered in mmc_blk_fixups[] are only
applied once the mmc_block driver probes, which is too late to avoid
a race against an earlier SLEEP/poweroff triggered on an under-
voltage path -- a host cap resolved in mmc_of_parse(), before any
card exists, sidesteps that ordering problem entirely.
This series implements that direction:
- Patch 1 documents a new "no-mmc-sleep" DT flag property.
- Patch 2 adds MMC_CAP2_NO_SLEEP_CMD, parses the DT property in
mmc_of_parse(), and has mmc_card_can_sleep() honor it.
The actual board DT change (adding "no-mmc-sleep;" to the affected
brcmstb eMMC controller node) will follow separately once this lands,
since that DT lives outside of mainline.
Changes in v2:
- Dropped the card-quirk/CID-match approach entirely in favor of a
host capability bit, per Ulf's suggestion.
- Added a DT property ("no-mmc-sleep") to set that capability,
following the no-sdio/no-sd/no-mmc precedent, per Ulf.
- This also resolves Oleksij's concern about mmc_blk_fixups[]
being applied too late to close the race on an early
SLEEP/poweroff path, since the host cap is resolved in
mmc_of_parse() before a card exists.
- Reworded the rationale in patch 1's commit message and binding
description per Florian's review.
- Added a Reported-by/Closes tag crediting Florian for the
original bug report.
Kamal Dasu (2):
dt-bindings: mmc: Document no-mmc-sleep property
mmc: core: Add MMC_CAP2_NO_SLEEP_CMD host capability
.../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
drivers/mmc/core/host.c | 2 ++
drivers/mmc/core/mmc.c | 3 +++
include/linux/mmc/host.h | 1 +
4 files changed, 14 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] dt-bindings: sram: Document qcom,shikra-imem compatible
From: Mukesh Ojha @ 2026-07-17 18:02 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Komal Bajaj,
devicetree, linux-kernel
In-Reply-To: <178425854616.1084804.7965648558976512392.b4-ty@kernel.org>
On Thu, Jul 16, 2026 at 10:23:26PM -0500, Bjorn Andersson wrote:
>
> On Thu, 30 Apr 2026 18:08:04 +0530, Komal Bajaj wrote:
> > Add compatible for Shikra SoC IMEM.
> >
> >
>
> Applied, thanks!
>
> [1/1] dt-bindings: sram: Document qcom,shikra-imem compatible
> commit: 26ead60b1a2722627759dc8c279ed336826bb5e1
>
>
> Please make sure to Cc linux-arm-msm@vger.kernel.org, so changes like this
> shows up in my inbox.
There is a very high chance it can get missed. Is there a better way, like
adding sram.yaml to the ARM/QUALCOMM mailing list in the MAINTAINERS file?
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v4 2/2] iio: adc: add MAX40080 current-sense amplifier driver
From: Andy Shevchenko @ 2026-07-17 17:58 UTC (permalink / raw)
To: Stefan Popa; +Cc: linux-iio, jic23, nuno.sa, devicetree, Ciprian Hegbeli
In-Reply-To: <20260717123852.1140893-3-stefan.popa@analog.com>
On Fri, Jul 17, 2026 at 03:38:49PM +0300, Stefan Popa wrote:
> The MAX40080 is a bidirectional current-sense amplifier with an
> integrated 12-bit ADC and an I2C/SMBus interface. It measures the
> voltage across an external shunt resistor and the input bus voltage,
> storing the results in an internal FIFO.
>
> No existing IIO driver covers this device or a register-compatible part.
> The closest relatives target different silicon with incompatible register
> maps and feature sets: max9611 is a unidirectional high-side sensor with a
> die-temperature channel and MUX-selected gain and no FIFO/PEC, while
> max34408 is an 8-bit multi-channel current monitor. The MAX40080 has a
> device-specific register map with bidirectional 13-bit current, a 64-entry
> FIFO, PEC, a single-measurement mode triggered by an SMBus Quick Command,
> and two selectable input ranges, so it warrants its own driver.
>
> Add a direct-mode IIO driver exposing the current and voltage channels
> with raw and scale attributes, a configurable oversampling (digital
> averaging) ratio, and PEC-protected register access. The two selectable
> current-sense ranges are exposed through scale/scale_available; the
> current scale is derived from the shunt-resistor-micro-ohms device-tree
> property.
...
> +struct max40080_state {
> + struct i2c_client *client;
> + /* Serializes read-modify-write access to the CFG register. */
> + struct mutex lock;
> + u32 shunt_resistor_uOhm;
> + /*
> + * Cached configuration, also used to restore the device on resume after
> + * a suspend that may have cut its power: the selected RANGE index and
> + * the oversampling ratio.
> + */
> + unsigned int range;
> + int oversampling_ratio;
> + /*
> + * Precomputed current scale (mA per code) for each RANGE setting, as
> + * {integer, nano} pairs for IIO_VAL_INT_PLUS_NANO. The range is
> + * selected by writing the corresponding scale.
> + */
> + int current_scale[ARRAY_SIZE(max40080_csa_gain)][2];
> + /* DMA-safe buffer for i2c_smbus_read_i2c_block_data(). */
> + u8 buf[4] ____cacheline_aligned;
Why don't you use the specific IIO macro for this?
Do you have internal reviews for this patch series?
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: reset: Add reset controller constants for mt8167
From: sashiko-bot @ 2026-07-17 17:50 UTC (permalink / raw)
To: Luca Leonardo Scorcia; +Cc: devicetree, linux-watchdog, robh, conor+dt
In-Reply-To: <20260717163959.714561-5-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect reset ID mapping for MMSYS SW1 reset constants.
--
--- Patch [4]: [PATCH v2 4/7] dt-bindings: reset: Add reset controller constants for mt8167 ---
commit 3e501b19a4f1986647da6f341a25af00a37a8d1d
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
dt-bindings: reset: Add reset controller constants for mt8167
This commit adds identifying bits for watchdog and mmsys resets on
the mt8167 platform.
> diff --git a/include/dt-bindings/reset/mediatek,mt8167-resets.h b/include/dt-bindings/reset/mediatek,mt8167-resets.h
> new file mode 100644
> index 0000000000000..85d2d0e99c689
> --- /dev/null
> +++ b/include/dt-bindings/reset/mediatek,mt8167-resets.h
[ ... ]
> +#define MT8167_MMSYS_SW0_RST_B_DPI0 23
> +#define MT8167_MMSYS_SW0_RST_B_MIPI_TX_CONFIG 24
> +#define MT8167_MMSYS_SW1_RST_B_LVDS_ENCODER 25
> +#define MT8167_MMSYS_SW1_RST_B_DPI1 26
> +#define MT8167_MMSYS_SW1_RST_B_HDMI 27
[Severity: High]
Will these reset IDs correctly map to the SW1 register?
In drivers/soc/mediatek/mtk-mmsys.c, mtk_mmsys_reset_update() dynamically
calculates the register offset by dividing the ID by 32.
Since MT8167 does not provide an rst_tb mapping array, the raw ID is used for
this division. For IDs 25, 26, and 27, this calculates to an offset of 0,
which targets the SW0_RST_B register instead of SW1_RST_B.
Should these IDs be greater than or equal to 32 if they belong to SW1, or is
the SW1 naming a typo for bits that actually reside in the SW0 register?
> +
> +#endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8167 */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717163959.714561-1-l.scorcia@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 2/2] iio: accel: mma8452: Allow open drain interrupt pin configuration
From: Andy Shevchenko @ 2026-07-17 17:47 UTC (permalink / raw)
To: Esben Haabendal
Cc: Jonathan Cameron, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Martin Kepplinger,
Sean Nyekjaer, David Lechner, Nuno Sá, Andy Shevchenko,
Martin Kepplinger, linux-iio, devicetree, linux-kernel
In-Reply-To: <877bmtsu1h.fsf@geanix.com>
On Fri, Jul 17, 2026 at 02:02:50PM +0200, Esben Haabendal wrote:
> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> > On Thu, Jul 16, 2026 at 04:51:34PM +0000, Esben Haabendal wrote:
> >> On Wednesday, 15 July 2026 at 16:56, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >> > On Wed, Jul 15, 2026 at 04:25:20PM +0200, Esben Haabendal wrote:
> >> > > "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> >> > > > On Wed, Jul 15, 2026 at 01:35:41PM +0200, Esben Haabendal wrote:
> >> > > >> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> >> > > >> > On Wed, Jul 15, 2026 at 10:07:39AM +0200, Esben Haabendal wrote:
...
> >> > > >> >> if (client->irq) {
> >> > > >> >> ret = request_threaded_irq(client->irq, NULL, mma8452_interrupt,
> >> > > >> >> - IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> >> > > >> >> + IRQF_TRIGGER_LOW | IRQF_ONESHOT |
> >> > > >> >> + data->open_drain ? IRQF_SHARED : 0,
> >> > > >> >> client->name, indio_dev);
> >> > > >> >
> >> > > >> > Why do we care?
> >> > > >>
> >> > > >> Care about what exactly?
> >> > > >
> >> > > > About exclusivity of the interrupt.
> >> > >
> >> > > Ok.
> >> > >
> >> > > >> We need to add IRQF_SHARED flag in order to allow shared interrupt, and
> >> > > >> we should not add it when using (the default) push-pull mode.
> >> > > >
> >> > > > Why not? How would it make any difference from SW perspective?
> >> > >
> >> > > Not adding the IRQF_SHARED flag prevents use with shared interrupts. I
> >> > > think we are on the same page on that.
> >> > >
> >> > > Unconditional adding IRQF_SHARED flag would allow configurations where
> >> > > other devices share interrupt line with mma8452 compatible chip
> >> > > configured with push-pull, resulting in broken or unpredictable results.
> >> > > I don't see why we should not care about that.
> >> >
> >> > But it's not their problem! If it's this device that prevents this
> >> > configuration, it should have a check. With this code it just hides
> >> > and changing a DT property will lead to kernel warning.
> >>
> >> The chip such does not prevent the configuration, and does not prevent
> >> sharing the interrupt. The irq pin in the device can be configured in either
> >> push-pull mode or open-drain mode.
> >> In order to allow sharing interrupt line with other chips, the chip
> >> must be configured with irq pin in open-drain mode, which is what the
> >> drive-open-drain device-tree property I am adding in this series enables
> >> developers to do.
> >> If/when you add this property to the device-tree, the irq pin will be
> >> in open-drain mode, and the IRQF_SHARED flag can (and should IMHO) be set
> >> as the interrupt line can be shared.
> >> If/when the drive-open-drain property is not set (existing device-trees
> >> and current only supported behavior), the chip cannot support sharing the
> >> interrupt line, and adding the IRQF_SHARED flag would be a bug, as the
> >> chip irq pin requires an exclusive interrupt input.
> >>
> >> Maybe the confusion is caused by the fact that the drive-open-drain
> >> does not describe how the irq pin IS behaving, but rather how it SHOULD
> >> behave, and possibly required because of the HW designed having tied the
> >> irq pin to an irq input together with other irq sources.
> >
> > Why do we care of push-pull then? Can't we always make it open-drain?
>
> No. Open-drain requires an external pull-up resistor. If there are no
> external pull-up resistor, open-drain will not work, and interrupt
> sharing is not possible.
Right. My question was basically to understand if we have the HW (platforms to
which this sensor is attached) that relies on this pin to be PP (in current
configuration)?
> >> > > > Yes, I understand the HW case.
> >> > > >
> >> > > >> > The (hidden) problem this will have in the future is that the IRQ core
> >> > > >> > will splat a warning in case that other shared IRQs might be
> >> > > >> > configured with different flags. Putting that flag conditionally makes
> >> > > >> > it a mine field for the users. Instead just unconditionally add that
> >> > > >> > flag and we will get reports as soon as there will be a user that
> >> > > >> > shares the same interrupt pin with some other devices which drivers do
> >> > > >> > not use the same settings.
> >> > > >>
> >> > > >> If we add the IRQF_SHARED flag unconditionally, it will be set also when
> >> > > >> push-pull mode is enabled. I don't see how the kernel will be able to
> >> > > >> notice that that is not going to work. If you have another device that
> >> > > >> uses IRQF_TRIGGER_LOW|IRF_ONESHOT|IRQF_SHARED, it will not work with the
> >> > > >> MMA8452 device when configured as push-pull.
> >> > > >
> >> > > > Right, and why do we care (again)?
> >> > >
> >> > > Why we care that the system as a whole (SW on top of HW) will not work?
> >> > >
> >> > > If we don't care about that, why do we even have this IRQF_SHARED flag?
> >> > > The only purpose of that is to tell the kernel that this particular
> >> > > device / interrupt will work with shared interrupt or not.
> >> > >
> >> > > Isn't that exactly what I do with this change? Nothing more, nothing less.
> >> > >
> >> > > > It's pure DT/FW/HW issue, not an SW issue.
> >> > > > Otherwise it will become a carefully placed mine for the poor user who will
> >> > > > use these flags and try to share an interrupt with the mma8452 device which
> >> > > > has no set property and uses push-pull mode.
> >> > >
> >> > > I don't get how you see it like that. Adding IRQF_SHARED unconditionally
> >> > > would create exactly the mine field you are talking about. Poor users
> >> > > can specify a system configuration (DT) that tries to use a shared
> >> > > interrupt line, but configures the mma8452 compatible chip in push-pull.
> >> > > The poor user will not only be poor, but also unhappy.
> >> >
> >> > > By applying the IRQF_SHARED dynamically, the kernel will be able to fail
> >> > > in a controlled manner instead, making it much less painful to create a
> >> > > working system configuration (DT)
> >> >
> >> > And my point that we need to make less painful runtime experience.
> >>
> >> Yes. We agree on that.
> >>
> >> But I do believe that my patch is that painful runtime experience.
> >>
> >> Adding IRQF_SHARED flag when irq pin is configured in push-pull mode
> >> will be painful. I know, that was my initial approach. Does really not
> >> work, and can lead to wasting time on debugging the HW.
> >>
> >> > > Going back to your poor user story above, if the poor user tries to
> >> > > share the interrupt pin with the mma8452 device, it will get an error
> >> > > (just as it is with the kernel today). The device does not support
> >> > > shared interrupts. Reading the DT bindings documentation, the user
> >> > > should be able to find the drive-open-drain property, and add that to
> >> > > the device-tree to make things work. Maybe even consider if that is
> >> > > compatible with the hardware being used.
> >> > >
> >> > > If IRQF_SHARED was set unconditionally, the user would not get an error,
> >> > > but most likely would get a system where no irq's were raised for the
> >> > > other chips. I sincerely believe that debugging this is much more
> >> > > painful than reading device-tree bindings.
> >> > >
> >> > > > Did I miss anything?
> >> > >
> >> > > I don't know. Maybe I am missing the obvious here.
> >> >
> >> > I consider the case when shared interrupt is enabled on both devices, but
> >> > second one (driver) missed the same IRQ flags. This becomes a warning in
> >> > IRQ core.
> >>
> >> Missed which IRQ flags?
> >
> > _LOW, for instance.
>
> All devices sharing an interrupt really do need to agree on these
> flags. Do you known any drivers that does not specify the trigger type
> when requesting an irq?.
Huh?! Majority of the device drivers! And that's how it should have been from
day 1, that's why I call this a pre-existing bug in this driver which we may
not address :-(. But we may address it when use SHARED interrupts.
> You cannot share an interrupt line if not all devices have the
> same trigger mode. So if one device on a shared interrupt has _LOW, all
> the other devices need to have that. Not just the flags, but the actual
> triggering mode of the device. Some chips might support more than one
> mode, others only one specific mode.
Yes.
> >> > Shared interrupts it's also a contract with all stakeholders on keeping
> >> > the same flags for all devices.
> >>
> >> Of-course.
> >>
> >> And adding IRQF_SHARED is a contract that says that the interrupt can be
> >> shared. I can only see that it would be a bug to add that flag in cases
> >> where we know that the interrupt really cannot be shared.
> >>
> >> As for the IRQF_TRIGGER_LOW flag being set, I think that looks correct
> >> as long as we do not support switching to active high irq polarity.
> >
> > No, it's not. It overrides whatever platform wants to have.
>
> The trigger type is not just a platform thing. It describes how the
> device behaves.
No, it describes how this certain device is connected to the certain platform.
It's a combination of what device is capable of and how platform design makes
use of it.
> Device that only support one triggering mode must set
> the flag that describes that. Devices that can be configured for
> different triggering modes can implement that, and should then configure
> the device for the chosen mode and set the flags accordingly.
Yes, but not in the device drivers!
> > It prevents PCB level designs from anything else.
>
> Yes. In this case, the current driver does not support designs that
> requires the mma8452 compatible chip to be configured for active high
> irq trigger. We could and probably should address that.
Exactly!
> But that is a different issue than what I am doing here. And I don't
> have hardware readily available where this can be tested, so I would
> prefer to let somebody else do that.
No objection on the specific issue, but...
> I am adding support for designs that require the mma8452 compatible chip
> to be configured for open-drain, while staying backwards compatible and
> allowing support for designs without external pull-up.
...the shared case *is* different. And I do not want the disaster (a bug)
to spread.
> In all cases, the driver should register the interrupt handle with the
> IRQF_TRIGGER_* flag that matches what the chip is configured for.
> I believe leaving it out is invalid.
Again, this chip is not a single party in the equation. Nobody prevents
to put a NOT gate on PCB to support this device and say other that wants
inverted polarity while sharing the same interrupt line.
> >> But on that topic, the chip actually supports selecting between active
> >> low and high irq polarity. Should we implement something along the lines
> >> of what is done in smi330_setup_irq() in iio/imu/smi330/smi330_core.c?
> >> And thereby allow using the device with active high irq?
...
> >> > After looking into genirq code I don't see other way how to handle this.
> >> > It looks like we need to address the TRIGGER_LOW first, in other words
> >> > we need drop that flag when IRQF_SHARED is set, and leave it to users
> >> > to setup IRQ trigger properly on all sides.
> >>
> >> Why do we need to drop the IRQF_TRIGGER_LOW flag because IRQF_SHARED is
> >> set?
> >>
> >> Users as in those specifying the system device-tree?
> >
> > No, because like I said, the SHARED is a *contract*, it's not just a setting.
>
> Absolutely. That is the key here.
>
> IQRF_SHARED is a contract, where the driver promises to return IRQ_NONE
> if the interrupt is not for that device. This is already implemented
> by mma8452_interrupt().
>
> > And that contract includes the similarities on the IRQ flags. One may not
> > have two devices with different trigger level, it's a common sense,
> > right?
>
> Right.
>
> And that is exactly why we have to specify the IRQF_TRIGGER_* flag that
> the irq output is configured for.
No, definitely the opposite. We may *not* specify this flag in the driver,
we have to rely on the _platform_ configuration. PCB level.
> The driver will not switch to the
> desired trigger level based on what other devices on the same interrupt
> uses. You have to configure/specify the trigger mode and leve and set
> the IRQF_TRIGGER_* flag accordingly.
Yes, but not in the driver!
> > So, SHARED must exclude anything that comes from the platform description or
> > IRQ chip controller (limitations).
>
> Now you got me confused again. The IRQF_TRIGGER_LOW flag given to
> request_threaded_irq() is not coming from platform description or IRQ
> chip controller. It describes the trigger mode that the chip is
> excercising in the current implementation.
And this is wrong. It's not device driver business to define this. More
accurate it's not only of the device in question and how it works.
> The kernel would not know how to configure the IRQ chip controller, and
> in case of shared interrupts, would not be able to check that the
> devices sharing the interrupt is configured correctly.
Huh?! The kernel is responsible to program IRQ chip and the respective
device drivers in accordance with the platform design (and protocol to
supply it to the OS is called DT or ACPI or ...).
There are several limitations for this:
- IRQ chip that might not support certain trigger configurations
- device that can only take subset of trigger configurations
- in shared line case all of the devices need to agree on that
on a _platform_ level
> > So, without addressing that, it makes a little sense to add SHARED.
>
> Not true.
True. Obviously we have a disagreement here and I tried hard to explain
my point above.
> Let me take my system here. I have multiple chips / irq sources
> connected to the same interrupt input on the CPU. They are all using
> level low triggering (which hardware and system engineers have ofcourse
> been observant enough to ensure).
And if not? Isn't it possible to make them share an interrupt line?
Of course it's very much possible, but in the platform description
the both devices will need to have the same one, so for the second
one it will be a bit of a lie (due to an external NOT gate or a latch
or any other PCB level tricks).
> Without my change, the mma8452 driver does not support configuring the
> chip to use open-drain, so it will be pulling the interrupt line high,
> interrupting irq for all interrupt sources.
I even don't consider this, this is obvious. And you are correct here.
> With my change, I can now configure the device to use open-drain,
> register the interrupt, and everything works nicely.
Nope, it depends on the other stakeholders.
> And the change is backwards compatible, as you have to specify
> drive-open-drain to switch from PP to OD.
>
> How does that not make sense?
Please, read again what I wrote.
> > I would accept this patch without adding SHARED, perhaps.
>
> Without IRQF_SHARED, I cannot use it with the hardware I have which are
> sharing the interrupt.
True, but with _LOW it makes a little sense to use SHARED.
> > But still question why we can't use the OD instead of PP for the pin
> > to begin with?
>
> Because HW needs to be designed for OD. It is perfectly valid to design
> hardware that relies on the default mode of mma8452 and compatible chips
> to use PP. Switching to OD will not work for such systems without
> external pull-up.
>
> > Do we have real HW that uses IRQ input without a pull-up?
>
> I certainly have had such designs many times in the past.
Okay.
> Why should we implement the driver so that we cannot support such valid
> HW designs?
This is exactly my question as your patch limits this to _LOW.
And this is a big issue with it.
...
P.S.
I'm on vacation, but I disagree on the approach taken in this patch.
I leave it to you and Jonathan and others to settle down.
Here is my formal NAK (to this form of the patch, as I said, w/o shared
support it might be okay to go).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 7/7] clk: tests: Add Kunit testing for nexus nodes
From: sashiko-bot @ 2026-07-17 17:41 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric); +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260717-schneider-v7-2-rc1-eip201-upstream-v4-7-751547e160e5@bootlin.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] `of_find_node_by_name_kunit()` creates a double-free / use-after-free trap via its `from` argument.
- [Medium] `of_find_node_by_name_kunit()` returns an `ERR_PTR` on failure, breaking the expected `NULL` failure semantic of `of_find_node_by_name()`.
--
--- Patch [7]: [PATCH v4 7/7] clk: tests: Add Kunit testing for nexus nodes ---
commit abd4c1ecb509bcaa0e834d4c06b41750affacb27
Author: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
clk: tests: Add Kunit testing for nexus nodes
Add a nexus node with a child requesting a mapped clock in the fake DT
overlay to verify that the parsing is also correctly working. Create an
of_find_node_by_name() like kunit helper to garbage collect the node
automatically in case of failed assertion.
> diff --git a/drivers/clk/clk_kunit_helpers.c b/drivers/clk/clk_kunit_helpers.c
> index 68a28e70bb61c..daaf1cf1546c4 100644
> --- a/drivers/clk/clk_kunit_helpers.c
> +++ b/drivers/clk/clk_kunit_helpers.c
[ ... ]
> +struct device_node *of_find_node_by_name_kunit(struct kunit *test, struct device_node *from,
> + const char *name)
> +{
> + struct device_node *np;
> + int ret;
> +
> + np = of_find_node_by_name(from, name);
[Severity: Medium]
Will this lead to a double-free if the from argument is another
KUnit-managed node?
of_find_node_by_name() explicitly drops the reference on its from argument.
If a test author passes a node previously returned by
of_find_node_by_name_kunit(), the underlying of_find_node_by_name() will
consume the reference immediately.
KUnit is unaware of this and will execute its deferred action at the end of the
test, calling of_node_put() a second time on the already freed node.
> + if (!np)
> + return NULL;
> +
> + ret = kunit_add_action_or_reset(test, of_node_put_wrapper, np);
> + if (ret)
> + return ERR_PTR(ret);
[Severity: Medium]
Could this ERR_PTR() return value cause crashes for callers using standard OF
node pointer checks?
The standard of_find_node_by_name() strictly returns NULL on failure, and
callers typically check for failure using if (!np). Returning an ERR_PTR()
here means truthy checks will pass, potentially leading to an invalid pointer
dereference when the caller attempts to use the returned error pointer as a
device_node struct.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com?part=7
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mmc: Add post-power-off-delay-ms property
From: Judith Mendez @ 2026-07-17 17:40 UTC (permalink / raw)
To: Ulf Hansson
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-mmc, devicetree, linux-kernel
In-Reply-To: <CAPx+jO-a3+mv2msL+12Ag-xs33es2+Wxbr_uKRMY3rbN7eL-cw@mail.gmail.com>
Hi Ulf,
On 7/17/26 5:21 AM, Ulf Hansson wrote:
> On Fri, Jul 17, 2026 at 1:26 AM Judith Mendez <jm@ti.com> wrote:
>>
>> Add post-power-off-delay-ms property to MMC controller common.
>>
>> This property shall be used to specify delay if needed after
>> deasserting power during MMC power cycles.
>
> Please clarify with some additional information from the cover-letter,
> like "specify custom delays after MMC power off to work around
> hardware issues such as slow RC circuites on MMC VDD rails."
>
>>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>> .../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> index 3d7195e9461c3..3ff68d32a308f 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> @@ -275,6 +275,14 @@ properties:
>> not available.
>> default: 10
>>
>> + post-power-off-delay-ms:
>
> For mmc-pwrseq-simple we already have "power-off-delay-us", perhaps
> better to re-use that name instead.
Besides having the same dt property name as mmc-pwrseq-simple what is
the benefit of switching to power-off-delay-us?
All values will have to be in us instead of ms and thus will look a bit
less clean in code. If it is just a naming preference, I do prefer
the current name in this version, please let me know if we can keep:
post-power-off-delay-ms.
All other comments I agree with and will fix in v2.
Thanks for reviewing (:
~ Judith
>
>> + description:
>> + The presence of this property indicates that the card requires a
>> + delay (in milliseconds) after power off before the next power on.
>
> Again, maybe something to indicate this is specific like "specify
> custom delays after MMC power off to work around
> hardware issues such as slow RC circuites on MMC VDD rails."
>
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 10000
>
> Are the above limits needed at all?
>
> I suggest we add a "default: 1", as that would correspond to the
> hardcoded value that the mmc core currently uses for this delay.
>
>> +
>> supports-cqe:
>> $ref: /schemas/types.yaml#/definitions/flag
>> description:
>> --
>> 2.54.0
>>
>
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: watchdog: Add compatible for MediaTek mt8167
From: sashiko-bot @ 2026-07-17 17:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia; +Cc: linux-watchdog, robh, devicetree, conor+dt
In-Reply-To: <20260717163959.714561-4-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `mediatek,mt8167-wdt` compatible string is added as a standalone compatible (without fallback) in the DT bindings, but the patch series is missing the corresponding driver support and reset definitions header.
--
--- Patch [3]: [PATCH v2 3/7] dt-bindings: watchdog: Add compatible for MediaTek mt8167 ---
commit 666f2d36168cb1a5fa647ba2d10b40b0cd2f2240
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
dt-bindings: watchdog: Add compatible for MediaTek mt8167
This commit adds a dedicated compatible string for the MediaTek mt8167
watchdog. It replaces the previous fallback to mt6589-wdt since the
mt8167 hardware has 15 software resets instead of 12, and in a different
order.
> diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> index 953629cb9558b..f514be8a5851d 100644
> --- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> @@ -26,6 +26,7 @@ properties:
> - mediatek,mt6795-wdt
> - mediatek,mt7986-wdt
> - mediatek,mt7988-wdt
> + - mediatek,mt8167-wdt
[Severity: Medium]
Will this new compatible string probe successfully without driver support?
Looking at the driver match table:
drivers/watchdog/mtk_wdt.c:mtk_wdt_dt_ids[] {
{ .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data },
...
}
It seems there is no match entry for "mediatek,mt8167-wdt".
Since this is added as a standalone compatible without a fallback to
an existing string, any device tree using it will fail to probe the
watchdog driver.
Additionally, the commit message mentions the mt8167 has 15 software resets
instead of 12, but there doesn't appear to be a corresponding dt-bindings
header exporting these new reset indices for device tree consumers to use.
> - mediatek,mt8183-wdt
> - mediatek,mt8186-wdt
> - mediatek,mt8188-wdt
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717163959.714561-1-l.scorcia@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: phy: add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver
From: sashiko-bot @ 2026-07-17 17:33 UTC (permalink / raw)
To: Artem Shimko; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260716173325.653164-3-a.shimko.dev@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The fallback logic for missing delay properties incorrectly applies default delays to both RX and TX paths for RGMII_TXID and RGMII_RXID modes, breaking RGMII semantics.
- [High] Silent truncation of negative MDIO read errors due to `u16` variable typing causes the PHY reset polling loop to falsely report success.
- [High] The RGMII configuration is written to the PHY after the software reset, preventing the settings from taking effect.
--
--- Patch [2]: [PATCH net-next v3 2/2] net: phy: add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver ---
commit cafde85b2bbf112f7902c7badc2f66ec1f9c7bc5
Author: Artem Shimko <a.shimko.dev@gmail.com>
net: phy: add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver
This commit adds a new driver for the DAPU Telecom DAP8211R(I) Gigabit
Ethernet PHY. It supports RGMII delay configuration through device tree
properties and optional 180-degree TX clock phase shifting.
> diff --git a/drivers/net/phy/dap8211r.c b/drivers/net/phy/dap8211r.c
> new file mode 100644
> index 0000000000000..e6381fd8c98c2
> --- /dev/null
> +++ b/drivers/net/phy/dap8211r.c
[ ... ]
> +static int dap8211r_config_init(struct phy_device *phydev)
> +{
> + struct device_node *phydev_node = phydev->mdio.dev.of_node;
> + u16 set = 0, val = 0;
[Severity: High]
Does declaring val as u16 truncate negative error codes returned by
dap8211r_read_ext() during polling?
If dap8211r_read_ext() returns a negative error like -EIO, the truncated
value will still have its high bit set, which might cause the polling
loop below to exit early and falsely report success.
> + int ret;
> + s32 internal_delay;
> +
> + if (of_property_read_bool(phydev_node, "dapu,tx-inverted-clk"))
> + set |= DAP8211R_RGMII_CLK_INVERT;
> +
> + internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,
> + DAP8211R_DELAY_SIZE, true);
> + if (internal_delay < 0) {
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> + internal_delay = 0;
> + else
> + internal_delay = DAP8211R_DEFAULT_DEL_SEL;
> + }
[Severity: High]
If the rx-internal-delay-ps property is missing and the interface mode is
PHY_INTERFACE_MODE_RGMII_TXID, does this fallback logic incorrectly apply
the default delay (DAP8211R_DEFAULT_DEL_SEL) to the RX path?
For RGMII_TXID, should the RX delay instead be 0?
> +
> + set |= FIELD_PREP(DAP8211R_RGMII_RX_DEL_MASK, internal_delay);
> +
> + internal_delay = phy_get_internal_delay(phydev, dap8211r_internal_delay,
> + DAP8211R_DELAY_SIZE, false);
> + if (internal_delay < 0) {
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII)
> + internal_delay = DAP8211R_INIT_TX_DEL_VAL;
> + else
> + internal_delay = DAP8211R_DEFAULT_DEL_SEL;
> + }
[Severity: High]
Similarly, if tx-internal-delay-ps is missing and the interface mode is
PHY_INTERFACE_MODE_RGMII_RXID, will this incorrectly apply the default delay
to the TX path when it should be 0?
> +
> + set |= FIELD_PREP(DAP8211R_RGMII_TX_DEL_MASK, internal_delay);
> +
> + ret = dap8211r_modify_ext(phydev, DAP8211R_PHY_CON, DAP8211R_PHY_SW_RST, 0);
> + if (ret)
> + return ret;
> +
> + /* Wait for reset self-clear (max 200 us) */
> + ret = read_poll_timeout(dap8211r_read_ext, val,
> + (val & DAP8211R_PHY_SW_RST),
> + 20, 200, false, phydev, DAP8211R_PHY_CON);
> + if (ret)
> + return ret;
> +
> + ret = dap8211r_modify_ext(phydev, DAP8211R_RGMII_CON, DAP8211R_RGMII_CONFIG_MASK, set);
[Severity: High]
Is the RGMII configuration written to the PHY after the software reset
completes?
The initialization comment mentions a software reset is used to apply
settings. If we write the RGMII configuration after the reset, will the
settings take effect, or will the PHY operate with uninitialized values?
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716173325.653164-1-a.shimko.dev@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dt-bindings: net: add DAPU Telecom DAP8211R(I) PHY binding
From: sashiko-bot @ 2026-07-17 17:33 UTC (permalink / raw)
To: Artem Shimko; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260716173325.653164-2-a.shimko.dev@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The vendor prefix 'dapu' (used in the filename 'dapu,dap8211r.yaml' and the property 'dapu,tx-inverted-clk') is not registered in the 'vendor-prefixes.yaml' file.
--
--- Patch [1]: [PATCH net-next v3 1/2] dt-bindings: net: add DAPU Telecom DAP8211R(I) PHY binding ---
commit 3e68dcf4de91d264592b244d85a077b73ce34c7c
Author: Artem Shimko <a.shimko.dev@gmail.com>
dt-bindings: net: add DAPU Telecom DAP8211R(I) PHY binding
This commit adds device tree binding documentation for the DAPU Telecom
DAP8211R(I) Gigabit Ethernet PHY. It specifies support for RGMII with
configurable TX/RX clock delays and introduces the dapu,tx-inverted-clk
vendor-specific extension.
> diff --git a/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
> new file mode 100644
> index 0000000000000..d4012fa17a1e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
[ ... ]
> + tx-internal-delay-ps:
> + description:
> + RGMII TX clock delay in picoseconds (0 to maximum).
> + multipleOf: 150
> + maximum: 2250
> + default: 1950
> +
> + dapu,tx-inverted-clk:
[Severity: Low]
Is the dapu vendor prefix registered in vendor-prefixes.yaml?
Failing to document the dapu prefix in
Documentation/devicetree/bindings/vendor-prefixes.yaml causes standard
device tree validation tools to emit a warning or error about an
undocumented vendor prefix when processing this schema.
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + If present, the RGMII TX clock to the MAC is inverted (180 degree
> + phase shift relative to the data lines). This is a vendor-specific
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716173325.653164-1-a.shimko.dev@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 2/7] watchdog: mediatek: Add wdt/toprgu resets for MT6589
From: sashiko-bot @ 2026-07-17 17:30 UTC (permalink / raw)
To: Luca Leonardo Scorcia; +Cc: conor+dt, robh, linux-watchdog, devicetree
In-Reply-To: <20260717163959.714561-3-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Reset controller is synchronously registered before its structural configuration variable `has_swsysrst_en` is initialized.
--
--- Patch [2]: [PATCH v2 2/7] watchdog: mediatek: Add wdt/toprgu resets for MT6589 ---
commit 3b51cb7125d43b8f8ea3a7996ec1844775ec36b1
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
watchdog: mediatek: Add wdt/toprgu resets for MT6589
This commit populates the toprgu_sw_rst_num field for the MT6589 watchdog data.
It maps the 12 reset bits available in the WDT_SWSYSRST register to allow
toprgu resets via the device tree.
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 91d110646e16f..e61f6ae743276 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
[ ... ]
> @@ -88,6 +89,10 @@ static const struct mtk_wdt_data mt2712_data = {
> .toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM,
> };
>
> +static const struct mtk_wdt_data mt6589_data = {
> + .toprgu_sw_rst_num = MT6589_TOPRGU_SW_RST_NUM,
> +};
> +
> static const struct mtk_wdt_data mt6735_data = {
> .toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM,
> };
[Severity: High]
This is a pre-existing issue, but registering the reset controller in
mtk_wdt_probe() happens before the structural configuration is fully
initialized:
drivers/watchdog/mtk_wdt.c:mtk_wdt_probe() {
...
wdt_data = of_device_get_match_data(dev);
if (wdt_data) {
err = toprgu_register_reset_controller(pdev,
wdt_data->toprgu_sw_rst_num);
if (err)
return err;
mtk_wdt->has_swsysrst_en = wdt_data->has_swsysrst_en;
}
...
}
If a consumer driver probes concurrently and asserts the reset line, could it
execute before the has_swsysrst_en flag is set?
On SoCs requiring software reset enable, reading the uninitialized
has_swsysrst_en as false would cause the reset assertion to fail silently,
potentially leaving consumer devices in an undefined state.
Should mtk_wdt->has_swsysrst_en be initialized before calling
toprgu_register_reset_controller()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717163959.714561-1-l.scorcia@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v4 5/7] clk: Use the generic OF phandle parsing in only one place
From: sashiko-bot @ 2026-07-17 17:28 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric); +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260717-schneider-v7-2-rc1-eip201-upstream-v4-5-751547e160e5@bootlin.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Returning a dangling pointer to a device node's name after dropping the node's reference count.
- [High] Returning a dangling pointer to a clock core's name after dropping the clock reference.
- [High] Loss of the requested clock index when falling back to a parent node via the `clock-ranges` property.
--
--- Patch [5]: [PATCH v4 5/7] clk: Use the generic OF phandle parsing in only one place ---
commit ae5ff381e475c55a5d269ef4dce5a639c14cc437
Author: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
clk: Use the generic OF phandle parsing in only one place
This commit replaces the use of of_parse_phandle_with_args() with
of_parse_clkspec() inside of_clk_get_parent_name(). It also modifies
of_parse_clkspec() to stop traversing up the device tree if a "clocks"
property is found.
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 7d63d81ebc096..45f5d7a4ccc17 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -5219,6 +5219,8 @@ static int of_parse_clkspec(const struct device_node *np, int index,
> * has a "clock-ranges" property, then we can try one of its
> * clocks.
> */
> + if (of_property_present(np, "clocks"))
> + break;
> np = np->parent;
> if (np && !of_property_present(np, "clock-ranges"))
> break;
[Severity: High]
This is a pre-existing issue, but this patch significantly exacerbates it.
When falling back to the parent node via the "clock-ranges" property, does
this discard the caller's requested clock index?
drivers/clk/clk.c:of_parse_clkspec() {
...
np = np->parent;
if (np && !of_property_present(np, "clock-ranges"))
break;
index = 0;
}
By hardcoding index to 0 before iterating to the parent, the requested clock
index is lost. The function incorrectly looks up index 0 on the parent node
regardless of what index the caller originally requested. This breaks
index-based clock lookups for devices relying on "clock-ranges" to inherit
clocks.
Since this patch switches of_clk_get_parent_name() to use of_parse_clkspec(),
when of_clk_parent_fill() requests parents 0, 1, 2, etc., will it now silently
receive identical copies of the parent's 0th clock name for all indices and
corrupt the hardware clock tree topology?
> @@ -5364,8 +5366,7 @@ const char *of_clk_get_parent_name(const struct device_node *np, int index)
> int count;
> struct clk *clk;
>
> - rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
> - &clkspec);
> + rc = of_parse_clkspec(np, index, NULL, &clkspec);
> if (rc)
> return NULL;
>
[Severity: High]
This isn't a bug introduced by this patch, but looking further down in
of_clk_get_parent_name(), does this return a dangling pointer if the device
tree node is dynamically removed?
drivers/clk/clk.c:of_clk_get_parent_name() {
...
if (IS_ERR(clk)) {
if (clkspec.args_count == 0)
clk_name = clkspec.np->name;
else
clk_name = NULL;
} else {
...
of_node_put(clkspec.np);
return clk_name;
}
The string pointer clk_name is retrieved from the device node, but the
reference to the node is immediately dropped via of_node_put(clkspec.np). If
the node and its name string are freed, for example via DT overlay removal,
any subsequent access to the child's cached parent name by the clock framework
would lead to a Use-After-Free.
[Severity: High]
This is another pre-existing issue in the same function, but does this also
return a dangling pointer if the parent clock provider is dynamically
unregistered?
drivers/clk/clk.c:of_clk_get_parent_name() {
...
} else {
clk_name = __clk_get_name(clk);
clk_put(clk);
}
}
of_node_put(clkspec.np);
return clk_name;
}
The clock name is retrieved via __clk_get_name(clk), but the consumer
reference is immediately dropped via clk_put(clk). If the parent clock
provider unregisters (e.g., on driver unbind or module unload), the parent's
clk_core structure and its name string are freed. This could trigger a
Use-After-Free on any subsequent access by the child clock.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com?part=5
^ permalink raw reply
* Re: [PATCH v4 3/7] clk: tests: Add Kunit testing for of_clk_get_parent_name()
From: sashiko-bot @ 2026-07-17 17:11 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric); +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260717-schneider-v7-2-rc1-eip201-upstream-v4-3-751547e160e5@bootlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Potential use-after-free of device tree strings and clock names when returning clock parent names.
--
--- Patch [3]: [PATCH v4 3/7] clk: tests: Add Kunit testing for of_clk_get_parent_name() ---
commit 4b760cb4ff3b2b61c5f90468c3fd87c387504cd7
Author: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
clk: tests: Add Kunit testing for of_clk_get_parent_name()
This commit adds a Kunit test to verify that of_clk_get_parent_name()
returns the correct clock name when looking up by index.
> diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
> index f47f81b7d72a4..4084559e157df 100644
> --- a/drivers/clk/clk_test.c
> +++ b/drivers/clk/clk_test.c
[ ... ]
> @@ -3637,9 +3637,23 @@ static void clk_parse_clkspec_with_incorrect_index_and_name(struct kunit *test)
> KUNIT_EXPECT_TRUE(test, IS_ERR(hw));
> }
>
> +/*
> + * Verify that of_clk_get_parent_name() returns the correct clock name when
> + * looking up by index through the consumer's clocks property.
> + */
> +static void of_clk_get_parent_name_gets_parent_name(struct kunit *test)
> +{
> + struct clk_parse_clkspec_ctx *ctx = test->priv;
> + const char *expected_name = "clk_parse_clkspec_1";
> +
> + KUNIT_EXPECT_STREQ(test, expected_name,
> + of_clk_get_parent_name(ctx->cons_np, 0));
[Severity: High]
This isn't a bug introduced by this patch, but does of_clk_get_parent_name()
return a potentially dangling pointer here?
Looking at of_clk_get_parent_name() in drivers/clk/clk.c:
clk_name = __clk_get_name(clk);
clk_put(clk);
...
of_node_put(clkspec.np);
return clk_name;
The string pointer is extracted and the reference to its owning object (the
clock or the device node) is dropped before returning. If the node is from a
removed DT overlay or the clock provider is concurrently unregistered, and
this was the last reference, wouldn't the memory backing the string be freed
leaving the caller with a dangling pointer?
> +}
> +
> static struct kunit_case clk_parse_clkspec_test_cases[] = {
> KUNIT_CASE(clk_parse_clkspec_with_correct_index_and_name),
> KUNIT_CASE(clk_parse_clkspec_with_incorrect_index_and_name),
> + KUNIT_CASE(of_clk_get_parent_name_gets_parent_name),
> {}
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com?part=3
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs
From: sashiko-bot @ 2026-07-17 17:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia; +Cc: conor+dt, robh, linux-watchdog, devicetree
In-Reply-To: <20260717163959.714561-2-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch adds reset provider capabilities for MT6589 without updating the corresponding YAML schema to require `#reset-cells`.
--
--- Patch [1]: [PATCH v2 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs ---
commit 1610507569a41df45fcf55f93c1df6323ff7d422
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
dt-bindings: reset: Add MT6589 toprgu reset IDs
This commit introduces the reset constants for the 12 MT6589 toprgu
resets to be used as a reset provider.
> diff --git a/include/dt-bindings/reset/mediatek,mt6589-resets.h b/include/dt-bindings/reset/mediatek,mt6589-resets.h
> new file mode 100644
> index 0000000000000..ee08c39df5131
> --- /dev/null
> +++ b/include/dt-bindings/reset/mediatek,mt6589-resets.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> + */
> +
> +#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT6589
> +#define _DT_BINDINGS_RESET_CONTROLLER_MT6589
> +
> +/* TOPRGU resets */
[Severity: Low]
Does Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml need to
be updated to require #reset-cells when using mediatek,mt6589-wdt?
When adding reset provider capabilities for a hardware variant, the schema
typically requires an allOf/if-then block to add #reset-cells to the required
list. Without this update, a device tree node utilizing the MT6589 watchdog
as a reset provider could omit #reset-cells and still silently pass
dt_binding_check validation.
> +#define MT6589_TOPRGU_INFRA_SW_RST 0
> +#define MT6589_TOPRGU_MM_SW_RST 1
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717163959.714561-1-l.scorcia@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: input: focaltech,ft8112: Add focaltech,ft3d81 compatible
From: Dmitry Torokhov @ 2026-07-17 16:54 UTC (permalink / raw)
To: Pradyot Kumar Nayak
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Peng,
Bjorn Andersson, Konrad Dybcio, Abel Vesa, Dmitry Baryshkov,
linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <20260717-add_focaltech_ft3d81_touchscreen_support-v4-1-5dd091e25801@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 05:28:34PM +0530, Pradyot Kumar Nayak wrote:
> The Focaltech ft3d81 is fully compatible with the ft8112 i.e.
> it uses the same I2C-HID protocol and the same power-on/reset sequencing,
> DT nodes for boards carrying an ft3d81,can therefore bind to the existing
> ft8112 driver without any additional changes.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
Applied, thank you.
--
Dmitry
^ 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