* Re: [PATCH 2/2] mmc: core: Add post-power-off-delay-ms support
From: sashiko-bot @ 2026-07-16 23:37 UTC (permalink / raw)
To: Judith Mendez; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260716232641.2659710-3-jm@ti.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `post-power-off-delay-ms` hardware constraint is only enforced in `mmc_power_cycle()`, leaving decoupled power-off/power-on sequences vulnerable to hardware timing violations.
- [Low] Explicitly configuring a 0 ms post-power-off delay in the device tree is ignored, falling back to the 1 ms default.
--
--- Patch [2]: [PATCH 2/2] mmc: core: Add post-power-off-delay-ms support ---
commit 36ce7de56b9b7e7608c56353aede4cb3de73df5b
Author: Judith Mendez <jm@ti.com>
mmc: core: Add post-power-off-delay-ms support
This commit adds support for post-power-off-delay-ms, allowing a
configurable delay after an MMC power off.
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 29e80e5f928e9..f9049aaf44394 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1394,8 +1394,12 @@ void mmc_power_off(struct mmc_host *host)
> void mmc_power_cycle(struct mmc_host *host, u32 ocr)
> {
> mmc_power_off(host);
> - /* Wait at least 1 ms according to SD spec */
> - mmc_delay(1);
> + if (host->post_power_off_delay_ms) {
> + mmc_delay(host->post_power_off_delay_ms);
> + } else {
> + /* Wait at least 1 ms according to SD spec */
> + mmc_delay(1);
> + }
[Severity: Medium]
Will this delay be missed for decoupled power-off and power-on sequences?
If a device relies on post-power-off-delay-ms (e.g., 100ms) but goes through a
runtime PM suspend or system suspend, mmc_power_off() will be called, followed
later by mmc_power_up(). Because the delay is only enforced here in
mmc_power_cycle(), will the decoupled off/on path violate the power-off time
constraint?
Could mmc_power_off() record a timestamp, and mmc_power_up() calculate the
elapsed time to only delay the remaining required duration?
[Severity: Low]
Does this ignore an explicitly configured 0 ms delay?
If a developer explicitly specifies post-power-off-delay-ms = <0> in the
device tree, this condition will evaluate to false and unexpectedly fall
back to the 1 ms default.
Could this be resolved by initializing the default value in mmc_alloc_host()
and removing the if/else condition here?
> mmc_power_up(host, ocr);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716232641.2659710-1-jm@ti.com?part=2
^ permalink raw reply
* [PATCH 0/2] mmc: Add post-power-off-delay-ms support
From: Judith Mendez @ 2026-07-16 23:26 UTC (permalink / raw)
To: Judith Mendez, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-mmc, devicetree, linux-kernel
This series adds post-power-off-delay-ms support for MMC controllers,
enabling boards to specify custom delays after MMC power off to work around
hardware issues such as slow RC circuites on MMC VDD rails.
Rather than adding host driver-specific workarounds, we abstract the
implementation into the MMC core and pickup the delay value with a device
tree property (post-power-off-delay-ms). This allows any board with slow
power off requirements to configure the necessary delay without code
changes.
Requesting comments for how big the delay should be maxed at, currently
it is set to 10000ms, but not sure if this is too high.
The solution is minimal and follows existing patterns as with
(post-power-on-delay-ms).
Judith Mendez (2):
dt-bindings: mmc: Add post-power-off-delay-ms property
mmc: core: Add post-power-off-delay-ms support
.../devicetree/bindings/mmc/mmc-controller-common.yaml | 8 ++++++++
drivers/mmc/core/core.c | 8 ++++++--
drivers/mmc/core/host.c | 8 ++++++++
include/linux/mmc/host.h | 1 +
4 files changed, 23 insertions(+), 2 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH 2/2] mmc: core: Add post-power-off-delay-ms support
From: Judith Mendez @ 2026-07-16 23:26 UTC (permalink / raw)
To: Judith Mendez, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <20260716232641.2659710-1-jm@ti.com>
Add support for post-power-off-delay-ms which shall be used to insert
a configurable delay post MMC power off.
Signed-off-by: Judith Mendez <jm@ti.com>
---
drivers/mmc/core/core.c | 8 ++++++--
drivers/mmc/core/host.c | 8 ++++++++
include/linux/mmc/host.h | 1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 29e80e5f928e9..f9049aaf44394 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1394,8 +1394,12 @@ void mmc_power_off(struct mmc_host *host)
void mmc_power_cycle(struct mmc_host *host, u32 ocr)
{
mmc_power_off(host);
- /* Wait at least 1 ms according to SD spec */
- mmc_delay(1);
+ if (host->post_power_off_delay_ms) {
+ mmc_delay(host->post_power_off_delay_ms);
+ } else {
+ /* Wait at least 1 ms according to SD spec */
+ mmc_delay(1);
+ }
mmc_power_up(host, ocr);
}
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index b7ce3137d4529..ea8f36827e41c 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -421,6 +421,14 @@ int mmc_of_parse(struct mmc_host *host)
device_property_read_u32(dev, "post-power-on-delay-ms",
&host->ios.power_delay_ms);
+ device_property_read_u32(dev, "post-power-off-delay-ms",
+ &host->post_power_off_delay_ms);
+ if (host->post_power_off_delay_ms > 10000) {
+ dev_err(dev, "post-power-off-delay-ms %u exceeds max 10000, setting 10000\n",
+ host->post_power_off_delay_ms);
+ host->post_power_off_delay_ms = 10000;
+ }
+
return mmc_pwrseq_alloc(host);
}
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba84f02c2a101..b751b61b1116e 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -578,6 +578,7 @@ struct mmc_host {
u32 err_stats[MMC_ERR_MAX];
u32 max_sd_hs_hz;
+ u32 post_power_off_delay_ms;
unsigned long private[] ____cacheline_aligned;
};
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: mmc: Add post-power-off-delay-ms property
From: Judith Mendez @ 2026-07-16 23:26 UTC (permalink / raw)
To: Judith Mendez, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <20260716232641.2659710-1-jm@ti.com>
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.
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:
+ description:
+ The presence of this property indicates that the card requires a
+ delay (in milliseconds) after power off before the next power on.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 10000
+
supports-cqe:
$ref: /schemas/types.yaml#/definitions/flag
description:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 0/4] hwmon: (adt7470) Add thermal framework support
From: Luiz Angelo Daros de Luca @ 2026-07-16 23:19 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-hwmon,
devicetree, linux-kernel
In-Reply-To: <37ce18e8-d505-415f-8e01-0212840aba8a@roeck-us.net>
> This chip is 20+ years old, and it is very unlikely that it is used
> in current designs. Please provide evidence that this code is actually
> needed and not just a coding exercise.
I understand. It is used in multiple Edgecore switches like ECS2100.
I'm preparing a port to OpenWrt.
https://github.com/luizluca/openwrt/commits/ecs2110/
https://forum.openwrt.org/t/add-support-for-edgecore-ecs2100-ecs4100-switches/251818/10
Regards,
Luiz
^ permalink raw reply
* Re: [PATCH 0/4] hwmon: (adt7470) Add thermal framework support
From: Guenter Roeck @ 2026-07-16 23:14 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel
In-Reply-To: <20260716-adt7470_thermalzone-v1-0-cc55ef35edde@gmail.com>
On 7/16/26 14:21, Luiz Angelo Daros de Luca wrote:
> The ADT7470 is a temperature monitor and PWM fan controller capable of
> monitoring up to 10 external temperature sensors and controlling up to 4
> PWM outputs.
>
> Currently, the driver exposes these sensors and PWM controls solely via
> the standard hwmon sysfs interface. This patch series integrates the
> ADT7470 driver with the kernel's thermal subsystem, allowing its
> temperature sensors to be referenced by Device Tree thermal zones.
>
> To avoid saturating the I2C bus during frequent polling by the thermal
> core, the thermal callbacks are designed to read from the driver's
> internal cache.
>
> Patch 1 adds the YAML device tree binding documentation, defining
> the necessary #cooling-cells and #thermal-sensor-cells properties.
> Patch 2 performs a minor refactoring to introduce the ADT7470_PWM_MAX
> macro, replacing hardcoded values.
> Patch 3 registers the 4 PWM channels as optional thermal cooling
> devices.
> Patch 4 registers the external temperature sensors as optional thermal
> zones.
>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
This chip is 20+ years old, and it is very unlikely that it is used
in current designs. Please provide evidence that this code is actually
needed and not just a coding exercise.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 4/4] hwmon: (adt7470) Add thermal zone sensor support
From: Guenter Roeck @ 2026-07-16 23:12 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel
In-Reply-To: <20260716-adt7470_thermalzone-v1-4-cc55ef35edde@gmail.com>
On 7/16/26 14:21, Luiz Angelo Daros de Luca wrote:
> Expose the ADT7470 external temperature sensors to the thermal framework
> via Device Tree. The thermal callbacks use the driver's cached sensor data,
> avoiding any I2C bus traffic during frequent polling by the thermal core.
>
Detailed explanation why HWMON_C_REGISTER_TZ does not work or is
insufficient goes here and into the driver code as comment.
Thanks,
Guenter
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
> ---
> drivers/hwmon/adt7470.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
> index b865f4bd50f8..44fe310f0650 100644
> --- a/drivers/hwmon/adt7470.c
> +++ b/drivers/hwmon/adt7470.c
> @@ -150,6 +150,11 @@ struct adt7470_cooling_device {
> int pwm_index;
> };
>
> +struct adt7470_thermal_sensor {
> + struct adt7470_data *data;
> + int id;
> +};
> +
> struct adt7470_data {
> struct regmap *regmap;
> struct mutex lock;
> @@ -181,6 +186,7 @@ struct adt7470_data {
> unsigned int auto_update_interval;
>
> struct adt7470_cooling_device cooling_devices[ADT7470_PWM_COUNT];
> + struct adt7470_thermal_sensor thermal_sensors[ADT7470_TEMP_COUNT];
> };
>
> /*
> @@ -957,6 +963,47 @@ static int adt7470_register_cooling_devices(struct device *dev,
> return 0;
> }
>
> +static int adt7470_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> + struct adt7470_thermal_sensor *sensor = thermal_zone_device_priv(tz);
> + struct adt7470_data *data = sensor->data;
> +
> + mutex_lock(&data->lock);
> + *temp = 1000 * data->temp[sensor->id];
> + mutex_unlock(&data->lock);
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_device_ops adt7470_thermal_ops = {
> + .get_temp = adt7470_get_temp,
> +};
> +
> +static int adt7470_register_thermal_sensors(struct device *dev,
> + struct adt7470_data *data)
> +{
> + int i;
> +
> + for (i = 0; i < ADT7470_TEMP_COUNT; i++) {
> + struct thermal_zone_device *tz;
> +
> + data->thermal_sensors[i].data = data;
> + data->thermal_sensors[i].id = i;
> +
> + tz = devm_thermal_of_zone_register(dev, i, &data->thermal_sensors[i],
> + &adt7470_thermal_ops);
> + if (IS_ERR(tz)) {
> + if (PTR_ERR(tz) == -ENODEV)
> + continue;
> + return dev_warn_probe(dev, PTR_ERR(tz),
> + "failed to register thermal zone %d\n",
> + i);
> + }
> + }
> +
> + return 0;
> +}
> +
> static ssize_t pwm_max_show(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> @@ -1401,6 +1448,10 @@ static int adt7470_probe(struct i2c_client *client)
> err = adt7470_register_cooling_devices(dev, data);
> if (err)
> return err;
> +
> + err = adt7470_register_thermal_sensors(dev, data);
> + if (err)
> + return err;
> }
>
> data->auto_update = kthread_run(adt7470_update_thread, client, "%s",
>
^ permalink raw reply
* Re: [PATCH v2 2/2] media: synopsys: hdmirx: add HDMI audio capture support
From: Dmitry Osipenko @ 2026-07-16 23:08 UTC (permalink / raw)
To: Igor Paunovic, Mauro Carvalho Chehab
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-media, kernel, devicetree, linux-kernel
In-Reply-To: <20260715200834.8486-3-royalnet026@gmail.com>
15.07.2026 23:08, Igor Paunovic пишет:
> @@ -2788,6 +3058,16 @@ static void hdmirx_remove(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct snps_hdmirx_dev *hdmirx_dev = dev_get_drvdata(dev);
>
> + /*
> + * Clear the streaming flag first so a running worker cannot re-arm
> + * itself, then tear down the codec (which stops any active stream)
> + * before the final cancel.
> + */
> + WRITE_ONCE(hdmirx_dev->audio_streaming, false);
> + if (hdmirx_dev->audio_pdev)
> + platform_device_unregister(hdmirx_dev->audio_pdev);
> + cancel_delayed_work_sync(&hdmirx_dev->audio_work);
> +
Audio capture should be stopped when the codec removed and
hdmirx_audio_shutdown() stops the audio_work. The v1 was good here,
Sashiko bot should be wrong.
I'd like to see rest of the patches (I2S and etc) to test this patch
before giving ack.
--
Best regards,
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: nvidia,tegra234-mgbe: Add missing properties
From: Rob Herring (Arm) @ 2026-07-16 23:05 UTC (permalink / raw)
To: Thierry Reding
Cc: Eric Dumazet, devicetree, linux-tegra, Andrew Lunn, Paolo Abeni,
linux-kernel, Jonathan Hunter, Krzysztof Kozlowski,
David S. Miller, Conor Dooley, Jakub Kicinski, netdev
In-Reply-To: <20260716212001.989872-1-thierry.reding@kernel.org>
On Thu, 16 Jul 2026 23:20:01 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Being a DWMAC derivative, the Tegra234 MGBE supports AXI configuration
> nodes named stmmac-axi-config and phandle references to them using the
> snps,axi-config property.
>
> While at it, add the 10gbase-r PHY mode.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> This gets rid of the remaining warnings on half of the Tegra234 boards.
>
> .../devicetree/bindings/net/nvidia,tegra234-mgbe.yaml | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml: properties:snps,axi-config: 'anyOf' conditional failed, one must be fixed:
'description' is a dependency of '$ref'
'snps,dwmac.yaml#/properties/snps,axi-config' does not match 'types.yaml#\\/definitions\\/'
hint: A vendor property needs a $ref to types.yaml
'snps,dwmac.yaml#/properties/snps,axi-config' does not match '^#\\/(definitions|\\$defs)\\/'
hint: A vendor property can have a $ref to a a $defs schema
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260716212001.989872-1-thierry.reding@kernel.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v7 09/13] clk: zte: Introduce a driver for zx297520v3 top clocks
From: sashiko-bot @ 2026-07-16 22:42 UTC (permalink / raw)
To: Stefan Dösinger
Cc: devicetree, olteanv, robh, vkoul, neil.armstrong, linux-phy,
conor+dt
In-Reply-To: <20260717-zx29clk-v7-9-408411cfcf36@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Using `clk_main[0]` to initialize the `.parent` field in the `zx297520v3_top_gates` static array is a violation of ISO C rules for constant expressions, resulting in a hard compile error.
--
--- Patch [9]: [PATCH v7 09/13] clk: zte: Introduce a driver for zx297520v3 top clocks ---
commit 8a7fee3879cf08b60157cde425eed4bbaa05fcb1
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 top clocks
This commit introduces a clock driver for the ZTE zx297520v3 SoC top clocks.
It supports core devices such as PLLs, the AHB bus, timers, the USB
controller, and the Cortex M0 processor.
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> new file mode 100644
> index 0000000000000..20ff00ba5f670
> --- /dev/null
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> +static const struct zx_gate_desc zx297520v3_top_gates[] = {
[ ... ]
> + /* AHB clock gates: Disabling these cuts off the A53 from register access into 0x130000/
> + * 0x140000, including the topcrm region, so it can't be re-enabled. Mark them critical for
> + * that reason.
> + *
> + * Gating this off does not stop the M0 rproc, nor does it stop M0 from accessing topcrm. It
> + * does however gate off M0 from the AXI interconnect, so it can't read RAM, Matrix, etc. So
> + * these bits here merely gate the bus, not the actual devices.
> + */
> + GATE(ZX297520V3_AHB_PCLK, "ahb-pclk", "ahb-mux", 0x54, 12,
> + CLK_IS_CRITICAL),
> + GATE(ZX297520V3_AHB_WCLK, "ahb-wclk", "m0-mux", 0x54, 13,
> + CLK_IS_CRITICAL),
> +
> + /* SRAM1 and 2 clocks. Leave them on for now, as turning them off carelessly hangs the M0 */
> + GATE(ZX297520V3_SRAM1_PCLK, "sram1-pclk", clk_main[0], 0x54, 18,
> + CLK_IS_CRITICAL),
[Severity: Low]
Does using clk_main[0] to initialize elements of a static array cause a build
failure?
In C, array accesses are not treated as constant expressions. Initializing the
zx297520v3_top_gates static array with clk_main[0] will cause the compiler
to fail with an "initializer element is not constant" error.
Could a string literal like "clock-26m" be used directly instead?
> + GATE(ZX297520V3_SRAM2_PCLK, "sram2-pclk", clk_main[0], 0x54, 16,
> + CLK_IS_CRITICAL),
> +
> + /* Pinmux (AON, TOP, IOCFG but not PDCFG). Critical as well until we have a driver that
> + * consumes it. I don't think we'll realistically shut this off ever.
> + *
> + * Setting either bit 0 or 1 in register 0x58 makes the device work.
> + */
> + GATE(ZX297520V3_PMM_WCLK, "pmm-wclk", clk_main[0], 0x58, 0,
> + CLK_IS_CRITICAL),
> + GATE(ZX297520V3_PMM_PCLK, "pmm-pclk", clk_main[0], 0x58, 1,
> + CLK_IS_CRITICAL),
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-zx29clk-v7-0-408411cfcf36@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH v7 08/13] clk: zte: Add zx PLL support infrastructure
From: sashiko-bot @ 2026-07-16 22:34 UTC (permalink / raw)
To: Stefan Dösinger
Cc: conor+dt, devicetree, neil.armstrong, linux-phy, olteanv, vkoul,
robh
In-Reply-To: <20260717-zx29clk-v7-8-408411cfcf36@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] zx29_pll_calc_values fails to clamp out-of-bounds frequencies, causing rate determination to abort instead of returning the closest achievable rate.
- [High] .determine_rate does not enforce req->min_rate and req->max_rate boundaries.
- [Medium] Using `dev_info` inside `zx29_pll_set_rate` will spam the kernel log.
--
--- Patch [8]: [PATCH v7 08/13] clk: zte: Add zx PLL support infrastructure ---
commit c3e5de791970b113941346866ebf54af4b186d7d
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add zx PLL support infrastructure
This commit adds PLL support infrastructure for ZTE zx chips, specifically
tested with the zx297520v3. It provides the standard clock operations
including rate calculation, parent selection, and enabling/disabling
of the PLLs.
> diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
> index f8ddb4c7dff66..701e580609f2b 100644
> --- a/drivers/clk/zte/pll-zx.c
> +++ b/drivers/clk/zte/pll-zx.c
[ ... ]
> +static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
> + unsigned long rate)
> +{
[ ... ]
> + for (j = 1; j <= postdiv2_max; j++) {
> + for (i = 1; i <= postdiv1_max; i++) {
> + u64 vco = (u64)rate * i * j;
> + unsigned long out;
> +
> + if (vco > ZX29_PLL_VCO_MAX_FREQ || vco < ZX29_PLL_VCO_MIN_FREQ)
> + continue;
[Severity: High]
Does this logic fail to clamp out-of-bounds frequencies?
If a consumer requests a clock rate where the maximum evaluated VCO
(e.g., 10 MHz * 7 * 7 = 490 MHz) is less than ZX29_PLL_VCO_MIN_FREQ,
this loop will just continue and return 0.
Should the requested rate be clamped to the physical minimum and maximum
achievable bounds before computing the VCO to ensure it returns the closest
supported rate?
[ ... ]
> +static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + unsigned long new_rate;
> + u32 setting;
[ ... ]
> + setting = zx29_pll_calc_values(pll, req->best_parent_rate, req->rate);
> + if (!setting)
> + return -EINVAL;
> +
> + new_rate = zx29_pll_get_rate(pll, req->best_parent_rate, setting);
> + if (new_rate != req->rate) {
> + dev_warn(pll->dev, "Did not find an exact match. Want %lu, got %lu\n",
> + req->rate, new_rate);
> + req->rate = new_rate;
[Severity: High]
Does this assignment violate the caller's min/max rate constraints?
If the closest hardware rate falls outside the req->min_rate and req->max_rate
boundaries, assigning it back to req->rate could cause the clock framework to
reject the rate change entirely, even if another slightly less optimal but
in-bounds rate was available.
> + }
> +
> + return 0;
> +}
> +
> +static int zx29_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + int res = -EINVAL;
> + u32 setting;
> +
> + /* PLLs can be changed while they are running and in testing the downstream hardware
> + * handles it gracefully - as long as the new rate is a rate the hardware can operate at.
> + */
> + setting = zx29_pll_calc_values(pll, parent_rate, rate);
> + if (!setting)
> + return -EINVAL;
> +
> + if (zx29_pll_get_rate(pll, parent_rate, setting) == rate) {
> + res = regmap_update_bits(pll->map, pll->reg, 0x00ffffff, setting);
> + dev_info(pll->dev, "%s: Setting rate: 0x%08x\n", clk_hw_get_name(hw), setting);
[Severity: Medium]
Could this dev_info call cause log spam during dynamic frequency scaling?
If this PLL is used for scaling operations where .set_rate is called
hundreds of times per second, this will rapidly flood the kernel log.
Would dev_dbg be more appropriate for this hot path?
> + }
> +
> + return res;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-zx29clk-v7-0-408411cfcf36@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v7 06/13] clk: zte: Add Clock registration infrastructure
From: sashiko-bot @ 2026-07-16 22:26 UTC (permalink / raw)
To: Stefan Dösinger
Cc: vkoul, linux-phy, robh, conor+dt, devicetree, olteanv,
neil.armstrong
In-Reply-To: <20260717-zx29clk-v7-6-408411cfcf36@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] In `zx_clk_common_probe()`, the error path for `data->init(map)` incorrectly returns `PTR_ERR(clk)` instead of propagating the actual error code `res`.
--
--- Patch [6]: [PATCH v7 06/13] clk: zte: Add Clock registration infrastructure ---
commit 377a6af7769b840d87a85b32af3001fd5f4431dd
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add Clock registration infrastructure
This commit adds the common clock registration infrastructure for ZTE SoCs.
It includes support for registering PLLs, muxes, dividers, and gates using
regmap, and introduces a common probe function to initialize them.
> diff --git a/drivers/clk/zte/clk-zx.c b/drivers/clk/zte/clk-zx.c
> new file mode 100644
> index 0000000000000..db4fad2b4b056
> --- /dev/null
> +++ b/drivers/clk/zte/clk-zx.c
[ ... ]
> @@ -0,0 +1,155 @@
[ ... ]
> +int zx_clk_common_probe(struct device *dev, struct device_node *of_node,
> + const struct zx_clk_data *data)
> +{
[ ... ]
> + if (data->init) {
> + res = data->init(map);
> + if (res)
> + return dev_err_probe(dev, PTR_ERR(clk), "Controller init failure\n");
[Severity: High]
Does this code pass the wrong error code to dev_err_probe() in the
zx_clk_common_probe() error path?
When data->init(map) fails, it returns a non-zero error code into res.
However, the error handling block incorrectly evaluates and returns
PTR_ERR(clk).
Since clk is merely an iteration variable from the preceding loops, it could
be completely uninitialized if num_inputs_enable and num_inputs are 0, which
might trick the driver core into assuming the probe succeeded despite
initialization failing.
If the loops did execute successfully, clk holds a valid pointer, and
PTR_ERR(clk) will return a random large number depending on the pointer's
memory address, resulting in a meaningless error code.
Should this return res instead of PTR_ERR(clk)?
> + }
> +
> + res = zx_clk_register_plls(dev, map, data->plls, data->num_plls);
> + if (res)
> + return res;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-zx29clk-v7-0-408411cfcf36@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH 2/2] riscv: dts: spacemit: k3: Add PCIe device node
From: Inochi Amaoto @ 2026-07-16 22:24 UTC (permalink / raw)
To: Anirudh Srinivasan, Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, devicetree,
linux-riscv, spacemit, linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <CAEev2e8ZyM+b9qLxS6NZjkBZy5GFz37vjgtEfH0ax24nfPozow@mail.gmail.com>
On Mon, Jul 13, 2026 at 10:04:09AM -0500, Anirudh Srinivasan wrote:
> Hi Inochi,
>
> On Sun, Jul 12, 2026 at 11:19 PM Inochi Amaoto <inochiama@gmail.com> wrote:
> >
> > On Sun, Jul 12, 2026 at 11:13:07PM -0500, Anirudh Srinivasan wrote:
> > > Hi Inochi,
> > >
> > > On Thu, Jul 09, 2026 at 12:04:14PM +0800, Inochi Amaoto wrote:
> > > > Add all PCIe device node for Spacemit K3.
> > > >
> > > > Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> > > > ---
> > > > arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 38 ++++
> > > > arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi | 33 ++++
> > > > arch/riscv/boot/dts/spacemit/k3.dtsi | 195 +++++++++++++++++++
> > > > 3 files changed, 266 insertions(+)
> > > >
> > >
> > > I see some warnings printed during probe
> > >
> > > [ 10.842955] r8169 0002:01:00.0: of_irq_parse_pci: failed with rc=-22
> > >
> > > [ 10.937754] rtw89_8852be 0004:01:00.0: of_irq_parse_pci: failed with rc=-22
> > >
> >
> > This is an expected error because the driver does not support INTx
> > but the hardware claims it supports. Since the vendor does not want
> > to support it, so there is no way for the upstreamer to add this.
>
> Are you saying that the hardware advertises support for INTx, but
> spacemit hasn't provided a driver that uses it?
>
> Is there a way to let the driver know to not try setting up legacy
> interrupts then? It seems like it's trying to do that now, and failing
> to find interrupts node in the DT.
>
IIRC it is hard to do this, this is more like a quirk for the spacemit
PCIe controllers.
Regards,
Inochi
> >
> > > I see that all the 3 rc nodes are missing an interrupts node and an
> > > interrupt parent (saplic). The vendor DT seems to have this. Not sure if
> > > this is related.
> > >
> > > The 10G ethernet probes fine, but the wifi card fails to probe. Seems
> > > like the card is trying to request 32 bit DMA addresses and we're
> > > failing cause we have 64 bit memory only.
> > > The vendor kernel seems to have a patch to enable 36 bit DMA in
> > > the rtw89 driver. That'll probably fix this.
> > >
> >
> > This warning is also found on my test, it is not related to
> > the PCIe driver, but a lack of the RTL phy driver. :(
> >
> > You may also noticed a bad performance on this 10G ethernet,
> > it is caused by the single queue used by the RTL driver.
> > IIRC, even 9800 X3D can not achieve the max speed.
>
> I don't have the ability to test the 10G NIC unfortunately :(
>
> Regards
> Anirudh Srinivasan
>
> >
> > Regards,
> > Inochi
> >
^ permalink raw reply
* Re: [PATCH v7 03/13] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller
From: sashiko-bot @ 2026-07-16 22:25 UTC (permalink / raw)
To: Stefan Dösinger
Cc: vkoul, linux-phy, neil.armstrong, olteanv, robh, conor+dt,
devicetree
In-Reply-To: <20260717-zx29clk-v7-3-408411cfcf36@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added clock and reset macro definitions overlap with existing definitions for a different controller (topcrm) in the same header files, using the same `ZX297520V3_` prefix without disambiguation.
--
--- Patch [3]: [PATCH v7 03/13] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller ---
commit 5ec0de6373fd034a146a7bae84009d3814552ed6
Author: Stefan Dösinger <stefandoesinger@gmail.com>
dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller
This controller contains clocks and resets for high speed devices on the
zx297520v3 board and hardware spinlocks that I expect will be necessary
to communicate correctly with the LTE DSP firmware blob. A simple MFD driver
will instantiate independent clock, reset and hwlock drivers.
> diff --git a/include/dt-bindings/clock/zte,zx297520v3-clk.h b/include/dt-bindings/clock/zte,zx297520v3-clk.h
> index 1f010ff4e6ca6..09ee3de679d96 100644
> --- a/include/dt-bindings/clock/zte,zx297520v3-clk.h
> +++ b/include/dt-bindings/clock/zte,zx297520v3-clk.h
> @@ -63,4 +63,45 @@
> #define ZX297520V3_HSIC_WCLK 55
> #define ZX297520V3_HSIC_PCLK 56
>
> +#define ZX297520V3_SYS_TIMER_WCLK 1
> +#define ZX297520V3_CPU_WCLK 2
[Severity: Low]
Could these new clock macros overlap with the existing ones in this header
and cause confusion?
The existing topcrm clocks in this header also start at 1 and use the same
ZX297520V3_ prefix, for example ZX297520V3_M0_WCLK. Is there a risk that a
developer might accidentally use a matrixcrm clock macro for a topcrm node
or vice versa? If they do, the C preprocessor will substitute the
overlapping integer without error.
Would it be safer to add a distinct prefix for the matrixcrm clocks, such
as ZX297520V3_MATRIX_?
[ ... ]
> diff --git a/include/dt-bindings/reset/zte,zx297520v3-reset.h b/include/dt-bindings/reset/zte,zx297520v3-reset.h
> index 43db72bb59de0..4682d4a599c6a 100644
> --- a/include/dt-bindings/reset/zte,zx297520v3-reset.h
> +++ b/include/dt-bindings/reset/zte,zx297520v3-reset.h
> @@ -29,4 +29,16 @@
> #define ZX297520V3_HSIC_PHY_RESET 20
> #define ZX297520V3_HSIC_RESET 21
>
> +#define ZX297520V3_CPU_RESET 0
> +#define ZX297520V3_DDR_CTRL_RESET 1
[Severity: Low]
Does this identical prefix also cause an overlap risk for reset definitions?
The new matrixcrm resets start at 0 and use the ZX297520V3_ prefix, which
overlaps with the existing topcrm resets like ZX297520V3_ZSP_RESET.
Could adding a matrixcrm-specific prefix here also help prevent potential
device tree configuration errors?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-zx29clk-v7-0-408411cfcf36@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v7 05/13] mfd: zx297520v3: Add a clock and reset MFD driver
From: sashiko-bot @ 2026-07-16 22:24 UTC (permalink / raw)
To: Stefan Dösinger
Cc: olteanv, neil.armstrong, devicetree, robh, linux-phy, conor+dt,
vkoul
In-Reply-To: <20260717-zx29clk-v7-5-408411cfcf36@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Complex platform data structures (`mfd_cell` arrays) are passed directly through the `.data` field of the `of_device_id` match table.
- [Medium] The MFD core driver is incorrectly located in `drivers/soc/zte/` instead of `drivers/mfd/`.
- [Medium] The driver uses `PLATFORM_DEVID_NONE` instead of `PLATFORM_DEVID_AUTO` for subdevice indexing.
--
--- Patch [5]: [PATCH v7 05/13] mfd: zx297520v3: Add a clock and reset MFD driver ---
commit 040c43d18f894269b77d87091f84cd5ad6b9755d
Author: Stefan Dösinger <stefandoesinger@gmail.com>
mfd: zx297520v3: Add a clock and reset MFD driver
This driver registers child devices for the zx297520v3 clock and reset
controllers. The clk-zx297520v3 and reset-zte-zx297520v3 submitted in
the next patches will drive the respective functionalities.
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> new file mode 100644
> index 0000000000000..090ba8aa06c1e
> --- /dev/null
> +++ b/drivers/soc/zte/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-$(CONFIG_ZTE_ZX297520V3_CRM) += zx297520v3-crm.o
[Severity: Medium]
Since this driver utilizes the devm_mfd_add_devices() API and registers
multiple child devices, should it be located in drivers/mfd/ instead of
drivers/soc/zte/?
The MFD guidelines state that placing MFD core drivers outside of drivers/mfd/
violates subsystem layering and bypasses proper subsystem maintainer review.
[ ... ]
> diff --git a/drivers/soc/zte/zx297520v3-crm.c b/drivers/soc/zte/zx297520v3-crm.c
> new file mode 100644
> index 0000000000000..8b82ccba4e90d
> --- /dev/null
> +++ b/drivers/soc/zte/zx297520v3-crm.c
[ ... ]
> +static int zx297520v3_crm_probe(struct platform_device *pdev)
> +{
> + const struct zx297520v3_crm_data *data;
> +
> + data = of_device_get_match_data(&pdev->dev);
> + if (!data)
> + return -ENODEV;
> +
> + return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE, data->cells,
[Severity: Medium]
Is it intentional to use PLATFORM_DEVID_NONE here?
The MFD subsystem guidelines prefer using PLATFORM_DEVID_AUTO for subdevice
indexing to avoid sysfs device naming collisions and driver load failures.
> + data->num_cells, NULL, 0, NULL);
> +}
> +
> +static const struct of_device_id of_match_zx297520v3_crm[] = {
> + { .compatible = "zte,zx297520v3-topcrm", .data = &zx297520v3_topcrm_data },
[Severity: High]
Does passing complex platform data structures (like the mfd_cell array inside
zx297520v3_topcrm_data) directly through the .data field of the of_device_id
match table pose a memory safety hazard and lead to initialization ordering
races?
The MFD guidelines suggest storing an integer ID or enum in the match table's
.data field, and using a switch statement in zx297520v3_crm_probe() to select
the correct static const mfd_cell array.
> + { .compatible = "zte,zx297520v3-matrixcrm", .data = &zx297520v3_matrixcrm_data },
> + { .compatible = "zte,zx297520v3-lspcrm", .data = &zx297520v3_lspcrm_data },
> + { }
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-zx29clk-v7-0-408411cfcf36@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v7 01/13] dt-bindings: phy: Add zx297520v3 USB phy documentation
From: sashiko-bot @ 2026-07-16 22:24 UTC (permalink / raw)
To: Stefan Dösinger
Cc: linux-phy, conor+dt, olteanv, devicetree, robh, neil.armstrong,
vkoul
In-Reply-To: <20260717-zx29clk-v7-1-408411cfcf36@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The example uses an undocumented compatible string 'zte,zx297520v3-topcrm', which will break `make dt_binding_check` for this commit.
--
--- Patch [1]: [PATCH v7 01/13] dt-bindings: phy: Add zx297520v3 USB phy documentation ---
commit 4c69b2717ebf9691d299b4744633e7788d392913
Author: Stefan Dösinger <stefandoesinger@gmail.com>
dt-bindings: phy: Add zx297520v3 USB phy documentation
This commit adds device tree binding documentation for the ZTE zx297520v3 USB
and HSIC PHY. It defines the required properties for the PHY, which acts as
a child node to the topcrm controller.
> diff --git a/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml
> new file mode 100644
> index 0000000000000..8bad9365d5cc0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.yaml
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/phy/phy-zte-zx297520v3-usb.h>
> +
> + topcrm: clock-controller {
> + compatible = "zte,zx297520v3-topcrm", "syscon";
[Severity: Low]
Will this undocumented compatible string cause a regression in
`make dt_binding_check` during bisection?
Since the "zte,zx297520v3-topcrm" binding is added in the next patch, evaluating
this commit on its own will result in validation failures because the string is
not documented in any schema and is not an allowed fallback in syscon.yaml.
Additionally, does the example node need a "reg" property since it includes
"syscon" in the compatible string? syscon.yaml requires it, which may lead to
further validation errors.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #reset-cells = <1>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-zx29clk-v7-0-408411cfcf36@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: Convert TI Keypad Controller to DT schema
From: Rob Herring @ 2026-07-16 22:12 UTC (permalink / raw)
To: sashiko-reviews
Cc: Eduard Bostina, dmitry.torokhov, conor+dt, linux-input,
devicetree
In-Reply-To: <20260708124112.1DC541F00A3A@smtp.kernel.org>
On Wed, Jul 08, 2026 at 12:41:11PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Properties strictly required by the hardware and driver ('keypad,num-rows', 'keypad,num-columns', 'interrupts', and 'linux,keymap') are omitted from the 'required:' list, allowing non-functional device trees to silently pass validation.
> --
>
> --- Patch [1]: [PATCH] dt-bindings: input: Convert TI Keypad Controller to DT schema ---
> commit 31e1662350e854e7b96beb7e7de83fc2b0d265e2
> Author: Eduard Bostina <egbostina@gmail.com>
>
> dt-bindings: input: Convert TI Keypad Controller to DT schema
>
> This commit converts the Texas Instruments Keypad Controller bindings to DT
> schema format. It updates the autorepeat property name, adds the reg-names
> property, and omits the keypad row and column properties from the required
> list to prevent validation failures.
>
> > diff --git a/Documentation/devicetree/bindings/input/ti,omap4-keypad.yaml b/Documentation/devicetree/bindings/input/ti,omap4-keypad.yaml
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/ti,omap4-keypad.yaml
> [ ... ]
> > +required:
> > + - compatible
> > + - reg
>
> [Severity: Medium]
> The commit message mentions that keypad,num-rows and keypad,num-columns were
> omitted from this required list because enforcing them causes validation
> failures. Should these properties, along with interrupts and linux,keymap,
> be included here to accurately reflect the driver's probing requirements?
>
> Omitting them allows non-functional device tree nodes to silently pass
> schema validation. At runtime, the omap4-keypad driver will unconditionally
> fail to probe via platform_get_irq(), matrix_keypad_parse_properties(), and
> matrix_keypad_build_keymap() when these properties are missing.
>
> Would it be better to enforce the strict hardware and driver requirements in
> the schema, and instead fix the incomplete device tree nodes that are
> failing validation?
Yes. sashiko is right.
Rob
^ permalink raw reply
* [PATCH v7 13/13] ARM: dts: zte: Declare zx297520v3 CRM device nodes
From: Stefan Dösinger @ 2026-07-16 22:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
devicetree, linux-kernel
In-Reply-To: <20260717-zx29clk-v7-0-408411cfcf36@gmail.com>
This makes use of the driver added in the previous patches. It wires up
the uart clocks and resets and allows getting rid of the placeholder
uartclk node.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Version 7:
Add phy nodes to topcrm
Remove syscon from matrixclk again
Adapt remove now-removed extra clk inputs from matrix
Add reset to LSP
osc26m -> clock-26m for the fixed rate clocks, likewise for 32k
Version 6:
Add syscon to matrixclk
Version 5:
Re-name from *clk to *crm
Add the syscon-reboot node here because the binding requires it
Re-add accidentally dropped uart2 IRQ
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 92 ++++++++++++++++++++++++++++++++---
1 file changed, 84 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index a16c30a164bb..b479d097f004 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -4,6 +4,8 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/zte,zx297520v3-reset.h>
+#include <dt-bindings/clock/zte,zx297520v3-clk.h>
/ {
#address-cells = <1>;
@@ -20,13 +22,16 @@ cpu@0 {
};
};
- /* Base bus clock and default for the UART. It will be replaced once a clock driver has
- * been added.
- */
- uartclk: uartclk-26000000 {
- #clock-cells = <0>;
+ osc26m: clock-26m {
compatible = "fixed-clock";
clock-frequency = <26000000>;
+ #clock-cells = <0>;
+ };
+
+ osc32k: clock-32k {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
};
timer {
@@ -70,13 +75,82 @@ gic: interrupt-controller@f2000000 {
<0xf2040000 0x20000>;
};
+ topcrm: clock-controller@13b000 {
+ compatible = "zte,zx297520v3-topcrm", "syscon";
+ reg = <0x0013b000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&osc26m>, <&osc32k>;
+ clock-names = "osc26m", "osc32k";
+
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ offset = <0x0>;
+ value = <0x1>;
+ mask = <0x1>;
+ };
+
+ usb-phy@84 {
+ compatible = "zte,zx297520v3-usb-phy";
+ reg = <0x84>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 43 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 45 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 46 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "usb-up", "usb-down", "hsic-up", "hsic-down";
+ resets = <&topcrm ZX297520V3_USB_PHY_RESET>,
+ <&topcrm ZX297520V3_HSIC_PHY_RESET>;
+ reset-names = "usb", "hsic";
+ #phy-cells = <1>;
+ };
+ };
+
+ matrixcrm: clock-controller@1306000 {
+ compatible = "zte,zx297520v3-matrixcrm";
+ reg = <0x01306000 0x400>;
+ clocks = <&osc26m>, <&osc32k>,
+ <&topcrm ZX297520V3_MPLL>, <&topcrm ZX297520V3_MPLL_D5>,
+ <&topcrm ZX297520V3_DPLL>, <&topcrm ZX297520V3_GPLL>,
+ <&topcrm ZX297520V3_GPLL_D2>, <&topcrm ZX297520V3_GATED_OSC26M>;
+ clock-names = "osc26m", "osc32k", "mpll", "mpll-d5", "dpll",
+ "gpll", "gpll-d2", "wclk-osc26m";
+ #clock-cells = <1>;
+ #hwlock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ lspcrm: clock-controller@1400000 {
+ compatible = "zte,zx297520v3-lspcrm";
+ reg = <0x01400000 0x100>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+
+ clocks = <&matrixcrm ZX297520V3_LSP_MPLL_D5_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_MPLL_D4_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_MPLL_D6_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_MPLL_D8_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_MPLL_D12_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_OSC26M_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_OSC32K_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_PCLK>,
+ <&matrixcrm ZX297520V3_LSP_TDM_WCLK>,
+ <&matrixcrm ZX297520V3_LSP_DPLL_D4_WCLK>;
+ clock-names = "mpll-d5", "mpll-d4", "mpll-d6", "mpll-d8", "mpll-d12",
+ "osc26m", "osc32k", "pclk", "tdm-wclk", "dpll-d4";
+ resets = <&matrixcrm ZX297520V3_LSP_RESET>;
+ };
+
+
uart0: serial@131000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x0018c011>;
reg = <0x00131000 0x1000>;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&uartclk>, <&uartclk>;
+ clocks = <&topcrm ZX297520V3_UART0_WCLK>, <&topcrm ZX297520V3_UART0_PCLK>;
clock-names = "uartclk", "apb_pclk";
+ resets = <&topcrm ZX297520V3_UART0_RESET>;
status = "disabled";
};
@@ -85,8 +159,9 @@ uart1: serial@1408000 {
arm,primecell-periphid = <0x0018c011>;
reg = <0x01408000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&uartclk>, <&uartclk>;
+ clocks = <&lspcrm ZX297520V3_UART1_WCLK>, <&lspcrm ZX297520V3_UART1_PCLK>;
clock-names = "uartclk", "apb_pclk";
+ resets = <&lspcrm ZX297520V3_UART1_RESET>;
status = "disabled";
};
@@ -95,8 +170,9 @@ uart2: serial@140d000 {
arm,primecell-periphid = <0x0018c011>;
reg = <0x0140d000 0x1000>;
interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&uartclk>, <&uartclk>;
+ clocks = <&lspcrm ZX297520V3_UART2_WCLK>, <&lspcrm ZX297520V3_UART2_PCLK>;
clock-names = "uartclk", "apb_pclk";
+ resets = <&lspcrm ZX297520V3_UART2_RESET>;
status = "disabled";
};
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: leds: backlight: Convert TPS65217 to DT schema
From: Rob Herring @ 2026-07-16 21:59 UTC (permalink / raw)
To: Eduard Bostina
Cc: Conor Dooley, Daniel Thompson, devicetree, dri-devel, Jingoo Han,
Krzysztof Kozlowski, Lee Jones, linux-kernel, linux-leds,
Pavel Machek, daniel.baluta, simona.toaca, goledhruva, m-chawdhry
In-Reply-To: <20260708123317.1768641-1-egbostina@gmail.com>
On Wed, Jul 08, 2026 at 12:33:17PM +0000, Eduard Bostina wrote:
> Convert the Texas Instruments TPS65217 PMIC bindings to DT schema.
>
> During the conversion, the following updates were made:
> - Make the 'backlight' node optional to resolve dtbs_check warnings.
> Some boards declare a bare TPS65217 node without implementing the
> backlight configuration.
> - Document the 'isink-en' property in the backlight subnode to resolve
> dtbs_check warnings. This property is used (am335x-guardian.dts)
> to manage the backlight current sinks. It was missing from the old
> txt binding.
> - 'additionalProperties: true' is at the top level because the
> TPS65217 node is documented across multiple independent schemas
> matching the same compatible string.
We can't have true here.
Looks to me like you just need to define all the child nodes like
'regulators' (and its children) and 'charger' (which already has a
schema).
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
> .../bindings/leds/backlight/ti,tps65217.yaml | 82 +++++++++++++++++++
> .../leds/backlight/tps65217-backlight.txt | 27 ------
> 2 files changed, 82 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> delete mode 100644 Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> new file mode 100644
> index 000000000000..07b15cab4b63
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/ti,tps65217.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TPS65217 family of regulators
> +
> +maintainers:
> + - Eduard Bostina <egbostina@gmail.com>
> +
> +description: |
Don't need '|' if no formatting.
> + The TPS65217 chip contains a boost converter and current sinks which can be
> + used to drive LEDs for use as backlights.
> +
> +properties:
> + compatible:
> + const: ti,tps65217
> +
> + reg:
> + maxItems: 1
> + description: I2C slave address
> +
> + backlight:
> + type: object
> + additionalProperties: false
> + description:
> + Node for specifying WLED1 and WLED2 lines in TPS65217.
> +
> + properties:
> + isel:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 2]
> + description: |
> + Selection bit. Valid values:
> + 1 - ISEL1 (low-level)
> + 2 - ISEL2 (high-level)
> +
> + fdim:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [100, 200, 500, 1000]
> + description:
> + PWM dimming frequency in Hz.
> +
> + default-brightness:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 100
> +
> + isink-en:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Enable backlight current sinks.
Constraints? 0 or 1?
Not used by any driver, so perhaps it should be removed from the .dts
file.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpu: host1x: Fix email address
From: Thierry Reding @ 2026-07-16 21:54 UTC (permalink / raw)
To: Thierry Reding
Cc: Mikko Perttunen, Jonathan Hunter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, devicetree
In-Reply-To: <20260701160655.725111-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
On Wed, 01 Jul 2026 18:06:55 +0200, Thierry Reding wrote:
> These bindings had mixed up local and domain parts, the combination of
> which doesn't exist. Fix them up.
Applied, thanks!
[1/1] dt-bindings: gpu: host1x: Fix email address
commit: d28b49f11f8cbb7d76382998c84c18f465b347a4
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: Convert OMAP USB TLL to DT schema
From: Rob Herring (Arm) @ 2026-07-16 21:50 UTC (permalink / raw)
To: Eduard Bostina
Cc: mfd, Conor Dooley, linux-kernel, simona.toaca, goledhruva,
devicetree, daniel.baluta, Krzysztof Kozlowski, m-chawdhry,
Lee Jones
In-Reply-To: <20260708123328.1768794-1-egbostina@gmail.com>
On Wed, 08 Jul 2026 12:33:28 +0000, Eduard Bostina wrote:
> Convert the OMAP HS USB Host TLL bindings to DT schema.
>
> During the conversion, ti,hwmods has been made optional to resolve
> dtbs_check warnings. Modern OMAP platforms do not require this
> property, but it is still required for older platforms.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
> .../devicetree/bindings/mfd/omap-usb-tll.txt | 27 ----------
> .../devicetree/bindings/mfd/ti,usbhs-tll.yaml | 53 +++++++++++++++++++
> 2 files changed, 53 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/ti,usbhs-tll.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 05/10] dt-bindings: clock: renesas,r8a78000-cpg: Add firmware property
From: Rob Herring @ 2026-07-16 21:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, Sudeep Holla, Cristian Marussi,
Krzysztof Kozlowski, Conor Dooley, Saravana Kannan, Ulf Hansson,
Rafael J . Wysocki, Philipp Zabel, Michael Turquette,
Stephen Boyd, Brian Masney, Bartosz Golaszewski, Vinod Koul,
Konrad Dybcio, Kevin Hilman, Florian Fainelli, Wolfram Sang,
Marek Vasut, Kuninori Morimoto, arm-scmi, linux-arm-kernel,
devicetree, linux-pm, linux-clk, linux-renesas-soc, linux-kernel
In-Reply-To: <CAMuHMdV=ckONBbTYELPJU8YWoNzdu3PJ95VR8cz+f_7dUeiPUw@mail.gmail.com>
On Fri, Jul 10, 2026 at 01:02:39PM +0200, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Fri, 10 Jul 2026 at 12:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Wed, Jul 08, 2026 at 12:16:23PM +0200, Geert Uytterhoeven wrote:
> > > Add a firmware property, for systems where SCMI must be used instead of
> > > direct hardware access.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > v2:
> > > - Spin off from "dt-bindings: clock: Document Renesas R-Car X5H Clock
> > > Pulse Generator".
> > > ---
> > > .../devicetree/bindings/clock/renesas,r8a78000-cpg.yaml | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
> > > index 4e23bba334382346..fc499e7cf52e4f0c 100644
> > > --- a/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
> > > +++ b/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
> > > @@ -35,6 +35,12 @@ properties:
> > > <dt-bindings/clock/renesas,r8a78000-cpg.h>.
> > > const: 1
> > >
> > > + firmware:
> >
> > RPi is doing similar, but I have doubts. It looks way too close to
> > generic "syscon" which is disallowed.
> >
> > I think this should be vendor+purpose specific, e.g.:
> > "renesas,scmi-transport" or "renesas,scmi-firmware"
If you can tell me the resource that a 'firmware' provider provides then
it is fine, but you can't.
> The disadvantage of a vendor-specific property is that there are more
> cases to handle for fw_devlink, cfr. "[PATCH v2 02/10] of: property:
> fw_devlink: Add support for firmware"[1].
If vendor specific phandle properties are a problem for fw_devlink, then
we already have that problem to solve and 1 more doesn't matter.
Rob
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: iommu: Fix interrupt type in example
From: Thierry Reding @ 2026-07-16 21:47 UTC (permalink / raw)
To: joro, will, robin.murphy, robh, krzk+dt, conor+dt, jonathanh,
thierry.reding, nicolinc, Ashish Mhetre
Cc: iommu, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260622065410.2780215-1-amhetre@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
On Mon, 22 Jun 2026 06:54:09 +0000, Ashish Mhetre wrote:
> The CMDQV interrupt on Tegra264 is edge-triggered per the hardware
> interrupt documentation, but the binding example describes it as
> level-triggered. Correct the example to use IRQ_TYPE_EDGE_RISING so
> that it does not propagate the wrong trigger type.
Applied, thanks!
[2/2] arm64: tegra: Fix CMDQV interrupt type on Tegra264
commit: e70af6a126e172274d9e6459d80438a46d4455f3
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* [PATCH v3] dt-bindings: clock: ti,clockdomain: Convert to DT schema
From: Bhargav Joshi @ 2026-07-16 21:45 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tero Kristo
Cc: linux-clk, devicetree, linux-kernel, goledhruva, m-chawdhry,
daniel.baluta, simona.toaca, j.bhargav.u
Convert TI clockdomain to yaml DT schema. Drop '#clock-cells' from the
required list as this binding doesn't define a new clock binding type,
it is used to group existing clock nodes under hardware hierarchy. Most
existing dts omit '#clock-cells'.
Update the reference to the old legacy text binding in the description
of bindings/clock/ti/ti,gate-clock.yaml to point to the new YAML file.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
Changes in v3:
- set limits for clock-output-names and clocks properties
- Link to v2: https://lore.kernel.org/r/20260622-ti-clockdomain-v2-1-434dbe0789e2@gmail.com
Changes in v2:
- updating the stale reference to the legacy .txt file inside
bindings/clock/ti/ti,gate-clock.yaml to fix make refcheckdocs error
- Link to v1: https://lore.kernel.org/r/20260621-ti-clockdomain-v1-1-e99a56af98ea@gmail.com
---
.../devicetree/bindings/clock/ti/clockdomain.txt | 25 ------------
.../bindings/clock/ti/ti,clockdomain.yaml | 44 ++++++++++++++++++++++
.../bindings/clock/ti/ti,gate-clock.yaml | 2 +-
3 files changed, 45 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
deleted file mode 100644
index edf0b5d42768..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Binding for Texas Instruments clockdomain.
-
-This binding uses the common clock binding[1] in consumer role.
-Every clock on TI SoC belongs to one clockdomain, but software
-only needs this information for specific clocks which require
-their parent clockdomain to be controlled when the clock is
-enabled/disabled. This binding doesn't define a new clock
-binding type, it is used to group existing clock nodes under
-hardware hierarchy.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "ti,clockdomain"
-- #clock-cells : from common clock binding; shall be set to 0.
-- clocks : link phandles of clocks within this domain
-
-Optional properties:
-- clock-output-names : from common clock binding.
-
-Examples:
- dss_clkdm: dss_clkdm {
- compatible = "ti,clockdomain";
- clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml b/Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml
new file mode 100644
index 000000000000..95746bfdced4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,clockdomain.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments clockdomain
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description:
+ This binding uses the common clock binding in consumer role. Every clock on TI
+ SoC belongs to one clockdomain, but software only needs this information for
+ specific clocks which require their parent clockdomain to be controlled when
+ the clock is enabled/disabled. This binding doesn't define a new clock binding
+ type, it is used to group existing clock nodes under hardware hierarchy.
+
+properties:
+ compatible:
+ const: ti,clockdomain
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ minItems: 1
+ maxItems: 64
+
+ clock-output-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ dss_clkdm {
+ compatible = "ti,clockdomain";
+ clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
index eaa727ab0d7f..438e190d1067 100644
--- a/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
@@ -19,7 +19,7 @@ description: |
that is used.
[1] Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml
- [2] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+ [2] Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml
properties:
compatible:
---
base-commit: acb7500801e98639f6d8c2d796ed9f64cba83d3a
change-id: 20260610-ti-clockdomain-a27dd0fa1ad5
Best regards,
--
Bhargav
^ permalink raw reply related
* Re: [PATCH v7 0/4] iio: adc: Add support for LTC2378 and similar ADCs
From: Andy Shevchenko @ 2026-07-16 21:44 UTC (permalink / raw)
To: Marcelo Schmitt
Cc: linux-iio, devicetree, linux-kernel, jic23, nuno.sa,
Michael.Hennerich, dlechner, andy, robh, krzk+dt, conor+dt,
julianbraha, marcelo.schmitt1
In-Reply-To: <cover.1784235595.git.marcelo.schmitt@analog.com>
On Thu, Jul 16, 2026 at 06:08:49PM -0300, Marcelo Schmitt wrote:
> This patch series adds support for LTC2378 and similar low noise, low power,
> high speed, successive approximation register (SAR) ADCs. These ADCs are similar
> among each other, varying mainly on the amount of precision bits, maximum sample
> rate, and input configuration (either fully differential or pseudo-differential).
>
> Patch 1 adds device tree documentation for LTC2378.
>
> Patch 2 enables single-shot sample read with a GPIO connected to the LTC2378 CNV pin.
>
> Patch 3 enables high-speed data captures with SPI offloading.
> The setup is similar to AD4030, with a specialized PWM generator being used both
> for SPI offload triggering and conversion start signaling.
>
> Patch 4 enables running buffered data captures without SPI offloading.
>
> Even though these parts are somewhat similar to AD4000, the wiring configuration
> for LTC parts is different as well as the available HDL for high speed sample
> rate mode. Because of that, I propose creating a new device driver for
> supporting LTC2378-like devices.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
for patches 2-4.
--
With Best Regards,
Andy Shevchenko
^ 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