* [PATCH v4 3/7] clk: tests: Add Kunit testing for of_clk_get_parent_name()
From: Miquel Raynal (Schneider Electric) @ 2026-07-17 15:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brendan Higgins, David Gow,
Rae Moar
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-kselftest, kunit-dev,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com>
Make sure this helper is never broken, especially since we will soon
make some changes in it.
Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
---
drivers/clk/clk_test.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
index f47f81b7d72a..4084559e157d 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));
+}
+
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),
{}
};
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/7] clk: tests: Add clk_parse_clkspec() Kunit testing
From: Miquel Raynal (Schneider Electric) @ 2026-07-17 15:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brendan Higgins, David Gow,
Rae Moar
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-kselftest, kunit-dev,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com>
Create a new set of kunit tests to make sure clk_parse_clkspec() is
working as expected. We currently verify if we get a proper device when
using indexes and names. If we make an out of bounds request we expect
an error.
For testing purposes, we must ensure of_clk_get_hw()'s symbol is
exported.
Suggested-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
---
drivers/clk/Makefile | 1 +
drivers/clk/clk.c | 2 +
drivers/clk/clk_test.c | 110 +++++++++++++++++++++++++++++++
drivers/clk/kunit_clk_parse_clkspec.dtso | 21 ++++++
4 files changed, 134 insertions(+)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index cc108a75a900..035b984db70d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -19,6 +19,7 @@ clk-test-y := clk_test.o \
kunit_clk_assigned_rates_zero.dtbo.o \
kunit_clk_assigned_rates_zero_consumer.dtbo.o \
kunit_clk_hw_get_dev_of_node.dtbo.o \
+ kunit_clk_parse_clkspec.dtbo.o \
kunit_clk_parent_data_test.dtbo.o
obj-$(CONFIG_COMMON_CLK) += clk-divider.o
obj-$(CONFIG_COMMON_CLK) += clk-fixed-factor.o
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 048adfa86a5d..08874cf9b561 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -24,6 +24,7 @@
#include <linux/spinlock.h>
#include <linux/string.h>
#include <linux/stringhash.h>
+#include <kunit/visibility.h>
#include "clk.h"
@@ -5300,6 +5301,7 @@ struct clk_hw *of_clk_get_hw(struct device_node *np, int index,
return hw;
}
+EXPORT_SYMBOL_IF_KUNIT(of_clk_get_hw);
static struct clk *__of_clk_get(struct device_node *np,
int index, const char *dev_id,
diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
index b1961daac5e2..f47f81b7d72a 100644
--- a/drivers/clk/clk_test.c
+++ b/drivers/clk/clk_test.c
@@ -3541,10 +3541,119 @@ static struct kunit_suite clk_hw_get_dev_of_node_test_suite = {
.test_cases = clk_hw_get_dev_of_node_test_cases,
};
+static const struct clk_init_data clk_parse_clkspec_1_init_data = {
+ .name = "clk_parse_clkspec_1",
+ .ops = &empty_clk_ops,
+};
+
+static const struct clk_init_data clk_parse_clkspec_2_init_data = {
+ .name = "clk_parse_clkspec_2",
+ .ops = &empty_clk_ops,
+};
+
+struct clk_parse_clkspec_ctx {
+ struct device_node *cons_np;
+};
+
+static int clk_parse_clkspec_init(struct kunit *test)
+{
+ struct device_node *prov1_np, *prov2_np;
+ struct clk_parse_clkspec_ctx *ctx;
+ struct clk_hw *hw1, *hw2;
+
+ ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+ test->priv = ctx;
+
+ KUNIT_ASSERT_EQ(test, 0, of_overlay_apply_kunit(test, kunit_clk_parse_clkspec));
+
+ /* Register provider 1 */
+ hw1 = kunit_kzalloc(test, sizeof(*hw1), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw1);
+ hw1->init = &clk_parse_clkspec_1_init_data;
+
+ prov1_np = of_find_compatible_node(NULL, NULL, "test,clock-provider1");
+ KUNIT_ASSERT_NOT_NULL(test, prov1_np);
+ of_node_put_kunit(test, prov1_np);
+
+ KUNIT_ASSERT_EQ(test, 0, of_clk_hw_register_kunit(test, prov1_np, hw1));
+ KUNIT_ASSERT_EQ(test, 0, of_clk_add_hw_provider_kunit(test, prov1_np, of_clk_hw_simple_get, hw1));
+
+ /* Register provider 2 */
+ hw2 = kunit_kzalloc(test, sizeof(*hw2), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw2);
+ hw2->init = &clk_parse_clkspec_2_init_data;
+
+ prov2_np = of_find_compatible_node(NULL, NULL, "test,clock-provider2");
+ KUNIT_ASSERT_NOT_NULL(test, prov2_np);
+ of_node_put_kunit(test, prov2_np);
+
+ KUNIT_ASSERT_EQ(test, 0, of_clk_hw_register_kunit(test, prov2_np, hw2));
+ KUNIT_ASSERT_EQ(test, 0, of_clk_add_hw_provider_kunit(test, prov2_np, of_clk_hw_simple_get, hw2));
+
+ ctx->cons_np = of_find_compatible_node(NULL, NULL, "test,clock-consumer");
+ KUNIT_ASSERT_NOT_NULL(test, ctx->cons_np);
+ of_node_put_kunit(test, ctx->cons_np);
+
+ return 0;
+}
+
+/* Test DT phandle lookups using correct index or name succeed */
+static void clk_parse_clkspec_with_correct_index_and_name(struct kunit *test)
+{
+ struct clk_parse_clkspec_ctx *ctx = test->priv;
+ struct clk_hw *hw1, *hw2, *hw3, *hw4;
+
+ /* Get clocks by index */
+ hw1 = of_clk_get_hw(ctx->cons_np, 0, NULL);
+ KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw1);
+
+ hw2 = of_clk_get_hw(ctx->cons_np, 1, NULL);
+ KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw2);
+ KUNIT_EXPECT_PTR_NE(test, hw1, hw2);
+
+ /* Get clocks by name */
+ hw3 = of_clk_get_hw(ctx->cons_np, 0, "first_clock");
+ KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw3);
+ KUNIT_EXPECT_PTR_EQ(test, hw1, hw3);
+
+ hw4 = of_clk_get_hw(ctx->cons_np, 0, "second_clock");
+ KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw4);
+ KUNIT_EXPECT_PTR_EQ(test, hw2, hw4);
+}
+
+/* Test DT phandle lookups using wrong index or name fail */
+static void clk_parse_clkspec_with_incorrect_index_and_name(struct kunit *test)
+{
+ struct clk_parse_clkspec_ctx *ctx = test->priv;
+ struct clk_hw *hw;
+
+ /* Get clock by index */
+ hw = of_clk_get_hw(ctx->cons_np, 2, NULL);
+ KUNIT_EXPECT_TRUE(test, IS_ERR(hw));
+
+ /* Get clock by name */
+ hw = of_clk_get_hw(ctx->cons_np, 0, "third_clock");
+ KUNIT_EXPECT_TRUE(test, IS_ERR(hw));
+}
+
+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),
+ {}
+};
+
+/* Test suite to verify clk_parse_clkspec() */
+static struct kunit_suite clk_parse_clkspec_test_suite = {
+ .name = "clk_parse_clkspec",
+ .init = clk_parse_clkspec_init,
+ .test_cases = clk_parse_clkspec_test_cases,
+};
kunit_test_suites(
&clk_assigned_rates_suite,
&clk_hw_get_dev_of_node_test_suite,
+ &clk_parse_clkspec_test_suite,
&clk_leaf_mux_set_rate_parent_test_suite,
&clk_test_suite,
&clk_multiple_parents_mux_test_suite,
@@ -3562,4 +3671,5 @@ kunit_test_suites(
&clk_uncached_test_suite,
);
MODULE_DESCRIPTION("Kunit tests for clk framework");
+MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/kunit_clk_parse_clkspec.dtso b/drivers/clk/kunit_clk_parse_clkspec.dtso
new file mode 100644
index 000000000000..c93feb93e101
--- /dev/null
+++ b/drivers/clk/kunit_clk_parse_clkspec.dtso
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ kunit_clock_provider1: kunit-clock-provider1 {
+ compatible = "test,clock-provider1";
+ #clock-cells = <1>;
+ };
+
+ kunit_clock_provider2: kunit-clock-provider2 {
+ compatible = "test,clock-provider2";
+ #clock-cells = <1>;
+ };
+
+ kunit-clock-consumer {
+ compatible = "test,clock-consumer";
+ clocks = <&kunit_clock_provider1 0>, <&kunit_clock_provider2 0>;
+ clock-names = "first_clock", "second_clock";
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/7] dt-bindings: clock: Introduce nexus nodes
From: Miquel Raynal (Schneider Electric) @ 2026-07-17 15:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brendan Higgins, David Gow,
Rae Moar
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-kselftest, kunit-dev,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260717-schneider-v7-2-rc1-eip201-upstream-v4-0-751547e160e5@bootlin.com>
Hardware containers can just decouple external resources like clock
without any more control. Nexus nodes already exist for PWM and GPIOs,
add a binding to allow them for clocks as well.
No examples are given, the file is litteraly a copy-paste from Hervé
Codina's work on PWM Nexus nodes, hence we just point to the examples
there which already illustrate very clearly the concept of the various
properties.
Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
---
.../bindings/clock/clock-nexus-node.yaml | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
new file mode 100644
index 000000000000..ff3283bd5fb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/clock-nexus-node.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock Nexus
+
+description: >
+ A nexus node allows to remap a clock specifier list in a consumer node
+ through a container or a connector node in a generic way. With this
+ remapping, the consumer node needs to know only about the nexus
+ node. Resources behind the nexus node are decoupled by the nexus node
+ itself.
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+select: true
+
+properties:
+ clock-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+dependentRequired:
+ clock-map: ['#clock-cells']
+
+additionalProperties: true
+
+# See the original pwm-nexus-node.yaml description for examples
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/7] clk: Add support for clock nexus
From: Miquel Raynal (Schneider Electric) @ 2026-07-17 15:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brendan Higgins, David Gow,
Rae Moar
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-kselftest, kunit-dev,
Miquel Raynal (Schneider Electric), Herve Codina
Adding support for clock nexus had some prerequisites requested by
Stephen, such as adding new selftests, the initial discussions come
from:
Link: https://lore.kernel.org/linux-clk/20260129201003.288605-1-miquel.raynal@bootlin.com/
Changes in v4:
- Fixed the kernel doc of of_find_node_by_name_kunit() which was lacking
the fact that it could return NULL upon lookup failure. Also improved
the commit message by mentioning the addition of that helper.
- All other Sashiko reports have either been disregarded because they
were way too unrelated or just not relevant enough in my opinion.
- Link to v3: https://lore.kernel.org/r/20260716-schneider-v7-2-rc1-eip201-upstream-v3-0-98454e83845c@bootlin.com
Changes in v3:
- Prevent out-of-bounds clock-ranges fallback in of_parse_clkspec()
- tests: Check of_clk_add_hw_provider_kunit() return value and fix node
ref leaks
- Link to v2: https://lore.kernel.org/r/20260710-schneider-v7-2-rc1-eip201-upstream-v2-0-b4680787377e@bootlin.com
Changes in v2:
- Collected tags.
- Rebased on top of v7.2-rc1
- Exported (test) clock symbols using the _IF_KUNIT() variant, and
imported the NS in the test file.
- Fixed a leaking node reported by Brian in the tests. Also used
existing helpers to simplify the test implementation as he wisely
suggested.
- Reworded the nexus node binding description as suggested by Stephen.
- Dropped redundant and non restraining properties from the Nexus
node as suggested by Rob.
- Assigned clock/clock-rate properties now traverse Nexus nodes.
- Rename helpers following Stephen proposals.
- Rework tests following Stephen hints.
- Link to v1: https://lore.kernel.org/r/20260327-schneider-v7-0-rc1-crypto-v1-0-5e6ff7853994@bootlin.com
Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
---
Miquel Raynal (Schneider Electric) (7):
dt-bindings: clock: Introduce nexus nodes
clk: tests: Add clk_parse_clkspec() Kunit testing
clk: tests: Add Kunit testing for of_clk_get_parent_name()
clk: Improve a couple of comments
clk: Use the generic OF phandle parsing in only one place
clk: Add support for clock nexus dt bindings
clk: tests: Add Kunit testing for nexus nodes
.../bindings/clock/clock-nexus-node.yaml | 30 +++++
drivers/clk/Makefile | 1 +
drivers/clk/clk-conf.c | 12 +-
drivers/clk/clk.c | 15 ++-
drivers/clk/clk_kunit_helpers.c | 31 +++++
drivers/clk/clk_test.c | 139 +++++++++++++++++++++
drivers/clk/kunit_clk_parse_clkspec.dtso | 31 +++++
include/kunit/clk.h | 2 +
8 files changed, 249 insertions(+), 12 deletions(-)
---
base-commit: 7f26e010764df304602f33912a0550dcf46e72c2
change-id: 20260710-schneider-v7-2-rc1-eip201-upstream-a470e5eab92d
Best regards,
--
Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
^ permalink raw reply
* Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties
From: Conor Dooley @ 2026-07-17 15:55 UTC (permalink / raw)
To: Yu-Chien Peter Lin
Cc: Conor Dooley, devicetree, linux-riscv, linux-kernel, robh,
krzk+dt, conor+dt, pjw, palmer, aou, alex, samuel.holland, dlan,
guodong, dfustini, michal.simek, junhui.liu, darshan.prajapati,
akpm, zhangchunyan, luxu.kernel, pincheng.plct, nick.hu, jim.shu,
zong.li, greentime.hu, robin.randhawa, scott, dave.patel,
raymond.mao, pawandeep.oza
In-Reply-To: <aloGd39fAlev7+4p@plin-1878>
[-- Attachment #1: Type: text/plain, Size: 6250 bytes --]
On Fri, Jul 17, 2026 at 06:39:51PM +0800, Yu-Chien Peter Lin wrote:
> Hi Conor,
>
> On Tue, Jun 30, 2026 at 07:06:14PM +0100, Conor Dooley wrote:
> > On Tue, Jun 30, 2026 at 07:11:26PM +0800, Yu-Chien Peter Lin wrote:
> > > Hi Conor,
> > >
> > > On Fri, Jun 26, 2026 at 03:36:38PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 26, 2026 at 07:47:31PM +0800, Yu-Chien Peter Lin wrote:
> > > > > Hi Conor,
> > > > >
> > > > > On Mon, Jun 22, 2026 at 06:12:47PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> > > > > > > Add per-hart DT properties for RISC-V Worlds architecture:
> > > > > > > riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> > > > > > > platform-defined values are primarily used by M-mode firmware
> > > > > > > to configure World ID CSRs and restrict WID usage across
> > > > > > > privilege levels.
> > > > > > >
> > > > > > > Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> > > > > > > ---
> > > > > > > .../devicetree/bindings/riscv/cpus.yaml | 21 +++++
> > > > > > > .../devicetree/bindings/riscv/worlds.yaml | 77 +++++++++++++++++++
> > > > > > > 2 files changed, 98 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > > > index 5feeb2203050..4b5778b6d3e7 100644
> > > > > > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > > > @@ -26,6 +26,7 @@ description: |
> > > > > > > allOf:
> > > > > > > - $ref: /schemas/cpu.yaml#
> > > > > > > - $ref: extensions.yaml
> > > > > > > + - $ref: worlds.yaml
> > > > > > > - if:
> > > > > > > not:
> > > > > > > properties:
> > > > > > > @@ -120,11 +121,31 @@ properties:
> > > > > > > thead systems where the vector register length is not identical on all harts, or
> > > > > > > the vlenb CSR is not available.
> > > > > > >
> > > > > > > + riscv,pmwid:
> > > > > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > + description:
> > > > > > > + Platform-defined M-mode World ID (WID) assigned to this hart.
> > > > > > > + minimum: 0
> > > > > > > + maximum: 63
> > > > > > > +
> > > > > > > + riscv,pmwidlist:
> > > > > > > + $ref: /schemas/types.yaml#/definitions/uint64
> > > > > > > + description:
> > > > > > > + Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
> > > > > >
> > > > > > I don't understand what the difference is between this property and the
> > > > > > one before it are.
> > > > > > Is this one meant to be used by m-mode software to then select one which
> > > > > > will appear in riscv,pmwid?
> > > > >
> > > > > pmwid (single value) is the reset default, while pmwidlist (bitmap)
> > > > > defines the allowed set. The root-of-trust M-mode software may select
> > > > > an allowed value from the pmwidlist and write it to the mwid CSR.
> > > >
> > > > I don't understand the point of the property then. If it is the reset
> > > > default, just read it out of the register?
> > > > Unless I am missing something, it's useless to s-mode because it may
> > > > not be what m-mode chose and useless to m-mode that has access to
> > > > the csr.
> > >
> > > Smwid is optional. In the no-Smwid case:
> > > - M-mode's WID is fixed to pmwid (hardware-defined via fuse/pinstrap/SoC
> > > registers, exposed to software via riscv,pmwid DT property)
> > > - S/U-mode's WID depends on opensbi-domain configuration [1]:
> > > - If next-wid is specified: S/U use that WID (via mlwid CSR)
> > > - If next-wid is absent : S/U fall back to pmwid (M/S/U in same
> > > world)
> > >
> > > So riscv,pmwid serves two purpose:
> > > 1. Source of truth for M-mode's WID when mwid CSR doesn't exist
> > > 2. Fallback value for OpenSBI to write to mlwid when domain config is
> > > absent.
> >
> > So it is not the default at reset at all then. The reset default is
> > something else entirely and this is used to overwrite that.
> >
> > > - M-mode's WID is fixed to pmwid (hardware-defined via fuse/pinstrap/SoC
> > > registers, exposed to software via riscv,pmwid DT property)
> >
> > In this case, it seems like pmwidlist would just contain a single entry,
> > and there is no need for pwmid.
>
> The pmwid and pmwidlist properties cannot merge because pmwidlist represents
> an optional hardware mask. On physically unrestricted platforms, pmwidlist
> doesn't exist, making pmwid essential to define the hardware reset default.
>
> >
> > Quite frankly, it seems like you need to decouple these properties from
> > being 1:1 mappings to your extension's CSRs and both name and explain
> > how they are to be used by software.
>
> These properties are actually not 1:1 CSR mappings. pmwid, pmwidlist, and
> pmlwidlist are the exact terms used in the RISC-V specification to describe
> these platform-defined hardware values, so I prefer to follow it.
CSRs or terms in your extension, it matters little.
Your properties should reflect how software will actually interact with
the devicetree and wordguard. There's no point having a bunch of
properties that relate to aspects of the extension if software is not
going to actually use them.
I fundamentally do not understand why software ever needs both both the
singular and list properties. What does software actually do with the
list property when both it and the singular property are provided?
I expect to see something simpler and/or much better explained in the next
revision.
> > Again same point applies here, why can a single-entry riscv,pmwidlist
> > not suffice here?
>
> As explained above, a single-entry pmwidlist cannot replace pmwid because
> it would fail to represent the exact hardware reset default for platforms
> without physical WID restrictions.
If there is one entry, use that, and if there are multiple entries, pick
one?
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format
From: Frank Li @ 2026-07-17 15:55 UTC (permalink / raw)
To: sashiko-reviews
Cc: Francesco Dolcini, devicetree, robh, dri-devel, Frank.Li,
conor+dt, imx
In-Reply-To: <20260717122808.693211F000E9@smtp.kernel.org>
On Fri, Jul 17, 2026 at 12:28:07PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Introduction of the legacy, non-standard `interface-pix-fmt` property for a standard hardware concept (parallel bus width), violating modern DT principles.
> --
>
> --- Patch [1]: [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format ---
> commit 7225ea545d2ff50540972dd75d375b8ecea4f315
> Author: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> dt-bindings: lcdif: Add interface pixel format
>
> This commit updates the fsl,lcdif device tree binding to support the
> interface-pix-fmt property. The property is used to describe the hardware's
> parallel data bus transfer width to match board wiring and prevent shifted
> colors.
>
> > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > index 2dd0411ec6516..209ee5a96e393 100644
> > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > @@ -58,6 +58,13 @@ properties:
> > items:
> > - const: rx
> >
> > + interface-pix-fmt:
> > + $ref: /schemas/types.yaml#/definitions/string
> > + enum:
> > + - rgb24
> > + - rgb565
> > + - rgb666
>
> [Severity: Low]
> Is this introducing a legacy, non-standard property into the new schema ABI?
>
> Standard devicetree guidelines usually prefer endpoint properties like
> bus-width (defined in video-interfaces.yaml) to describe physical parallel
> data line configurations, such as setting bus-width = <18> for RGB666.
Make sense, can we use standard property?
Frank
>
> If a custom property is strictly necessary here rather than using the standard
> endpoint properties, does this require a vendor prefix like
> fsl,interface-pix-fmt to comply with modern devicetree naming conventions?
>
> > +
> > interrupts:
> > items:
> > - description: LCDIF DMA interrupt
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260717121847.488148-1-francesco@dolcini.it?part=1
^ permalink raw reply
* Re: [PATCH v3 00/11] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Frank Li @ 2026-07-17 15:53 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
On Fri, Jul 17, 2026 at 03:06:24PM +0300, Ioana Ciornei wrote:
> This patch set adds the device tree nodes for the Lynx10G SerDes blocks
> found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
>
> The first 5 patches slowly change the LX2160A DTS support to a new
> structure which does not use any delete-node or delete-property
> directives. This is a direct result of the discussion with Frank in the
> v2 of this set:
> https://lore.kernel.org/all/akwAmzAbtg0Ejey0@SMW015318/
>
> Patches 5 and 6 transition the LX2160A and LX2162 SoC dtsi to use the
> device-specific Lynx28G SerDes compatible while the remainder of the set
> adds the SerDes block descriptions for the LS1028A, LS1046A, LS2088A and
> LS1088A SoCs.
>
> Changes in v3:
> - Changes how the LX216XA based SoC dtsi files are structured.
> - Split the enabling of serdes_1 into a separate patch
> - Split the LX2162A changes to another patch
> - Move the status property to be the last for serdes_3
> - Move the changes to the new fsl-lx2160a-serdes.dtsi file
Overall look good, let wait for some days for other reviewers.
Frank
>
> Changes in v2:
> - Enable serdes_1 on all board DTs that has consumers for it.
> - Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
> - Remove paragraph from commit message which mentioned some consumer
> changes that are no longer needed nor part of the commit.
> - Change the size of the SerDes region to 0x2000
>
> Ioana Ciornei (8):
> arm64: dts: lx2160a: explicitly enable serdes_1 node
> arm64: dts: lx2160a: extract the PCIe nodes into a separate dtsi
> arm64: dts: lx2160a: extract the SerDes nodes into a separate dtsi
> arm64: dts: lx2160a: extract the PCIe from LX2160A Rev2 into a
> separate file
> arm64: dts: lx2160a: split the dtsi to avoid delete-property
> arm64: dts: lx2160a: transition to device-specific SerDes compatible
> strings
> arm64: dts: lx2162a: transition to device-specific SerDes compatible
> strings
> arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
>
> Vladimir Oltean (3):
> arm64: dts: ls1028a: describe the Lynx 10G SerDes
> arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
> arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
>
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 ++
> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 ++++
> .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 ++++
> .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 +++++++
> .../dts/freescale/fsl-lx2160a-bluebox3.dts | 2 +-
> .../dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +-
> .../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
> .../dts/freescale/fsl-lx2160a-half-twins.dts | 4 +
> .../dts/freescale/fsl-lx2160a-honeycomb.dts | 2 +-
> .../dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi | 176 ++++++++++++
> .../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
> .../boot/dts/freescale/fsl-lx2160a-rev1.dtsi | 9 +
> .../boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 188 +------------
> .../dts/freescale/fsl-lx2160a-serdes.dtsi | 167 ++++++++++++
> .../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 2 +-
> .../dts/freescale/fsl-lx2162a-clearfog.dts | 6 +-
> .../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
> .../dts/freescale/fsl-lx2162a-serdes.dtsi | 86 ++++++
> .../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 9 +
> .../{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} | 181 ------------
> .../dts/freescale/fsl-lx216xa-pcie-gen3.dtsi | 257 ++++++++++++++++++
> 21 files changed, 974 insertions(+), 372 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
> rename arch/arm64/boot/dts/freescale/{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} (86%)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
>
> --
> 2.25.1
>
>
^ permalink raw reply
* Re: [PATCH v5 1/4] clk: sunxi-ng: mux: fix determine helper rate propagation
From: sashiko-bot @ 2026-07-17 15:49 UTC (permalink / raw)
To: Jerome Brunet
Cc: robh, conor+dt, linux-rtc, devicetree, Alexandre Belloni,
linux-sunxi
In-Reply-To: <20260717-a733-rtc-v5-1-3874cc26abf7@baylibre.com>
> Applying the pre divider on the parent rate is wrong because, while
> handling rate propagation through determine_rate(), the framework will
> likely round the parent rate again while cycling through the possibilities,
> throwing away the prediv applied. This means, the parent rate will then
> be wrong when the prediv is unapplied from a parent rate on which it
> was never applied to begin with.
>
> The right way to do it is to unapply the prediv from the requested rate,
> which is the wanted rate at the input on the clock element, and pass this
> to framework to do its thing.
>
> Change the determine rate mux helper in this way.
>
> Fixes: 1c8d7af61b37 ("clk: sunxi-ng: convert from divider_round_rate_parent() to divider_determine_rate()")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com?part=1
^ permalink raw reply
* Re: [PATCH v2 0/4] mtd: rawnand: qcom: Add MDM9607
From: Miquel Raynal @ 2026-07-17 15:48 UTC (permalink / raw)
To: Manivannan Sadhasivam, Stephan Gerhold
Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-mtd, linux-arm-msm,
devicetree, linux-kernel, Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <20260707-qcom-nandc-mdm9607-v2-0-d906f7e8b814@linaro.org>
On Tue, 07 Jul 2026 13:56:00 +0200, Stephan Gerhold wrote:
> MDM9607 has QPIC v1.5 that supports the OP_PAGE_READ_ONFI_READ command, but
> is missing the rest of the hardware changes in QPIC v2. There is also only
> a single clock that can be controlled using the RPM firmware. Document and
> add the new qcom,mdm9607-nand compatible for this setup.
>
>
Applied to nand/next, thanks!
[1/4] dt-bindings: mtd: qcom,nandc: Add MDM9607 QPIC NAND controller
commit: 4529aababe4212b9b6d70e83ceb6a99f9691c811
[2/4] mtd: rawnand: qcom: Make "aon" clock optional
commit: 533ec816312baecdb45bbcb8a279c6561aa71215
[3/4] mtd: rawnand: qcom: Make has_onfi_read_op separate from qpic_version2
commit: 0732595d2f8cf846be3327c8c9453eb10b10ed39
[4/4] mtd: rawnand: qcom: Add MDM9607 compatible
commit: 69e3c504e18bf1fec03fdf6293320860ec832af8
Patche(s) should be available on mtd/linux.git and will be
part of the next PR (provided that no robot complains by then).
Kind regards,
Miquèl
^ permalink raw reply
* Re: [PATCH 0/2] ARM: dts: ls: cleanup fpga related CHECK_DTBS warning
From: Frank.Li @ 2026-07-17 15:48 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Frank.Li
Cc: Frank Li, devicetree, linux-kernel, linux-arm-kernel, imx,
Ioana Ciornei, vladimir.oltean
In-Reply-To: <20260708-ls-fpga-v1-0-06c8a099b2a5@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 08 Jul 2026 14:55:12 -0400, Frank.Li@oss.nxp.com wrote:
> Cleanup oneboard fpga related CHECK_DTBS warning.
Applied, thanks!
[1/2] dt-bindings: fsl,fpga-qixis: Add fsl,ls1021aqds-fpga compatible string
commit: 092d1fad3b2c224e465e4ecc5d7a17f3da3cf1a8
[2/2] ARM: dts: ls1021a-qds: add compatible string "fsl,ls1021aqds-fpga" for on boards FPGA chip
commit: 28228f9ea570a94e1873adda5ee284134af28cd6
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: panel: samsung,atna33xc20: Add ATNA40HQ08-0
From: Doug Anderson @ 2026-07-17 15:40 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Rob Herring, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, dri-devel, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <6e7ae036-e63b-4f83-947c-992f3199dbab@oss.qualcomm.com>
Hi,
On Fri, Jul 17, 2026 at 6:06 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 6/6/26 12:41 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jun 5, 2026 at 10:14 AM Rob Herring <robh@kernel.org> wrote:
>
> [...]
>
> >> Well yes, people have a hard time using compatible strings that don't
> >> sound generic. That's too bad for them.
> >
> > OK, so sounds like going forward I should NAK changes to this file and
> > tell people to just use:
> >
> > compatible = "samsung,atna33xc20";
> >
> > ...to mean "Generic Samsung AMOLED panel with power sequencing that
> > matches atna33xc20"
> >
> > Yes, it means that if we find quirks with a specific panel later, it
> > could possibly be harder to work around them. However, since we have
> > several ways to identify the panel (via EDID and via DDC) this seems
> > fairly low risk. You can't perfectly predict the future anyway.
>
> Are we going forward with this guidance? I have another laptop with
> another ATNAxxx panel (ATNA60HR07-0) that I intend to submit a DT for
> soon
That would be my preference.
-Doug
^ permalink raw reply
* RE: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support
From: Yu-Chun Lin [林祐君] @ 2026-07-17 15:38 UTC (permalink / raw)
To: Andy Shevchenko, Michael Walle
Cc: 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: <alkbVkB5KNNR7ffN@ashevche-desk.local>
Hi,
>
> 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).
Best Regards,
Yu-Chun
> > > 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
* Re: [PATCH v5 4/4] clk: sunxi-ng: sun6i-rtc: add a733 support
From: sashiko-bot @ 2026-07-17 15:40 UTC (permalink / raw)
To: Jerome Brunet
Cc: devicetree, Alexandre Belloni, linux-rtc, robh, linux-sunxi,
conor+dt
In-Reply-To: <20260717-a733-rtc-v5-4-3874cc26abf7@baylibre.com>
> Add support for the sun60i a733 CCU RTC.
>
> Compared to the a523, this SoC has a different input oscillator divider
> which auto-detects the oscillator rate and select a divider to provide
> a fixed 32768Hz clock. It also provides several phy reference clocks
> with dedicated clock gates.
>
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com?part=4
^ permalink raw reply
* Re: [PATCH v5 2/4] clk: sunxi-ng: div: add read-only operation support
From: sashiko-bot @ 2026-07-17 15:40 UTC (permalink / raw)
To: Jerome Brunet
Cc: robh, linux-rtc, conor+dt, devicetree, linux-sunxi,
Alexandre Belloni
In-Reply-To: <20260717-a733-rtc-v5-2-3874cc26abf7@baylibre.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Missing `.set_parent` in `ccu_rodiv_ops` leads to silent software-hardware clock tree desynchronization during reparenting.
Pre-existing issues:
- [High] Unvalidated hardware register read passed to `divider_ro_determine_rate()` can cause a divide-by-zero kernel panic.
--
--- Patch [2]: [PATCH v5 2/4] clk: sunxi-ng: div: add read-only operation support ---
commit d732b1bc291c593bb4873ef5f04edb2855137f30
Author: Jerome Brunet <jbrunet@baylibre.com>
clk: sunxi-ng: div: add read-only operation support
This commit adds support for read-only dividers in the sunxi-ng clock
driver. It introduces a new ccu_rodiv_ops structure and updates the rate
determination helper to handle the read-only flag.
> diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
> index 62d680ccb524b..93cb4cb93abe8 100644
> --- a/drivers/clk/sunxi-ng/ccu_div.c
> +++ b/drivers/clk/sunxi-ng/ccu_div.c
> @@ -20,8 +20,22 @@ static int ccu_div_determine_rate_helper(struct ccu_mux_internal *mux,
> if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
> req->rate *= cd->fixed_post_div;
>
> - ret = divider_determine_rate(&cd->common.hw, req, cd->div.table,
> - cd->div.width, cd->div.flags);
> + if (cd->div.flags & CLK_DIVIDER_READ_ONLY) {
> + unsigned long val;
> + u32 reg;
> +
> + reg = readl(cd->common.base + cd->common.reg);
> + val = reg >> cd->div.shift;
> + val &= (1 << cd->div.width) - 1;
> +
> + ret = divider_ro_determine_rate(&cd->common.hw, req, cd->div.table,
> + cd->div.width, cd->div.flags, val);
[Severity: High]
This is a pre-existing issue, but could this unvalidated register read cause
a divide-by-zero kernel panic?
In ccu_div_determine_rate_helper(), the raw register value is read and
passed as 'val' to divider_ro_determine_rate(). If the register contains
an unexpected value from the bootloader (or 0 when CLK_DIVIDER_ONE_BASED
is set) that _get_div() maps to 0, divider_ro_determine_rate() lacks a
zero-check before calculating:
req->rate = DIV_ROUND_UP_ULL((u64)req->best_parent_rate, div);
> +
> + } else {
[ ... ]
> @@ -143,3 +157,15 @@ const struct clk_ops ccu_div_ops = {
> .set_rate = ccu_div_set_rate,
> };
> EXPORT_SYMBOL_NS_GPL(ccu_div_ops, "SUNXI_CCU");
> +
> +const struct clk_ops ccu_rodiv_ops = {
> + .disable = ccu_div_disable,
> + .enable = ccu_div_enable,
> + .is_enabled = ccu_div_is_enabled,
> +
> + .get_parent = ccu_div_get_parent,
> +
> + .determine_rate = ccu_div_determine_rate,
> + .recalc_rate = ccu_div_recalc_rate,
> +};
[Severity: High]
Could the missing .set_parent callback in ccu_rodiv_ops lead to a silent
desynchronization between the software clock tree and the hardware?
The struct provides reparenting capabilities via .get_parent and
.determine_rate, but omits .set_parent. If a rate request causes
ccu_mux_helper_determine_rate() to evaluate and select a new parent, the
Common Clock Framework will apply this new parent in software but skip
updating the hardware since .set_parent is NULL.
This would leave all downstream clock rate calculations incorrect.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com?part=2
^ permalink raw reply
* Re: [PATCH 0/7] Add reset support to MT6589 wdt and remove fallback compatibles
From: Akari Tsuyukusa @ 2026-07-17 15:38 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel
Cc: open list:WATCHDOG DEVICE DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Roman Vivchar
In-Reply-To: <20260716161923.266315-1-akkun11.open@gmail.com>
On Fri, Jul 17, 2026 at 1:19 AM Akari Tsuyukusa <akkun11.open@gmail.com> wrote:
>
> This series adds TOPRGU reset controller support to the MT6589 watchdog
> and removes the use of "mediatek,mt6589-wdt" as the fallback compatible
> from many other MediaTek SoCs.
>
> Many SoCs have been using "mediatek,mt6589-wdt" as the fallback.
> However, they are not compatible with the MT6589's reset register.
>
> To add reset support to MT6589 wdt and resolve this problem safely,
> the series proceeds step by step:
Better patch series is available
Link: https://lore.kernel.org/linux-mediatek/20260717151134.678839-1-l.scorcia@gmail.com/T/#t
I'm withdrawing this series.
Best regards,
Akari
^ permalink raw reply
* Re: [PATCH 01/42] of: reserved_mem: Introduce devres-managed initialization functions
From: Mukesh Ojha @ 2026-07-17 15:37 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Konrad Dybcio, Liviu Dudau, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Joel Stanley, Andrew Jeffery, Paul Cercueil, Anitha Chrisanthus,
Paul Kocialkowski, Linus Walleij, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Alexey Brodkin, Laurent Pinchart, Tomi Valkeinen,
Michal Simek, Daniel Scally, Jacopo Mondi, Mauro Carvalho Chehab,
Eddie James, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Minghsiu Tsai, Houlong Wei, Matthias Brugger,
AngeloGioacchino Del Regno, Joseph Liu, Marvin Lin,
Dmitry Osipenko, Krzysztof Kozlowski, Thierry Reding,
Jonathan Hunter, Srinivas Kandagatla, Arnd Bergmann,
Greg Kroah-Hartman, Ge Gordon, Adrian Hunter, Ulf Hansson,
Saravana Kannan, Mathieu Poirier, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Liam Girdwood, Mark Brown, Frank Li,
Sascha Hauer, Peter Ujfalusi, Bard Liao, Daniel Baluta,
Orson Zhai, Baolin Wang, Peter Chen, Fugang Duan, Ekansh Gupta,
BST Linux Kernel Upstream Group, Fabio Estevam, Nicolin Chen,
Pengutronix Kernel Team, Kai Vehmanen, Pierre-Louis Bossart,
Vijendar Mukunda, Chunyan Zhang, CIX Linux Kernel Upstream Group,
linux-arm-msm, linux-kernel, dri-devel, linux-aspeed,
linux-arm-kernel, linux-mips, linux-sunxi, linux-media, openbmc,
linux-mediatek, kernel, linux-tegra, linux-mmc, devicetree,
linux-remoteproc, linux-staging, linux-sound, linuxppc-dev, imx,
sound-open-firmware, Konrad Dybcio
In-Reply-To: <20260716200048.GA1183026-robh@kernel.org>
On Thu, Jul 16, 2026 at 03:00:48PM -0500, Rob Herring wrote:
> On Sat, Jul 04, 2026 at 01:08:14AM +0530, Mukesh Ojha wrote:
> > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >
> > Introduce devres-based helpers for of_reserved_mem_device_init(_by_idx)
> > to help fight dangling references and ever so slightly reduce the
> > number of boilerplate deinitialization calls.
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> > drivers/of/of_reserved_mem.c | 41 +++++++++++++++++++++++++++++++++
> > include/linux/of_reserved_mem.h | 25 ++++++++++++++++++++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 82222bd45ac6..b35541e9fbe8 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -787,6 +787,47 @@ void of_reserved_mem_device_release(struct device *dev)
> > }
> > EXPORT_SYMBOL_GPL(of_reserved_mem_device_release);
> >
> > +static void devm_of_reserved_mem_device_release(struct device *dev, void *res)
> > +{
> > + of_reserved_mem_device_release(*(struct device **)res);
> > +}
> > +
> > +/**
> > + * devm_of_reserved_mem_device_init_by_idx() - Resource managed of_reserved_mem_device_init_by_idx()
> > + * @dev: Pointer to the device to configure
> > + * @np: Pointer to the device node with 'memory-region' property
> > + * @idx: Index of selected region
> > + *
> > + * This is a resource managed version of of_reserved_mem_device_init_by_idx().
> > + * The reserved memory region will be released automatically when the device
> > + * is unbound.
> > + *
> > + * Returns: Negative errno on failure or zero on success.
> > + */
> > +int devm_of_reserved_mem_device_init_by_idx(struct device *dev,
> > + struct device_node *np, int idx)
>
> It looks to me like the only 2? users of this could be converted to
> devm_of_reserved_mem_device_init() instead. The mmc one obviously can.
> The imx one depends if np is dev->of_node. I'm not a fan of APIs with
> only a few users.
You are right, mmc can be but imx can't. I can make this static and drop
the API usage from imx but fix the leak by release function.
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx91-9x9-qsb: add CAN support overlay file
From: Frank.Li @ 2026-07-17 15:37 UTC (permalink / raw)
To: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, haibo.chen
Cc: Frank Li, imx, linux-arm-kernel, devicetree, linux-kernel,
Haibo Chen
In-Reply-To: <20260710-dts-imx91-can1-v1-1-c78c9c378e8d@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Fri, 10 Jul 2026 18:12:20 +0800, haibo.chen@oss.nxp.com wrote:
> On the i.MX91 9x9 QSB, CAN1 and MICFIL share pins. A TMUX1574RSVR
> analog mux controls the routing: when SEL is driven high, CAN1 is
> selected; when SEL is driven low, MICFIL is selected. By default,
> SEL is kept low.
>
> To enable CAN1, SEL must be driven high. This is done via the can_fun
> function defined in the pinctrl-gpiomux node. CAN1 uses the
> TJA1057GT/3 PHY.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: imx91-9x9-qsb: add CAN support overlay file
commit: 356894c37aa1f8ab430cef5d69176123b0ec98b3
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: mfd: x-powers,axp152: Document AXP318W
From: Jerome Brunet @ 2026-07-17 15:36 UTC (permalink / raw)
To: sashiko-bot; +Cc: sashiko-reviews, robh, conor+dt, devicetree
In-Reply-To: <20260717144316.7D7371F000E9@smtp.kernel.org>
On ven. 17 juil. 2026 at 14:43, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] The `x-powers,axp318w` compatible string was omitted from the conditional block that exempts similar PMIC generations from strictly requiring the `interrupts` property.
> - [Medium] The regex pattern for regulator nodes allows non-existent switched output nodes (`swout3` through `swout9`) to silently pass validation.
> --
>
> --- Patch [1]: [PATCH v4 1/5] dt-bindings: mfd: x-powers,axp152: Document AXP318W ---
> commit 08577b06937ca6f13b4a7f204e7f0abb6042c44d
> Author: Andre Przywara <andre.przywara@arm.com>
>
> dt-bindings: mfd: x-powers,axp152: Document AXP318W
>
> The X-Powers AXP318W is a PMIC used on some newer Allwinner devices.
> This patch adds the new compatible string, updates the PWM frequency
> property list, adds input supply properties, and updates the pattern
> for matching switched outputs.
>
>> diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
>> index 45f015d63df16..95b3984fe0f96 100644
>> --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
>> +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
>> @@ -83,6 +83,7 @@ allOf:
>> contains:
>> enum:
>> - x-powers,axp313a
>> + - x-powers,axp318w
>> - x-powers,axp323
>
> [Severity: Medium]
> Should x-powers,axp318w also be added to the earlier conditional block that
> exempts PMICs from requiring the interrupts property?
>
> There is another allOf block in this binding that forces interrupts to be
> required for all devices except a few specific generations:
>
> - if:
> not:
> properties:
> compatible:
> contains:
> enum:
> - x-powers,axp15060
> - x-powers,axp305
> - x-powers,axp313a
> - x-powers,axp323
> then:
> required:
> - interrupts
>
> Since the AXP318W shares constraints with siblings like axp313a and axp323,
> will omitting it from that exemption block cause valid device trees without
> an interrupts property to erroneously fail validation?
No, irq should not be omitted
>
> [ ... ]
>
>> @@ -277,7 +303,7 @@ properties:
>> Defines the work frequency of DC-DC in kHz.
>>
>> patternProperties:
>> - "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
>> + "^(([a-f])?ldo[0-9]|dcdc[0-9a-e]|ldo(_|-)io(0|1)|(dc1)?sw|swout[1-9]|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
>
> [Severity: Medium]
> Could the swout[1-9] pattern allow invalid switched output nodes to silently
> pass validation?
>
> The commit message notes that the PMIC features exactly two switched outputs,
> swout1 and swout2. Allowing swout[1-9] might let device trees with invalid
> nodes or typos like swout3 pass schema validation incorrectly. Would a tighter
> pattern like swout[1-2] be more appropriate here?
It is like that since v1 and has been acked.
It has been loose since forever so if it is an issue, it is defenitely
nothing introduced by this change. Making it strict would require a
different (crazy) regex for each chip.
--
Jerome
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
From: sashiko-bot @ 2026-07-17 15:33 UTC (permalink / raw)
To: Jerome Brunet
Cc: Alexandre Belloni, linux-sunxi, conor+dt, devicetree, robh,
linux-rtc
In-Reply-To: <20260717-a733-rtc-v5-3-3874cc26abf7@baylibre.com>
> On the a733 the "osc24M-32k" clock has the same gate bits as the previously
> supported SoC but a different divider implementation.
>
> Instead of a fixed 750 divider, the divider is selected based on the
> rate of the oscillator. It can be seen as a simple read-only divider.
>
> On the A733 the gate and the divider are on different register which is
> not supported by sunxi combined clocks. These element will be split on the
> A733. Split them for the older SoC as well to keep on sharing the gate
> definition.
>
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com?part=3
^ permalink raw reply
* Re: [PATCH v6 0/3] Add support for Variscite VAR-SOM-MX8QM and Symphony board
From: Frank.Li @ 2026-07-17 15:32 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, Daniel Baluta,
Josua Mayer, Alexander Stein, Ernest Van Hoecke, Maud Spierings,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1784284092.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Fri, 17 Jul 2026 12:29:36 +0200, Stefano Radaelli wrote:
> This patch series adds support for the Variscite VAR-SOM-MX8 QuadMax
> system on module and the Symphony carrier board.
>
> The series includes:
> - SOM device tree with on-module peripherals
> - Symphony carrier board device tree with board-specific features
>
> [...]
Applied, thanks!
[1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards
commit: 4a3f4d08f53242dd6524285fd37c01886aacd0bc
[2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax
commit: 868ced4df4ef1169802c400a685820f2f1fc059b
[3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board
commit: a40fdbf706cc643671e41b9ac2f9ec3a832e769e
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 7/7] soc: mediatek: mtk-mmsys: Add resets for mt8167
From: sashiko-bot @ 2026-07-17 15:30 UTC (permalink / raw)
To: Luca Leonardo Scorcia; +Cc: linux-watchdog, devicetree, robh, conor+dt
In-Reply-To: <20260717151134.678839-8-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing array mapping for MT8167_MMSYS_SW0_RST_B_MIPI_TX_CONFIG (ID 24) causes it to default to 0, unintentionally aliasing to and resetting the SMI_COMMON block.
--
--- Patch [7]: [PATCH 7/7] soc: mediatek: mtk-mmsys: Add resets for mt8167 ---
commit c0225a0e854c0cfee4ad1db37b9fac3a7690abdd
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
soc: mediatek: mtk-mmsys: Add resets for mt8167
This commit adds 64 MMSYS resets for the MT8167 SoC, spanning two contiguous
32-bit registers (SW0 and SW1).
> diff --git a/drivers/soc/mediatek/mt8167-mmsys.h b/drivers/soc/mediatek/mt8167-mmsys.h
> index eef14083c47b5..b8f38ff8cf443 100644
> --- a/drivers/soc/mediatek/mt8167-mmsys.h
> +++ b/drivers/soc/mediatek/mt8167-mmsys.h
[ ... ]
> +/* MMSYS resets */
> +static const u8 mmsys_mt8167_rst_tb[] = {
> + [MT8167_MMSYS_SW0_RST_B_SMI_COMMON] = MMSYS_RST_NR(0, 0),
> + [MT8167_MMSYS_SW0_RST_B_SMI_LARB0] = MMSYS_RST_NR(0, 1),
[ ... ]
> + [MT8167_MMSYS_SW0_RST_B_DSI0] = MMSYS_RST_NR(0, 22),
> + [MT8167_MMSYS_SW0_RST_B_DPI0] = MMSYS_RST_NR(0, 23),
> + /* bit 24 is SMI_COMMON again according to data sheet */
> + /* bit 25 is SMI_LARB0 again according to data sheet */
> + /* all other bits are not described in data sheet */
> + [MT8167_MMSYS_SW1_RST_B_LVDS_ENCODER] = MMSYS_RST_NR(1, 2),
> + [MT8167_MMSYS_SW1_RST_B_DPI1] = MMSYS_RST_NR(1, 3),
> + [MT8167_MMSYS_SW1_RST_B_HDMI] = MMSYS_RST_NR(1, 4),
> +};
[Severity: High]
Does this array omit the mapping for MT8167_MMSYS_SW0_RST_B_MIPI_TX_CONFIG
(ID 24)?
Because index 24 is unmapped in this array, it will default to 0. When a
driver requests a reset for the MIPI TX config ID, mtk_mmsys_reset_update()
will look up index 24 and retrieve 0, which directly maps to
MMSYS_RST_NR(0, 0) (the SMI_COMMON block).
Can this omission cause the SMI_COMMON block to be unintentionally reset
instead, potentially disrupting the multimedia subsystem's memory transactions?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717151134.678839-1-l.scorcia@gmail.com?part=7
^ permalink raw reply
* [PATCH v5 4/4] clk: sunxi-ng: sun6i-rtc: add a733 support
From: Jerome Brunet @ 2026-07-17 15:24 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com>
Add support for the sun60i a733 CCU RTC.
Compared to the a523, this SoC has a different input oscillator divider
which auto-detects the oscillator rate and select a divider to provide
a fixed 32768Hz clock. It also provides several phy reference clocks
with dedicated clock gates.
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 77 ++++++++++++++++++++++++++++++++++--
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 2 +-
2 files changed, 75 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index 25dd87e78eb7..98ae10307f43 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -44,9 +44,15 @@
#define DCXO_CTRL_REG 0x160
#define DCXO_CTRL_CLK16M_RC_EN BIT(0)
+#define DCXO_GATING_REG 0x16c
+
+#define CLK_NUMBER_NO_GATES (CLK_OSC24M_32K_DIV + 1)
+
struct sun6i_rtc_match_data {
bool have_ext_osc32k : 1;
bool have_iosc_calibration : 1;
+ bool have_dcxo_status : 1;
+ bool have_phy_ref_gates : 1;
bool rtc_32k_single_parent : 1;
const struct clk_parent_data *osc32k_fanout_parents;
u8 osc32k_fanout_nparents;
@@ -213,7 +219,12 @@ static struct ccu_mux osc32k_clk = {
},
};
-/* This falls back to the global name for fwnodes without a named reference. */
+/*
+ * This falls back to the global name for fwnodes without a named reference.
+ * NOTE: osc24M name might be misleading the oscillator could also be a 26MHz
+ * or a 19.2MHz one starting with the a733. The original name is kept anyway
+ * in case anything is relying on it.
+ */
static const struct clk_parent_data osc24M[] = {
{ .fw_name = "hosc", .name = "osc24M" }
};
@@ -227,8 +238,30 @@ static struct clk_fixed_factor osc24M_32k_div_clk = {
0),
};
-static SUNXI_CCU_GATE_HW(osc24M_32k_clk, "osc24M-32k", &osc24M_32k_div_clk.hw,
- LOSC_OUT_GATING_REG, BIT(16), 0);
+static struct clk_div_table osc24M_32k_div_a733_table[] = {
+ { .val = 0, .div = 732 },
+ { .val = 1, .div = 586 },
+ { .val = 2, .div = 793 },
+ { .val = 3, .div = 732 },
+ { /* Sentinel */ },
+};
+
+static struct ccu_div osc24M_32k_div_a733_clk = {
+ .enable = BIT(1),
+ .div = _SUNXI_CCU_DIV_TABLE_FLAGS(14, 2,
+ osc24M_32k_div_a733_table,
+ CLK_DIVIDER_READ_ONLY),
+ .common = {
+ .reg = DCXO_CTRL_REG,
+ .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
+ osc24M,
+ &ccu_rodiv_ops,
+ 0),
+ },
+};
+
+static SUNXI_CCU_GATE(osc24M_32k_clk, "osc24M-32k", "osc24M-32k-div",
+ LOSC_OUT_GATING_REG, BIT(16), 0);
static const struct clk_hw *rtc_32k_parents[] = {
&osc32k_clk.common.hw,
@@ -267,6 +300,15 @@ static struct ccu_mux osc32k_fanout_clk = {
},
};
+static SUNXI_CCU_GATE_FW(hosc_serdes1_clk, "hosc-serdes1", "hosc",
+ DCXO_GATING_REG, BIT(5), 0);
+static SUNXI_CCU_GATE_FW(hosc_serdes0_clk, "hosc-serdes0", "hosc",
+ DCXO_GATING_REG, BIT(4), 0);
+static SUNXI_CCU_GATE_FW(hosc_hdmi_clk, "hosc-hdmi", "hosc",
+ DCXO_GATING_REG, BIT(1), 0);
+static SUNXI_CCU_GATE_FW(hosc_ufs_clk, "hosc-ufs", "hosc",
+ DCXO_GATING_REG, BIT(0), 0);
+
static struct ccu_common *sun6i_rtc_ccu_clks[] = {
&iosc_clk,
&iosc_32k_clk,
@@ -275,6 +317,11 @@ static struct ccu_common *sun6i_rtc_ccu_clks[] = {
&osc24M_32k_clk.common,
&rtc_32k_clk.common,
&osc32k_fanout_clk.common,
+ &osc24M_32k_div_a733_clk.common,
+ &hosc_serdes1_clk.common,
+ &hosc_serdes0_clk.common,
+ &hosc_hdmi_clk.common,
+ &hosc_ufs_clk.common,
};
static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
@@ -288,6 +335,10 @@ static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
[CLK_OSC24M_32K] = &osc24M_32k_clk.common.hw,
[CLK_RTC_32K] = &rtc_32k_clk.common.hw,
[CLK_OSC24M_32K_DIV] = &osc24M_32k_div_clk.hw,
+ [CLK_HOSC_UFS] = &hosc_ufs_clk.common.hw,
+ [CLK_HOSC_HDMI] = &hosc_hdmi_clk.common.hw,
+ [CLK_HOSC_SERDES0] = &hosc_serdes0_clk.common.hw,
+ [CLK_HOSC_SERDES1] = &hosc_serdes1_clk.common.hw,
},
};
@@ -330,6 +381,15 @@ static const struct sun6i_rtc_match_data sun55i_a523_rtc_ccu_data = {
.osc32k_fanout_nparents = ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
};
+static const struct sun6i_rtc_match_data sun60i_a733_rtc_ccu_data = {
+ .have_ext_osc32k = true,
+ .have_iosc_calibration = true,
+ .have_dcxo_status = true,
+ .have_phy_ref_gates = true,
+ .osc32k_fanout_parents = sun50i_r329_osc32k_fanout_parents,
+ .osc32k_fanout_nparents = ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
+};
+
static const struct of_device_id sun6i_rtc_ccu_match[] = {
{
.compatible = "allwinner,sun50i-h616-rtc",
@@ -343,6 +403,10 @@ static const struct of_device_id sun6i_rtc_ccu_match[] = {
.compatible = "allwinner,sun55i-a523-rtc",
.data = &sun55i_a523_rtc_ccu_data,
},
+ {
+ .compatible = "allwinner,sun60i-a733-rtc",
+ .data = &sun60i_a733_rtc_ccu_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
@@ -375,6 +439,13 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
osc32k_fanout_init_data.parent_data = data->osc32k_fanout_parents;
osc32k_fanout_init_data.num_parents = data->osc32k_fanout_nparents;
+ if (data->have_dcxo_status)
+ sun6i_rtc_ccu_hw_clks.hws[CLK_OSC24M_32K_DIV] =
+ &osc24M_32k_div_a733_clk.common.hw;
+
+ if (!data->have_phy_ref_gates)
+ sun6i_rtc_ccu_hw_clks.num = CLK_NUMBER_NO_GATES;
+
return devm_sunxi_ccu_probe(dev, reg, &sun6i_rtc_ccu_desc);
}
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
index ab7b92b47f59..4f4f4cb00f1d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
@@ -11,6 +11,6 @@
#define CLK_RTC_32K 6
#define CLK_OSC24M_32K_DIV 7
-#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
+#define CLK_NUMBER (CLK_HOSC_SERDES1 + 1)
#endif /* _CCU_SUN6I_RTC_H */
--
2.47.3
^ permalink raw reply related
* [PATCH v5 3/4] clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
From: Jerome Brunet @ 2026-07-17 15:24 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com>
On the a733 the "osc24M-32k" clock has the same gate bits as the previously
supported SoC but a different divider implementation.
Instead of a fixed 750 divider, the divider is selected based on the
rate of the oscillator. It can be seen as a simple read-only divider.
On the A733 the gate and the divider are on different register which is
not supported by sunxi combined clocks. These element will be split on the
A733. Split them for the older SoC as well to keep on sharing the gate
definition.
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 20 +++++++++++---------
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 3 ++-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index b24c8b196e66..25dd87e78eb7 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -218,17 +218,18 @@ static const struct clk_parent_data osc24M[] = {
{ .fw_name = "hosc", .name = "osc24M" }
};
-static struct ccu_gate osc24M_32k_clk = {
- .enable = BIT(16),
- .common = {
- .reg = LOSC_OUT_GATING_REG,
- .prediv = 750,
- .features = CCU_FEATURE_ALL_PREDIV,
- .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k", osc24M,
- &ccu_gate_ops, 0),
- },
+static struct clk_fixed_factor osc24M_32k_div_clk = {
+ .mult = 1,
+ .div = 750,
+ .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
+ osc24M,
+ &clk_fixed_factor_ops,
+ 0),
};
+static SUNXI_CCU_GATE_HW(osc24M_32k_clk, "osc24M-32k", &osc24M_32k_div_clk.hw,
+ LOSC_OUT_GATING_REG, BIT(16), 0);
+
static const struct clk_hw *rtc_32k_parents[] = {
&osc32k_clk.common.hw,
&osc24M_32k_clk.common.hw
@@ -286,6 +287,7 @@ static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
[CLK_EXT_OSC32K_GATE] = &ext_osc32k_gate_clk.common.hw,
[CLK_OSC24M_32K] = &osc24M_32k_clk.common.hw,
[CLK_RTC_32K] = &rtc_32k_clk.common.hw,
+ [CLK_OSC24M_32K_DIV] = &osc24M_32k_div_clk.hw,
},
};
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
index 9ae821fc2599..ab7b92b47f59 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
@@ -9,7 +9,8 @@
#define CLK_EXT_OSC32K_GATE 4
#define CLK_OSC24M_32K 5
#define CLK_RTC_32K 6
+#define CLK_OSC24M_32K_DIV 7
-#define CLK_NUMBER (CLK_RTC_32K + 1)
+#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
#endif /* _CCU_SUN6I_RTC_H */
--
2.47.3
^ permalink raw reply related
* [PATCH v5 2/4] clk: sunxi-ng: div: add read-only operation support
From: Jerome Brunet @ 2026-07-17 15:24 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260717-a733-rtc-v5-0-3874cc26abf7@baylibre.com>
Add support for sunxi-ng read-only dividers. This will be
useful to the a733 oscillator detection logic.
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu_div.c | 30 ++++++++++++++++++++++++++++--
drivers/clk/sunxi-ng/ccu_div.h | 1 +
drivers/clk/sunxi-ng/ccu_mux.c | 2 +-
drivers/clk/sunxi-ng/ccu_mux.h | 4 ++++
4 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 62d680ccb524..93cb4cb93abe 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -20,8 +20,22 @@ static int ccu_div_determine_rate_helper(struct ccu_mux_internal *mux,
if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
req->rate *= cd->fixed_post_div;
- ret = divider_determine_rate(&cd->common.hw, req, cd->div.table,
- cd->div.width, cd->div.flags);
+ if (cd->div.flags & CLK_DIVIDER_READ_ONLY) {
+ unsigned long val;
+ u32 reg;
+
+ reg = readl(cd->common.base + cd->common.reg);
+ val = reg >> cd->div.shift;
+ val &= (1 << cd->div.width) - 1;
+
+ ret = divider_ro_determine_rate(&cd->common.hw, req, cd->div.table,
+ cd->div.width, cd->div.flags, val);
+
+ } else {
+ ret = divider_determine_rate(&cd->common.hw, req, cd->div.table,
+ cd->div.width, cd->div.flags);
+ }
+
if (ret)
return ret;
@@ -143,3 +157,15 @@ const struct clk_ops ccu_div_ops = {
.set_rate = ccu_div_set_rate,
};
EXPORT_SYMBOL_NS_GPL(ccu_div_ops, "SUNXI_CCU");
+
+const struct clk_ops ccu_rodiv_ops = {
+ .disable = ccu_div_disable,
+ .enable = ccu_div_enable,
+ .is_enabled = ccu_div_is_enabled,
+
+ .get_parent = ccu_div_get_parent,
+
+ .determine_rate = ccu_div_determine_rate,
+ .recalc_rate = ccu_div_recalc_rate,
+};
+EXPORT_SYMBOL_NS_GPL(ccu_rodiv_ops, "SUNXI_CCU");
diff --git a/drivers/clk/sunxi-ng/ccu_div.h b/drivers/clk/sunxi-ng/ccu_div.h
index be00b3277e97..a30a92780a05 100644
--- a/drivers/clk/sunxi-ng/ccu_div.h
+++ b/drivers/clk/sunxi-ng/ccu_div.h
@@ -300,5 +300,6 @@ static inline struct ccu_div *hw_to_ccu_div(struct clk_hw *hw)
}
extern const struct clk_ops ccu_div_ops;
+extern const struct clk_ops ccu_rodiv_ops;
#endif /* _CCU_DIV_H_ */
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 75ec3457324c..905570375711 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -67,7 +67,7 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
}
-static unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
struct ccu_mux_internal *cm,
int parent_index,
unsigned long parent_rate)
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index c94a4bde5d01..272a2c36a8f2 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -134,6 +134,10 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
struct ccu_mux_internal *cm,
int parent_index,
unsigned long parent_rate);
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+ struct ccu_mux_internal *cm,
+ int parent_index,
+ unsigned long parent_rate);
int ccu_mux_helper_determine_rate(struct ccu_common *common,
struct ccu_mux_internal *cm,
struct clk_rate_request *req,
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs
From: sashiko-bot @ 2026-07-17 15:25 UTC (permalink / raw)
To: Luca Leonardo Scorcia; +Cc: linux-watchdog, devicetree, conor+dt, robh
In-Reply-To: <20260717151134.678839-2-l.scorcia@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The watchdog binding schema is not updated to require `#reset-cells` for the MT6589 watchdog after it gained reset provider capabilities.
--
--- Patch [1]: [PATCH 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs ---
commit 8e7eeaa8443a5e5f9043d85f10bedf8f05afe2b3
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
dt-bindings: reset: Add MT6589 toprgu reset IDs
This commit adds a new header file defining reset IDs for the 12 MT6589 toprgu
resets.
> 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
[Severity: Low]
Does the MT6589 watchdog binding schema in
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml also need an
update to require the #reset-cells property?
Since the MT6589 watchdog is gaining reset provider capabilities with these
constants, device tree nodes omitting #reset-cells might incorrectly pass
schema validation unless an if-then block is added to the watchdog schema to
enforce it.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717151134.678839-1-l.scorcia@gmail.com?part=1
^ 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