* 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
* [PATCH v5 1/4] clk: sunxi-ng: mux: fix determine helper rate propagation
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>
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>
---
drivers/clk/sunxi-ng/ccu_mux.c | 56 ++++++++++++++++++++----------------------
1 file changed, 27 insertions(+), 29 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 09230728c400..75ec3457324c 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -92,66 +92,64 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
struct clk_rate_request adj_req = *req;
best_parent = clk_hw_get_parent(hw);
- best_parent_rate = clk_hw_get_rate(best_parent);
-
+ adj_req.best_parent_rate = clk_hw_get_rate(best_parent);
adj_req.best_parent_hw = best_parent;
- adj_req.best_parent_rate = ccu_mux_helper_apply_prediv(common, cm, -1,
- best_parent_rate);
+
+ /*
+ * This effectively treat the predivider as a postdivider.
+ * It stays mathematically correct and ensure whatever
+ * round() will do stays correct while walking the tree.
+ * It may query the parent rate too while handling rate propagation
+ */
+ adj_req.rate = ccu_mux_helper_unapply_prediv(common, cm, -1,
+ req->rate);
ret = round(cm, &adj_req, data);
if (ret)
return ret;
- best_rate = adj_req.rate;
-
/*
- * best_parent_rate might have been modified by our clock.
- * Unapply the pre-divider if there's one, and give
- * the actual frequency the parent needs to run at.
+ * parent_rate might have been modified by our clock as part
+ * of the rate propagation mechnanism. Same goes below.
*/
- best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, -1,
- adj_req.best_parent_rate);
+ best_parent_rate = adj_req.best_parent_rate;
+ best_rate = ccu_mux_helper_apply_prediv(common, cm, -1,
+ adj_req.rate);
goto out;
}
for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
struct clk_rate_request tmp_req = *req;
- unsigned long parent_rate;
+ unsigned long rate;
struct clk_hw *parent;
parent = clk_hw_get_parent_by_index(hw, i);
if (!parent)
continue;
- parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
- clk_hw_get_rate(parent));
-
tmp_req.best_parent_hw = parent;
- tmp_req.best_parent_rate = parent_rate;
+ tmp_req.best_parent_rate = clk_hw_get_rate(parent);
+ tmp_req.rate = ccu_mux_helper_unapply_prediv(common, cm, i,
+ req->rate);
ret = round(cm, &tmp_req, data);
if (ret)
continue;
- /*
- * parent_rate might have been modified by our clock.
- * Unapply the pre-divider if there's one, and give
- * the actual frequency the parent needs to run at.
- */
- parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
- tmp_req.best_parent_rate);
+ rate = ccu_mux_helper_apply_prediv(common, cm, i,
+ tmp_req.rate);
- if (tmp_req.rate == req->rate) {
+ if (rate == req->rate) {
best_parent = parent;
- best_parent_rate = parent_rate;
- best_rate = tmp_req.rate;
+ best_parent_rate = tmp_req.best_parent_rate;
+ best_rate = rate;
goto out;
}
- if (ccu_is_better_rate(common, req->rate, tmp_req.rate, best_rate)) {
- best_rate = tmp_req.rate;
- best_parent_rate = parent_rate;
+ if (ccu_is_better_rate(common, req->rate, rate, best_rate)) {
+ best_rate = rate;
+ best_parent_rate = tmp_req.best_parent_rate;
best_parent = parent;
}
}
--
2.47.3
^ permalink raw reply related
* [PATCH v5 0/4] clk: sun6i-rtc: Add support for Allwinner A733 SoC
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
Add support for the Allwinner A733 RTC and its internal Clock Control
Unit (CCU). Reuse the rtc-sun6i rtc driver while introducing a new
SoC-specific RTC CCU driver to handle the hardware's evolved clock
structure.
The A733 implementation supports hardware detection of three external
crystal frequencies (19.2MHz, 24MHz and 26MHz), which is represented in
the driver via read-only divider operations. Implement logic to derive a
normalized 32kHz reference from these DCXO sources using fixed
pre-dividers. Additionally, provide several new DCXO gate clocks for
peripherals, including SerDes, HDMI, and UFS.
This was tested on a Raxda Cubie A7A.
Changes in v5:
- Droped already applied changes
- Fix determine rate mux helper calculation
- Changed clock split commit description
- Added a macro for the clock number without gates
- Link to v4: https://patch.msgid.link/20260706-a733-rtc-v4-0-f330728db3d3@baylibre.com
Changes in v4:
- Remove unneeded export of mux prediv helpers
- Link to v3: https://patch.msgid.link/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com
Changes in v3:
- Disallow clock-output-names DT property for h616/r329 chips
- Fix ccu probe helper to properly unregister clocks on error
- Implement .determine_rate for ccu divider RO ops
- Drop unused DCXO_CTRL_REG_EN define
- Link to v2: https://patch.msgid.link/20260629-a733-rtc-v2-0-7b72112784f8@baylibre.com
Changes in v2:
* Changed DT bindings as suggested. Those have changed significantly
since v1 so I did not pick up Rob's review trailer
* Support added in the existing RTC CCU driver rather than a separate driver
* Added DT parsing clean up of the existing driver
* Xtal detection exposed by RO divider rather than a MUX.
* Dropped conversion to aux device for now. This is not strictly related
the a733 support and will submitted again later on.
* Link to v1: https://lore.kernel.org/r/20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech
---
Jerome Brunet (4):
clk: sunxi-ng: mux: fix determine helper rate propagation
clk: sunxi-ng: div: add read-only operation support
clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
clk: sunxi-ng: sun6i-rtc: add a733 support
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 89 ++++++++++++++++++++++++++++++++----
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 3 +-
drivers/clk/sunxi-ng/ccu_div.c | 30 +++++++++++-
drivers/clk/sunxi-ng/ccu_div.h | 1 +
drivers/clk/sunxi-ng/ccu_mux.c | 58 ++++++++++++-----------
drivers/clk/sunxi-ng/ccu_mux.h | 4 ++
6 files changed, 144 insertions(+), 41 deletions(-)
---
base-commit: c52b5090bf1e3b88745f8a81f264f34100ecde42
change-id: 20251226-a733-rtc-c5167df14e6e
Best regards,
--
Jerome
^ permalink raw reply
* Re: [PATCH 2/4] drm/bridge: display-connector: Fix I2C adapter resource leak
From: Luca Ceresoli @ 2026-07-17 15:21 UTC (permalink / raw)
To: Johan Hovold, Laurent Pinchart
Cc: dri-devel, devicetree, Thuan Nguyen, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, linux-renesas-soc,
stable
In-Reply-To: <alpEVeVmH5oiqmaj@hovoldconsulting.com>
On Fri Jul 17, 2026 at 5:03 PM CEST, Johan Hovold wrote:
> On Mon, Jul 06, 2026 at 12:35:40AM +0300, Laurent Pinchart wrote:
>> If the probe function returns an error after getting the I2C adapter for
>> DDC, the reference to the adapter is never released. Fix it by releasing
>> it in the bridge .destroy() handler.
>>
>> There is no need to test the ddc pointer with !IS_ERR(), as
>> of_get_i2c_adapter_by_node() returns NULL on error.
>
> I stumbled over this this morning as well and posted a fix here (which
> releases the adapter on driver unbind as is currently done):
>
> https://lore.kernel.org/lkml/20260717085716.1619275-1-johan@kernel.org/
>
>> Fixes: 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio support")
>
> I believe this issue was first introduced by commit 2e2bf3a5584d
> ("drm/bridge: display-connector: add DP support") a few releases
> earlier.
>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
> Reviewed-by: Johan Hovold <johan@kernel.org>
While Johan's patch has the benefit of putting the i2c adapter at remove
time (as opposed to destroy time, which is potentially a long time later),
it is also more complex. So I'd say this patch is fine.
Maybe we should have a devm version of of_get_i2c_adapter_by_node() to make
it all simpler.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 00/15] arm64: dts: freescale: imx8mn-var-som: Align SOM and Symphony DTSs
From: Frank.Li @ 2026-07-17 15:17 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1783330236.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 06 Jul 2026 11:34:30 +0200, Stefano Radaelli wrote:
> This series aligns the i.MX8MN VAR-SOM and VAR-SOM Symphony device
> trees with the latest hardware revisions.
>
> As the i.MX8MN device tree hierarchy closely mirrors the i.MX8MM one,
> this series applies the same alignment already accepted for the i.MX8MM
> platform, ensuring a consistent hardware description across both
> families.
>
> [...]
Applied, thanks!
[01/15] arm64: dts: freescale: imx8mn-var-som: Move UART4 description to Symphony
commit: 259bd77e9f635e058c045a880427570e534c8737
[02/15] arm64: dts: freescale: imx8mn-var-som: move uSD support to carrier boards
commit: bc5217a4e354ebe0a2f52d2188ef952fd630defc
[03/15] arm64: dts: freescale: imx8mn-var-som: Align fsl,pins tables
commit: 763a267bc2ccf637bd0f35492ca1e6ab6c9dc13b
[04/15] arm64: dts: freescale: imx8mn-var-som: Update FEC support with MaxLinear PHY
commit: a6c8d4f9c2db6254681d78ec93f5bd944a0cf89d
[05/15] arm64: dts: freescale: imx8mn-var-som: Add support for WM8904 audio codec
commit: ed99c5c5c5e88f31ed8de6eff9c3da2ca188d947
[06/15] arm64: dts: freescale: imx8mn-var-som: Add MCP251xFD CAN controller
commit: 42a066c24cc673b4317acb382597c0a3230b9f6f
[07/15] arm64: dts: freescale: imx8mn-var-som: Rework WiFi/BT and add legacy dts
commit: 040bf14c102570fee953fc2124737a988c3fb6a6
[08/15] arm64: dts: freescale: imx8mn-var-som: drop duplicate USB OTG node
commit: 0504e4d12fd3c3b5062b49086ce17a2743c60658
[09/15] arm64: dts: freescale: imx8mn-var-som: enable FlexSPI interface
commit: 5580a6278c5ce77a8492d76571929321894934f3
[10/15] arm64: dts: imx8mn-var-som-symphony: Add TPM2 support
commit: 8576126c7ccf632c8edeeb69f57f17ee5e125de5
[11/15] arm64: dts: imx8mn-var-som-symphony: Enable I2C4
commit: ab80a67f5cdb42797d0a92d7951242291bb97f3a
[12/15] arm64: dts: imx8mn-var-som-symphony: add wakeup sources
commit: e2e47af10c90f4c5eaf415fa98f6ca2f33ef30da
[13/15] arm64: dts: imx8mn-var-som-symphony: keep RGB_SEL low
commit: 164cb0d61a3fd0d9376005aae3b112a3dbba2e07
[14/15] arm64: dts: imx8mn-var-som-symphony: enable PWM1
commit: 8a6c812cd5a721aa0af9b7dd35b43d12c831349e
[15/15] arm64: dts: imx8mn-var-som-symphony: Disable internal RTC
commit: be578db51f789f0b88ec4f5e5f78e232b42c6b15
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: phy: Add support for the Maxio MAE0621A
From: Andrew Lunn @ 2026-07-17 15:15 UTC (permalink / raw)
To: Liu Changjie
Cc: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Luo Jie, Wolfram Sang,
devicetree, linux-kernel
In-Reply-To: <MN0PR19MB609153A4A590C66241B8A3CDACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
On Fri, Jul 17, 2026 at 11:44:03AM +0800, Liu Changjie wrote:
> Add exact PHY ID matching and optional 125 MHz CLKOUT configuration
> for the Maxio MAE0621A Gigabit Ethernet PHY. Preserve the existing
> hardware configuration when the firmware property is absent.
>
> Signed-off-by: Liu Changjie <liucj1228@outlook.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 7/7] soc: mediatek: mtk-mmsys: Add resets for mt8167
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
The mt8167 SoC has 64 MMSYS resets, split in two contiguous 32-bits
registers, MMSYS_SW0_RST_B (0x140) and MMSYS_SW1_RST_B (0x144), as
also stated in the downstream kernel for the Lenovo Smart Clock
in the ddp_reg.h header.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
drivers/soc/mediatek/mt8167-mmsys.h | 40 +++++++++++++++++++++++++++++
drivers/soc/mediatek/mtk-mmsys.c | 3 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/soc/mediatek/mt8167-mmsys.h b/drivers/soc/mediatek/mt8167-mmsys.h
index eef14083c47b..b8f38ff8cf44 100644
--- a/drivers/soc/mediatek/mt8167-mmsys.h
+++ b/drivers/soc/mediatek/mt8167-mmsys.h
@@ -3,6 +3,46 @@
#ifndef __SOC_MEDIATEK_MT8167_MMSYS_H
#define __SOC_MEDIATEK_MT8167_MMSYS_H
+#include <linux/soc/mediatek/mtk-mmsys.h>
+#include <dt-bindings/reset/mediatek,mt8167-resets.h>
+
+#define MT8167_MMSYS_SW0_RST_B 0x140
+#define MT8167_MMSYS_SW1_RST_B 0x144
+
+/* 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_CAM_MDP] = MMSYS_RST_NR(0, 2),
+ [MT8167_MMSYS_SW0_RST_B_MDP_RDMA0] = MMSYS_RST_NR(0, 3),
+ [MT8167_MMSYS_SW0_RST_B_MDP_RSZ0] = MMSYS_RST_NR(0, 4),
+ [MT8167_MMSYS_SW0_RST_B_MDP_RSZ1] = MMSYS_RST_NR(0, 5),
+ [MT8167_MMSYS_SW0_RST_B_MDP_TDSHP0] = MMSYS_RST_NR(0, 6),
+ [MT8167_MMSYS_SW0_RST_B_MDP_WDMA] = MMSYS_RST_NR(0, 7),
+ [MT8167_MMSYS_SW0_RST_B_MDP_WROT0] = MMSYS_RST_NR(0, 8),
+ [MT8167_MMSYS_SW0_RST_B_FAKE_ENG] = MMSYS_RST_NR(0, 9),
+ [MT8167_MMSYS_SW0_RST_B_MUTEX] = MMSYS_RST_NR(0, 10),
+ [MT8167_MMSYS_SW0_RST_B_DISP_OVL0] = MMSYS_RST_NR(0, 11),
+ [MT8167_MMSYS_SW0_RST_B_DISP_RDMA0] = MMSYS_RST_NR(0, 12),
+ [MT8167_MMSYS_SW0_RST_B_DISP_RDMA1] = MMSYS_RST_NR(0, 13),
+ [MT8167_MMSYS_SW0_RST_B_DISP_WDMA0] = MMSYS_RST_NR(0, 14),
+ [MT8167_MMSYS_SW0_RST_B_DISP_COLOR] = MMSYS_RST_NR(0, 15),
+ [MT8167_MMSYS_SW0_RST_B_DISP_CCORR] = MMSYS_RST_NR(0, 16),
+ [MT8167_MMSYS_SW0_RST_B_DISP_AAL] = MMSYS_RST_NR(0, 17),
+ [MT8167_MMSYS_SW0_RST_B_DISP_GAMMA] = MMSYS_RST_NR(0, 18),
+ [MT8167_MMSYS_SW0_RST_B_DISP_DITHER] = MMSYS_RST_NR(0, 19),
+ [MT8167_MMSYS_SW0_RST_B_DISP_UFOE] = MMSYS_RST_NR(0, 20),
+ [MT8167_MMSYS_SW0_RST_B_DISP_PWM] = MMSYS_RST_NR(0, 21),
+ [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),
+};
+
#define MT8167_DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x030
#define MT8167_DISP_REG_CONFIG_DISP_DITHER_MOUT_EN 0x038
#define MT8167_DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x058
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 2f3e0778bb17..abd96634b63c 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -57,6 +57,9 @@ static const struct mtk_mmsys_driver_data mt8167_mmsys_driver_data = {
.clk_driver = "clk-mt8167-mm",
.routes = mt8167_mmsys_routing_table,
.num_routes = ARRAY_SIZE(mt8167_mmsys_routing_table),
+ .sw0_rst_offset = MT8167_MMSYS_SW0_RST_B,
+ .rst_tb = mmsys_mt8167_rst_tb,
+ .num_resets = ARRAY_SIZE(mmsys_mt8167_rst_tb),
};
static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
--
2.43.0
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: mt8167: Properly describe the SoC watchdog
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
which in turn falls back on mt6589-wdt. However according to the data
sheet mt8167 has 15 sw resets instead of 12, and the reset bits are
different from mt6589.
Use the dedicated mediatek,mt8167-wdt compatible for the watchdog driver,
as it correctly describes the SoC resets.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 27cf32d7ae35..4ebf305c10fe 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -95,6 +95,13 @@ power-domain@MT8167_POWER_DOMAIN_CONN {
};
};
+ watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8167-wdt";
+ reg = <0 0x10007000 0 0x1000>;
+ interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
+ #reset-cells = <1>;
+ };
+
pio: pinctrl@1000b000 {
compatible = "mediatek,mt8167-pinctrl";
reg = <0 0x1000b000 0 0x1000>;
--
2.43.0
^ permalink raw reply related
* [PATCH 5/7] watchdog: mediatek: Add support for mt8167 TOPRGU/WDT
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
Add support for the Top Reset Generation Unit/Watchdog Timer found on
mt8167.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
drivers/watchdog/mtk_wdt.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index e61f6ae74327..10a3d4b5ee30 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -13,6 +13,7 @@
#include <dt-bindings/reset/mediatek,mt6589-resets.h>
#include <dt-bindings/reset/mediatek,mt6735-wdt.h>
#include <dt-bindings/reset/mediatek,mt6795-resets.h>
+#include <dt-bindings/reset/mediatek,mt8167-resets.h>
#include <dt-bindings/reset/mt7986-resets.h>
#include <dt-bindings/reset/mt8183-resets.h>
#include <dt-bindings/reset/mt8186-resets.h>
@@ -110,6 +111,10 @@ static const struct mtk_wdt_data mt7988_data = {
.has_swsysrst_en = true,
};
+static const struct mtk_wdt_data mt8167_data = {
+ .toprgu_sw_rst_num = MT8167_TOPRGU_SW_RST_NUM,
+};
+
static const struct mtk_wdt_data mt8183_data = {
.toprgu_sw_rst_num = MT8183_TOPRGU_SW_RST_NUM,
};
@@ -503,6 +508,7 @@ static const struct of_device_id mtk_wdt_dt_ids[] = {
{ .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data },
{ .compatible = "mediatek,mt7986-wdt", .data = &mt7986_data },
{ .compatible = "mediatek,mt7988-wdt", .data = &mt7988_data },
+ { .compatible = "mediatek,mt8167-wdt", .data = &mt8167_data },
{ .compatible = "mediatek,mt8183-wdt", .data = &mt8183_data },
{ .compatible = "mediatek,mt8186-wdt", .data = &mt8186_data },
{ .compatible = "mediatek,mt8188-wdt", .data = &mt8188_data },
--
2.43.0
^ permalink raw reply related
* [PATCH 4/7] dt-bindings: reset: Add reset controller constants for mt8167
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
Add the various bits that identify watchdog and mmsys resets. IDs for
mmsys resets restart from zero as they are used in a different device.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../reset/mediatek,mt8167-resets.h | 53 +++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 include/dt-bindings/reset/mediatek,mt8167-resets.h
diff --git a/include/dt-bindings/reset/mediatek,mt8167-resets.h b/include/dt-bindings/reset/mediatek,mt8167-resets.h
new file mode 100644
index 000000000000..85d2d0e99c68
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt8167-resets.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT8167
+#define _DT_BINDINGS_RESET_CONTROLLER_MT8167
+
+/* TOPRGU resets, these are actual bits in the register */
+#define MT8167_TOPRGU_DDRPHY_FLASH_RST 0
+#define MT8167_TOPRGU_AUD_PAD_RST 1
+#define MT8167_TOPRGU_MM_RST 2
+#define MT8167_TOPRGU_MFG_RST 3
+#define MT8167_TOPRGU_MDSYS_RST 4
+#define MT8167_TOPRGU_CONN_RST 5
+#define MT8167_TOPRGU_PAD2CAM_DIG_MIPI_RX_RST 6
+#define MT8167_TOPRGU_DIG_MIPI_TX_RST 7
+#define MT8167_TOPRGU_SPI_PAD_MACRO_RST 8
+/* bit 9 is reserved, unused according to data sheet */
+#define MT8167_TOPRGU_APMIXED_RST 10
+#define MT8167_TOPRGU_VDEC_RST 11
+#define MT8167_TOPRGU_CONN_MCU_RST 12
+#define MT8167_TOPRGU_EFUSE_RST 13
+#define MT8167_TOPRGU_PWRAP_SPICTL_RST 14
+#define MT8167_TOPRGU_SW_RST_NUM 15
+
+/* MMSYS resets, these are IDs */
+#define MT8167_MMSYS_SW0_RST_B_SMI_COMMON 0
+#define MT8167_MMSYS_SW0_RST_B_SMI_LARB0 1
+#define MT8167_MMSYS_SW0_RST_B_CAM_MDP 2
+#define MT8167_MMSYS_SW0_RST_B_MDP_RDMA0 3
+#define MT8167_MMSYS_SW0_RST_B_MDP_RSZ0 4
+#define MT8167_MMSYS_SW0_RST_B_MDP_RSZ1 5
+#define MT8167_MMSYS_SW0_RST_B_MDP_TDSHP0 6
+#define MT8167_MMSYS_SW0_RST_B_MDP_WDMA 7
+#define MT8167_MMSYS_SW0_RST_B_MDP_WROT0 8
+#define MT8167_MMSYS_SW0_RST_B_FAKE_ENG 9
+#define MT8167_MMSYS_SW0_RST_B_MUTEX 10
+#define MT8167_MMSYS_SW0_RST_B_DISP_OVL0 11
+#define MT8167_MMSYS_SW0_RST_B_DISP_RDMA0 12
+#define MT8167_MMSYS_SW0_RST_B_DISP_RDMA1 13
+#define MT8167_MMSYS_SW0_RST_B_DISP_WDMA0 14
+#define MT8167_MMSYS_SW0_RST_B_DISP_COLOR 15
+#define MT8167_MMSYS_SW0_RST_B_DISP_CCORR 16
+#define MT8167_MMSYS_SW0_RST_B_DISP_AAL 17
+#define MT8167_MMSYS_SW0_RST_B_DISP_GAMMA 18
+#define MT8167_MMSYS_SW0_RST_B_DISP_DITHER 19
+#define MT8167_MMSYS_SW0_RST_B_DISP_UFOE 20
+#define MT8167_MMSYS_SW0_RST_B_DISP_PWM 21
+#define MT8167_MMSYS_SW0_RST_B_DSI0 22
+#define MT8167_MMSYS_SW0_RST_B_DPI0 23
+#define MT8167_MMSYS_SW0_RST_B_MIPI_TX_CONFIG 24
+#define MT8167_MMSYS_SW1_RST_B_LVDS_ENCODER 25
+#define MT8167_MMSYS_SW1_RST_B_DPI1 26
+#define MT8167_MMSYS_SW1_RST_B_HDMI 27
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8167 */
--
2.43.0
^ permalink raw reply related
* [PATCH 3/7] dt-bindings: watchdog: Add compatible for MediaTek mt8167
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
which in turn falls back on mt6589-wdt. However according to the data
sheet mt8167 has 15 sw resets instead of 12, and their order is different
from mt6589. Update the wdt binding to add a dedicated compatible for
mt8167.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 953629cb9558..f514be8a5851 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -26,6 +26,7 @@ properties:
- mediatek,mt6795-wdt
- mediatek,mt7986-wdt
- mediatek,mt7988-wdt
+ - mediatek,mt8167-wdt
- mediatek,mt8183-wdt
- mediatek,mt8186-wdt
- mediatek,mt8188-wdt
--
2.43.0
^ permalink raw reply related
* [PATCH 2/7] watchdog: mediatek: Add wdt/toprgu resets for MT6589
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
According to Android sources, MT6589 has 12 reset bits in the
WDT_SWSYSRST register. Populate toprgu_sw_rst_num to allow toprgu resets
in device trees of the many compatible devices.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
drivers/watchdog/mtk_wdt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 91d110646e16..e61f6ae74327 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -10,6 +10,7 @@
*/
#include <dt-bindings/reset/mt2712-resets.h>
+#include <dt-bindings/reset/mediatek,mt6589-resets.h>
#include <dt-bindings/reset/mediatek,mt6735-wdt.h>
#include <dt-bindings/reset/mediatek,mt6795-resets.h>
#include <dt-bindings/reset/mt7986-resets.h>
@@ -88,6 +89,10 @@ static const struct mtk_wdt_data mt2712_data = {
.toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM,
};
+static const struct mtk_wdt_data mt6589_data = {
+ .toprgu_sw_rst_num = MT6589_TOPRGU_SW_RST_NUM,
+};
+
static const struct mtk_wdt_data mt6735_data = {
.toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM,
};
@@ -493,7 +498,7 @@ static int mtk_wdt_resume(struct device *dev)
static const struct of_device_id mtk_wdt_dt_ids[] = {
{ .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data },
- { .compatible = "mediatek,mt6589-wdt" },
+ { .compatible = "mediatek,mt6589-wdt", .data = &mt6589_data },
{ .compatible = "mediatek,mt6735-wdt", .data = &mt6735_data },
{ .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data },
{ .compatible = "mediatek,mt7986-wdt", .data = &mt7986_data },
--
2.43.0
^ permalink raw reply related
* [PATCH 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260717151134.678839-1-l.scorcia@gmail.com>
Add reset constants for the 12 MT6589 toprgu resets.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../reset/mediatek,mt6589-resets.h | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 include/dt-bindings/reset/mediatek,mt6589-resets.h
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 000000000000..ee08c39df513
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt6589-resets.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT6589
+#define _DT_BINDINGS_RESET_CONTROLLER_MT6589
+
+/* TOPRGU resets */
+#define MT6589_TOPRGU_INFRA_SW_RST 0
+#define MT6589_TOPRGU_MM_SW_RST 1
+#define MT6589_TOPRGU_MFG_SW_RST 2
+#define MT6589_TOPRGU_VENC_SW_RST 3
+#define MT6589_TOPRGU_VDEC_SW_RST 4
+#define MT6589_TOPRGU_IMG_SW_RST 5
+#define MT6589_TOPRGU_DDRPHY_SW_RST 6
+#define MT6589_TOPRGU_MD_SW_RST 7
+#define MT6589_TOPRGU_INFRA_AO_SW_RST 8
+#define MT6589_TOPRGU_MD_LITE_SW_RST 9
+#define MT6589_TOPRGU_APMIXED_SW_RST 10
+#define MT6589_TOPRGU_PWRAP_SPI_CTL_RST 11
+#define MT6589_TOPRGU_SW_RST_NUM 12
+
+#endif /* _DT_BINDINGS_RESET_CONTROLLER_MT6589 */
--
2.43.0
^ permalink raw reply related
* [PATCH 0/7] Properly describe mt8167 watchdog and mmsys resets
From: Luca Leonardo Scorcia @ 2026-07-17 15:11 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
which in turn falls back on mt6589-wdt. However according to the data
sheet mt8167 has 15 sw resets instead of 12, and the reset bits are
different from mt6589.
In the first two patches we improve the description of the resets for
mt6589 with values obtained from Android sources.
Then we introduce a dedicated mediatek,mt8167-wdt compatible for the
watchdog driver that describes correctly this SoC's resets. Also while
we're touching the bindings reset header, we add constants for the MMSYS
resets.
In the 6th patch we add a node for the mt8167 watchdog referring to the
new compatible in the SoC dtsi.
In the last patch, we define the mmsys reset table for the SoC. According
to the datasheet, there are 28 mmsys reset bits divided across two
adjacent registers.
Luca Leonardo Scorcia (7):
dt-bindings: reset: Add MT6589 toprgu reset IDs
watchdog: mediatek: Add wdt/toprgu resets for MT6589
dt-bindings: watchdog: Add compatible for MediaTek mt8167
dt-bindings: reset: Add reset controller constants for mt8167
watchdog: mediatek: Add support for mt8167 TOPRGU/WDT
arm64: dts: mt8167: Properly describe the SoC watchdog
soc: mediatek: mtk-mmsys: Add resets for mt8167
.../bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 7 +++
drivers/soc/mediatek/mt8167-mmsys.h | 40 ++++++++++++++
drivers/soc/mediatek/mtk-mmsys.c | 3 ++
drivers/watchdog/mtk_wdt.c | 13 ++++-
.../reset/mediatek,mt6589-resets.h | 24 +++++++++
.../reset/mediatek,mt8167-resets.h | 53 +++++++++++++++++++
7 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/reset/mediatek,mt6589-resets.h
create mode 100644 include/dt-bindings/reset/mediatek,mt8167-resets.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH 3/4] firmware: qcom: scm: Allow QSEECOM on the Glymur QCB
From: Mukesh Ojha @ 2026-07-17 15:04 UTC (permalink / raw)
To: Gopikrishna Garmidi
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Anvesh Jain P, Sibi Sankar, Pankaj Patil,
Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260717-glymur-qcb-v1-3-aaf1cff84aab@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 04:54:11AM -0700, Gopikrishna Garmidi wrote:
> Add Glymur QCB board to the QSEECOM allowlist for enabling access to
> efivars and uefi bootloader.
>
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
> drivers/firmware/qcom/qcom_scm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index f35f2ee39130..e0ea40b4302c 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2326,6 +2326,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
> { .compatible = "microsoft,romulus13", },
> { .compatible = "microsoft,romulus15", },
> { .compatible = "qcom,glymur-crd" },
> + { .compatible = "qcom,glymur-qcb" },
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 2/4] drm/bridge: display-connector: Fix I2C adapter resource leak
From: Johan Hovold @ 2026-07-17 15:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel, devicetree, Thuan Nguyen, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, linux-renesas-soc,
stable
In-Reply-To: <20260705213542.28987-3-laurent.pinchart+renesas@ideasonboard.com>
On Mon, Jul 06, 2026 at 12:35:40AM +0300, Laurent Pinchart wrote:
> If the probe function returns an error after getting the I2C adapter for
> DDC, the reference to the adapter is never released. Fix it by releasing
> it in the bridge .destroy() handler.
>
> There is no need to test the ddc pointer with !IS_ERR(), as
> of_get_i2c_adapter_by_node() returns NULL on error.
I stumbled over this this morning as well and posted a fix here (which
releases the adapter on driver unbind as is currently done):
https://lore.kernel.org/lkml/20260717085716.1619275-1-johan@kernel.org/
> Fixes: 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio support")
I believe this issue was first introduced by commit 2e2bf3a5584d
("drm/bridge: display-connector: add DP support") a few releases
earlier.
> Cc: stable@vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* Re: [PATCH v4 4/5] mfd: axp20x-i2c: Fix i2c instantiation
From: sashiko-bot @ 2026-07-17 14:54 UTC (permalink / raw)
To: Jerome Brunet; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260717-axp318-regulator-v4-4-50aff97084dd@baylibre.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing Error Handling / API Ambiguity causing unmatched devices to probe as AXP152.
- [High] MFD subsystem guideline violation: Hard-coded IDs used in mfd_cell array instead of PLATFORM_DEVID_AUTO.
--
--- Patch [4]: [PATCH v4 4/5] mfd: axp20x-i2c: Fix i2c instantiation ---
commit df6eff33eb956b610bd8100dff8a5beb1887390f
Author: Jerome Brunet <jbrunet@baylibre.com>
mfd: axp20x-i2c: Fix i2c instantiation
This patch fixes I2C instantiation for the AXP20X driver by moving the
variant matching directly into the bus-specific probes. It also adds support
for the AXP323 device.
Link: https://lore.kernel.org/r/20260717090209.2A09B1F000E9@smtp.kernel.org
> diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
> index 4e4ebfc78525c..64c212b76e5e6 100644
> --- a/drivers/mfd/axp20x-i2c.c
> +++ b/drivers/mfd/axp20x-i2c.c
> @@ -35,6 +35,7 @@ static int axp20x_i2c_probe(struct i2c_client *i2c)
> axp20x->irq = i2c->irq;
> dev_set_drvdata(axp20x->dev, axp20x);
>
> + axp20x->variant = (kernel_ulong_t)i2c_get_match_data(i2c);
[Severity: High]
This isn't a bug introduced by this patch, but because AXP152_ID is defined
as 0, a match failure returning NULL is indistinguishable from a successful
AXP152 match.
Since the driver blindly defaults to AXP152_ID on NULL, it could configure
an unrelated device as an AXP152 PMIC if forced via a sysfs bind. Writing
PMIC configurations to an unrelated I2C device can result in hardware
damage or system crashes.
Should the variant IDs be updated to start from 1 to allow unambiguous
error checking?
> ret = axp20x_match_device(axp20x);
> if (ret)
> return ret;
[ ... ]
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 2bbe73afff435..25509e47bedc8 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -1339,7 +1339,6 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> const struct mfd_cell *cells_no_irq = NULL;
> int nr_cells_no_irq = 0;
>
> - axp20x->variant = (long)device_get_match_data(dev);
> switch (axp20x->variant) {
> case AXP152_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp152_cells);
[Severity: High]
This is a pre-existing issue, but there are hard-coded IDs used in the
mfd_cell arrays defined in this file:
drivers/mfd/axp20x.c:axp806_cells[] = {
{
.id = 2,
.name = "axp20x-regulator",
},
};
Using hard-coded IDs in the mfd_cell array bypasses standard subsystem
indexing. This can lead to device naming collisions in sysfs and driver
load failures. A regulator driver load failure here could cause critical
power domains to remain uninitialized, leading to an unusable system.
Would it be possible to use PLATFORM_DEVID_AUTO in mfd_add_devices and
avoid hard-coded id fields in the mfd_cell arrays?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-axp318-regulator-v4-0-50aff97084dd@baylibre.com?part=4
^ permalink raw reply
* Re: [PATCH 4/4] riscv: dts: spacemit: enable SPI0 on K3 CoM260-IFX
From: sashiko-bot @ 2026-07-17 14:51 UTC (permalink / raw)
To: Zhengyu He; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-4-969a1b0f783f@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The commit message claims to describe a SPI NOR flash chip on chip select 0, but the corresponding device tree node is absent.
- [Medium] The pinctrl configuration sets the SPI pad voltage to 1.8V, which conflicts with the 3.3V Winbond W25Q64JV SPI NOR flash mentioned in the commit message.
--
--- Patch [4]: [PATCH 4/4] riscv: dts: spacemit: enable SPI0 on K3 CoM260-IFX ---
commit 195bf5fbf14f1dbf36d3f0697603287770b0c9db
Author: Zhengyu He <hezhy472013@gmail.com>
riscv: dts: spacemit: enable SPI0 on K3 CoM260-IFX
This commit enables the PDMA controller and SPI0 on the K3 CoM260-IFX board.
It also adds the pinctrl states for the SPI0 pins exposed on the board's 40-pin
header.
> diff --git a/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts b/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts
> --- a/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts
> +++ b/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts
[ ... ]
> +&spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ssp0_2_cfg>;
> + status = "okay";
> +};
[Severity: Medium]
The commit message states this patch will "describe the SPI NOR on chip select
0 for the current validation setup", but is the child node for the flash chip
missing here?
> diff --git a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
> --- a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
[ ... ]
> + /omit-if-no-ref/
> + ssp0_2_cfg: ssp0-2-cfg {
> + ssp0-0-pins {
> + pinmux = <K3_PADCONF(104, 1)>, /* ssp0 tx */
> + <K3_PADCONF(105, 1)>, /* ssp0 rx */
> + <K3_PADCONF(106, 1)>; /* ssp0 clk */
> +
> + bias-disable;
> + drive-strength = <25>;
> + power-source = <1800>;
[Severity: Medium]
Does this 1.8V power source configuration match the validation setup described
in the commit message?
The commit message mentions testing with a Winbond W25Q64JV, which is a 3.3V
component (the 1.8V equivalent is the W25Q64JW). If the SoC IO is driving
1.8V signals without a level shifter, it might fail to meet the 3.3V chip's
input high voltage thresholds. Could this be a typo in the commit message, or
is the power-source value incorrect for this board?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: axp20x: Add support for AXP318W PMIC
From: sashiko-bot @ 2026-07-17 14:48 UTC (permalink / raw)
To: Jerome Brunet; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260717-axp318-regulator-v4-2-50aff97084dd@baylibre.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The system power-off handler `axp20x_power_off()` is missing a switch case for `AXP318_ID`, causing it to write the power-off command to a regulator control register.
- [Medium] The newly added `axp318_cells` array uses a hardcoded cell ID instead of `PLATFORM_DEVID_AUTO`, violating MFD subsystem guidelines.
--
--- Patch [2]: [PATCH v4 2/5] mfd: axp20x: Add support for AXP318W PMIC ---
commit ffbc50262db7d7fef4ebd802fb44cd11951bf0bc
Author: Andre Przywara <andre.przywara@arm.com>
mfd: axp20x: Add support for AXP318W PMIC
This commit adds MFD core support for the X-Powers AXP318W PMIC. It defines
the regmap configurations, IRQs, and child device cells for the regulator.
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 679364189ea58..c8aeebd01bbcd 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
[ ... ]
> @@ -1061,6 +1129,10 @@ static struct mfd_cell axp313a_cells[] = {
> MFD_CELL_RES("axp313a-pek", axp313a_pek_resources),
> };
>
> +static const struct mfd_cell axp318_cells[] = {
> + MFD_CELL_BASIC("axp20x-regulator", NULL, NULL, 0, 1),
[Severity: Medium]
Does this hardcoded cell ID of 1 violate the MFD subsystem guidelines?
If multiple AXP devices with hardcoded IDs of 1 (such as the AXP313a and
AXP318W) are instantiated on the same system, could they both attempt to
register a platform device named axp20x-regulator.1, resulting in a fatal
-EEXIST failure?
Should this use PLATFORM_DEVID_AUTO instead?
> +};
> +
> static struct mfd_cell axp717_cells[] = {
> MFD_CELL_NAME("axp20x-regulator"),
[ ... ]
> @@ -1313,6 +1385,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_cfg = &axp313a_regmap_config;
> axp20x->regmap_irq_chip = &axp313a_regmap_irq_chip;
> break;
> + case AXP318_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp318_cells);
> + axp20x->cells = axp318_cells;
> + axp20x->regmap_cfg = &axp318_regmap_config;
> + axp20x->regmap_irq_chip = &axp318_regmap_irq_chip;
> + break;
[Severity: High]
Is AXP318_ID missing from the switch statement in axp20x_power_off()?
When the system attempts to power off, axp20x_power_off() is called. If
AXP318_ID is not handled in the switch statement there, will it fall through
to the default case and select AXP20X_OFF_CTRL (0x32) instead of the correct
AXP318_SHUTDOWN_CTRL (0x52)?
Could this failure to shut down the PMIC corrupt the state of the CLDO4
regulator by writing the power-off command to AXP318_CLDO4_CONTROL (which
is also 0x32)?
> case AXP323_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp313a_cells);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-axp318-regulator-v4-0-50aff97084dd@baylibre.com?part=2
^ permalink raw reply
* [PATCH 4/4] riscv: dts: spacemit: enable SPI0 on K3 CoM260-IFX
From: Zhengyu He @ 2026-07-17 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Mark Brown,
Alex Elder
Cc: devicetree, linux-riscv, spacemit, linux-kernel, linux-spi,
Zhengyu He, wefu, Cody Kang
In-Reply-To: <20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com>
SPI0 is the first enabled PDMA consumer on CoM260-IFX, so enable the
PDMA controller together with SPI0.
The board exposes SPI0 on its 40-pin header:
pin 19: MOSI
pin 21: MISO
pin 23: SCLK
pin 24: CS0
Define the pinctrl state used by this header wiring, and describe the SPI
NOR on chip select 0 for the current validation setup.
(This was tested using a Winbond W25Q64JV SPI NOR chip.)
Signed-off-by: Cody Kang <cody.kang.hk@outlook.com>
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
---
arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts | 13 ++++++++++++-
arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi | 21 +++++++++++++++++++++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts b/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts
index 238bb03d0e9e..01a7135df864 100644
--- a/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts
+++ b/arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts
@@ -11,11 +11,22 @@ / {
compatible = "spacemit,k3-com260-ifx", "spacemit,k3-com260", "spacemit,k3";
aliases {
- serial0 = &uart0;
ethernet0 = ð1;
+ serial0 = &uart0;
+ spi0 = &spi0;
};
chosen {
stdout-path = "serial0:115200n8";
};
};
+
+&pdma {
+ status = "okay";
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ssp0_2_cfg>;
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
index 3ee1471f3798..9b7617f3846c 100644
--- a/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi
@@ -679,6 +679,27 @@ pwm19-2-pins {
};
};
+ /omit-if-no-ref/
+ ssp0_2_cfg: ssp0-2-cfg {
+ ssp0-0-pins {
+ pinmux = <K3_PADCONF(104, 1)>, /* ssp0 tx */
+ <K3_PADCONF(105, 1)>, /* ssp0 rx */
+ <K3_PADCONF(106, 1)>; /* ssp0 clk */
+
+ bias-disable;
+ drive-strength = <25>;
+ power-source = <1800>;
+ };
+
+ ssp0-1-pins {
+ pinmux = <K3_PADCONF(107, 1)>; /* ssp0 frm */
+
+ bias-pull-up = <0>;
+ drive-strength = <25>;
+ power-source = <1800>;
+ };
+ };
+
/omit-if-no-ref/
uart0_0_cfg: uart0-0-cfg {
uart0-0-pins {
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] riscv: dts: spacemit: add SPI controllers for K3
From: Zhengyu He @ 2026-07-17 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Mark Brown,
Alex Elder
Cc: devicetree, linux-riscv, spacemit, linux-kernel, linux-spi,
Zhengyu He, wefu, Cody Kang
In-Reply-To: <20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com>
Add the SPI controller nodes for K3.
Signed-off-by: Cody Kang <cody.kang.hk@outlook.com>
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
---
arch/riscv/boot/dts/spacemit/k3.dtsi | 49 +++++++++++++++++++++++++++++++++++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
index 19fc9b49668e..dc44b5c77d41 100644
--- a/arch/riscv/boot/dts/spacemit/k3.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -5,8 +5,10 @@
*/
#include <dt-bindings/clock/spacemit,k3-clocks.h>
-#include <dt-bindings/reset/spacemit,k3-resets.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/reset/spacemit,k3-resets.h>
+
+#include "k3-pdma.h"
/dts-v1/;
@@ -927,6 +929,21 @@ pwm7: pwm@d401bc00 {
status = "disabled";
};
+ spi3: spi@d401c000 {
+ compatible = "spacemit,k3-spi", "spacemit,k1-spi";
+ reg = <0x0 0xd401c000 0x0 0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&syscon_apbc CLK_APBC_SPI3>,
+ <&syscon_apbc CLK_APBC_SPI3_BUS>;
+ clock-names = "core", "bus";
+ resets = <&syscon_apbc RESET_APBC_SPI3>;
+ interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&pdma K3_PDMA_SSP3_RX>, <&pdma K3_PDMA_SSP3_TX>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
pwm8: pwm@d4020000 {
compatible = "spacemit,k3-pwm", "marvell,pxa910-pwm";
reg = <0x0 0xd4020000 0x0 0x10>;
@@ -1081,6 +1098,36 @@ uart10: serial@d401f000 {
status = "disabled";
};
+ spi0: spi@d4040000 {
+ compatible = "spacemit,k3-spi", "spacemit,k1-spi";
+ reg = <0x0 0xd4040000 0x0 0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&syscon_apbc CLK_APBC_SPI0>,
+ <&syscon_apbc CLK_APBC_SPI0_BUS>;
+ clock-names = "core", "bus";
+ resets = <&syscon_apbc RESET_APBC_SPI0>;
+ interrupts = <283 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&pdma K3_PDMA_SSP0_RX>, <&pdma K3_PDMA_SSP0_TX>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ spi1: spi@d4040800 {
+ compatible = "spacemit,k3-spi", "spacemit,k1-spi";
+ reg = <0x0 0xd4040800 0x0 0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&syscon_apbc CLK_APBC_SPI1>,
+ <&syscon_apbc CLK_APBC_SPI1_BUS>;
+ clock-names = "core", "bus";
+ resets = <&syscon_apbc RESET_APBC_SPI1>;
+ interrupts = <282 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&pdma K3_PDMA_SSP1_RX>, <&pdma K3_PDMA_SSP1_TX>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
syscon_mpmu: system-controller@d4050000 {
compatible = "spacemit,k3-syscon-mpmu";
reg = <0x0 0xd4050000 0x0 0x10000>;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] spi: dt-bindings: spacemit: add K3 SPI compatible
From: Zhengyu He @ 2026-07-17 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Mark Brown,
Alex Elder
Cc: devicetree, linux-riscv, spacemit, linux-kernel, linux-spi,
Zhengyu He, wefu, Cody Kang
In-Reply-To: <20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com>
The K3 SPI controller is compatible with K1, so allow K3 device trees to
use "spacemit,k1-spi" as fallback.
Signed-off-by: Cody Kang <cody.kang.hk@outlook.com>
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
---
Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
index e82c7f8d0b98..5d86cc87e4fb 100644
--- a/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
@@ -24,7 +24,11 @@ allOf:
properties:
compatible:
- const: spacemit,k1-spi
+ oneOf:
+ - const: spacemit,k1-spi
+ - items:
+ - const: spacemit,k3-spi
+ - const: spacemit,k1-spi
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* [PATCH 1/4] riscv: dts: spacemit: add K3 PDMA request numbers
From: Zhengyu He @ 2026-07-17 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Mark Brown,
Alex Elder
Cc: devicetree, linux-riscv, spacemit, linux-kernel, linux-spi,
Zhengyu He, wefu, liyeshan, Guodong Xu
In-Reply-To: <20260717-k3-com260-spi-v7-2-rc2-b4-preview-20260716-v1-0-969a1b0f783f@gmail.com>
From: liyeshan <yeshan.li@spacemit.com>
Add a local DTS header that gives symbolic names to the SpacemiT K3
PDMA request lines of the non-secure peripherals. Device trees can use
these K3_PDMA_* macros instead of hard-coded request numbers when wiring
a peripheral "dmas" property.
Signed-off-by: liyeshan <yeshan.li@spacemit.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
---
arch/riscv/boot/dts/spacemit/k3-pdma.h | 83 ++++++++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k3-pdma.h b/arch/riscv/boot/dts/spacemit/k3-pdma.h
new file mode 100644
index 000000000000..a5b723ad616a
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-pdma.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * DMA request number (DRQ) definitions for non-secure peripherals of
+ * the SpacemiT K3 PDMA.
+ *
+ * Copyright (c) 2025 SpacemiT
+ * Copyright (c) 2026 Guodong Xu <docular.xu@gmail.com>
+ */
+
+#ifndef _DTS_SPACEMIT_K3_PDMA_H
+#define _DTS_SPACEMIT_K3_PDMA_H
+
+/* UART DMA request numbers */
+#define K3_PDMA_UART0_TX 3
+#define K3_PDMA_UART0_RX 4
+#define K3_PDMA_UART2_TX 5
+#define K3_PDMA_UART2_RX 6
+#define K3_PDMA_UART3_TX 7
+#define K3_PDMA_UART3_RX 8
+#define K3_PDMA_UART4_TX 9
+#define K3_PDMA_UART4_RX 10
+#define K3_PDMA_UART5_TX 25
+#define K3_PDMA_UART5_RX 26
+#define K3_PDMA_UART6_TX 27
+#define K3_PDMA_UART6_RX 28
+#define K3_PDMA_UART7_TX 29
+#define K3_PDMA_UART7_RX 30
+#define K3_PDMA_UART8_TX 31
+#define K3_PDMA_UART8_RX 32
+#define K3_PDMA_UART9_TX 33
+#define K3_PDMA_UART9_RX 34
+#define K3_PDMA_UART10_TX 53
+#define K3_PDMA_UART10_RX 54
+
+/* I2C DMA request numbers */
+#define K3_PDMA_I2C0_TX 11
+#define K3_PDMA_I2C0_RX 12
+#define K3_PDMA_I2C1_TX 13
+#define K3_PDMA_I2C1_RX 14
+#define K3_PDMA_I2C2_TX 15
+#define K3_PDMA_I2C2_RX 16
+#define K3_PDMA_I2C4_TX 17
+#define K3_PDMA_I2C4_RX 18
+#define K3_PDMA_I2C5_TX 35
+#define K3_PDMA_I2C5_RX 36
+#define K3_PDMA_I2C6_TX 37
+#define K3_PDMA_I2C6_RX 38
+#define K3_PDMA_I2C8_TX 41
+#define K3_PDMA_I2C8_RX 42
+
+/* SSP/SPI DMA request numbers */
+#define K3_PDMA_SSP3_TX 19
+#define K3_PDMA_SSP3_RX 20
+#define K3_PDMA_SSPA0_TX 21
+#define K3_PDMA_SSPA0_RX 22
+#define K3_PDMA_SSPA1_TX 23
+#define K3_PDMA_SSPA1_RX 24
+#define K3_PDMA_SSPA2_TX 56
+#define K3_PDMA_SSPA2_RX 57
+#define K3_PDMA_SSPA3_TX 58
+#define K3_PDMA_SSPA3_RX 59
+#define K3_PDMA_SSPA4_TX 60
+#define K3_PDMA_SSPA4_RX 61
+#define K3_PDMA_SSPA5_TX 62
+#define K3_PDMA_SSPA5_RX 63
+
+/* CAN DMA request numbers */
+#define K3_PDMA_CAN0_RX 43
+#define K3_PDMA_CAN1_RX 44
+#define K3_PDMA_CAN2_RX 51
+#define K3_PDMA_CAN3_RX 52
+
+/* SSP0/1 DMA request numbers */
+#define K3_PDMA_SSP0_TX 64
+#define K3_PDMA_SSP0_RX 65
+#define K3_PDMA_SSP1_TX 66
+#define K3_PDMA_SSP1_RX 67
+
+/* QSPI DMA request numbers */
+#define K3_PDMA_QSPI_RX 84
+#define K3_PDMA_QSPI_TX 85
+
+#endif /* _DTS_SPACEMIT_K3_PDMA_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] spi: spacemit: support K3 SPI controllers
From: Zhengyu He @ 2026-07-17 14:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Mark Brown,
Alex Elder
Cc: devicetree, linux-riscv, spacemit, linux-kernel, linux-spi,
Zhengyu He, wefu, liyeshan, Guodong Xu, Cody Kang
This series adds K3 PDMA request numbers, documents the K3 SPI
compatible, and enables SPI0 on the K3 CoM260-IFX.
This series is available here:
https://github.com/imguoguo/linux/tree/k3-com260-spi-v1
This series is based on v7.2-rc2.
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
---
Zhengyu He (3):
spi: dt-bindings: spacemit: add K3 SPI compatible
riscv: dts: spacemit: add SPI controllers for K3
riscv: dts: spacemit: enable SPI0 on K3 CoM260-IFX
liyeshan (1):
riscv: dts: spacemit: add K3 PDMA request numbers
.../devicetree/bindings/spi/spacemit,k1-spi.yaml | 6 +-
arch/riscv/boot/dts/spacemit/k3-com260-ifx.dts | 13 +++-
arch/riscv/boot/dts/spacemit/k3-pdma.h | 83 ++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k3-pinctrl.dtsi | 21 ++++++
arch/riscv/boot/dts/spacemit/k3.dtsi | 49 ++++++++++++-
5 files changed, 169 insertions(+), 3 deletions(-)
---
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
change-id: 20260716-k3-com260-spi-v7-2-rc2-b4-preview-20260716-077f86d144f0
Best regards,
--
Zhengyu He <hezhy472013@gmail.com>
^ permalink raw reply
* Re: [PATCH v4 03/11] power: sequencing: Add pwrseq_is_controllable() API
From: Loic Poulain @ 2026-07-17 14:45 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Marcel Holtmann, Luiz Augusto von Dentz, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <CAMRc=Md8mLgYRsLd-KhwVV8X9AcYbHf--RB_pf0xFBP_P_DvCQ@mail.gmail.com>
Hi Bartosz,
On Fri, Jul 17, 2026 at 11:29 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Thu, 16 Jul 2026 18:18:20 +0200, Loic Poulain
> <loic.poulain@oss.qualcomm.com> said:
> > On some boards a power sequencing target has no host-controllable enable
> > for its function, for instance when the enable line is not wired up to a
> > GPIO and is hardwired to an always-on level. The pcie-m2 "uart" target is
> > one such example: when the M.2 connector does not route the W_DISABLE2#
> > signal to a host GPIO, its enable/disable are no-ops and the consumer
> > cannot gate the Bluetooth function at all or exclusively.
> >
> > Add a generic pwrseq_is_controllable() helper. It reports whether the
> > target's final unit provides a host-controllable dedicated power actuator.
> > The target can implement a new optional is_controllable() callback,
> > reporting whether that actuator is effective on this target (for example
> > depending on GPIO presence). If the target does not provide the callback,
> > it is assumed to be controllable.
> >
> > Note this only describes the target's own enable actuator. It does not
> > imply that a power-off reaches an electrical OFF state, since a target may
> > have multiple consumers. It also does not mean that power is uncontrolled
> > for the target's dependencies: those may still be gated on their own. And
> > it does not restrict consumers from calling pwrseq_power_off() either,
> > which remains valid to drop this consumer's vote on the (possibly shared)
> > resources and dependencies of the target.
> >
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
>
> Thanks, this looks good to me now. This series is a bit all over the place,
> what is the merge strategy?
Since the entire series ultimately depends/touch on the pwrseq topic,
the simplest approach may be to take it all through your pwrseq
branch, with the possible exception of the DTS patches (through
Bjorn)?
Regards,
Loic
^ 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