* [PATCH v3 0/3] Add AST2700 USB3.2 PHY driver
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen, Krzysztof Kozlowski
Add AST2700 USB3.2 PHY support.
- Supports Super Speed Plus Gen2x1 (10 Gbps), Super Speed (5 Gbps),
High Speed (480 Mbps), Full Speed (12Mbps), and Low Speed (1.5 Mbps).
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Changes in v3:
- Wire drivers/phy/aspeed/ into drivers/phy/Kconfig and
drivers/phy/Makefile so the driver is actually built.
- Fix the Makefile config symbol to CONFIG_PHY_ASPEED_USB3 to match
the Kconfig symbol.
- Expand the Kconfig help text.
- Link to v2: https://lore.kernel.org/r/20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com
Changes in v2:
- aspeed,ast2700-usb3-phy.yaml
- Drop clocks, resets descripton.
- Kconfig
- add COMPILE_TEST, remove default n
- Link to v1: https://lore.kernel.org/r/20260114-upstream_usb3phy-v1-0-2e59590be2d7@aspeedtech.com
---
Ryan Chen (3):
dt-bindings: phy: aspeed: Document AST2700 USB3.2 PHY
phy: aspeed: Add AST2700 USB3.2 PHY driver
MAINTAINERS: Add ASPEED USB3 PHY driver
.../bindings/phy/aspeed,ast2700-usb3-phy.yaml | 48 +++++
MAINTAINERS | 8 +
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/aspeed/Kconfig | 15 ++
drivers/phy/aspeed/Makefile | 2 +
drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++
7 files changed, 311 insertions(+)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260112-upstream_usb3phy-7116f8dfe779
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: phy: aspeed: Document AST2700 USB3.2 PHY
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen, Krzysztof Kozlowski
In-Reply-To: <20260701-upstream_usb3phy-v3-0-00e12315b6f9@aspeedtech.com>
Document AST2700 USB3.2 PHY. This IP is connected between
USB3 controller and PHY module.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
.../bindings/phy/aspeed,ast2700-usb3-phy.yaml | 48 ++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
new file mode 100644
index 000000000000..b83037aa0438
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/aspeed,ast2700-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2700 USB 3.2 PHY
+
+maintainers:
+ - Ryan Chen <ryan_chen@aspeedtech.com>
+
+properties:
+ compatible:
+ const: aspeed,ast2700-usb3-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed,ast2700-scu.h>
+ #include <dt-bindings/reset/aspeed,ast2700-scu.h>
+
+ usb-phy@12010000 {
+ compatible = "aspeed,ast2700-usb3-phy";
+ reg = <0x12010000 0xc0>;
+ clocks = <&syscon0 SCU0_CLK_GATE_PORTAUSB2CLK>;
+ resets = <&syscon0 SCU0_RESET_PORTA_PHY3>;
+ #phy-cells = <0>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/3] MAINTAINERS: Add ASPEED USB3 PHY driver
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260701-upstream_usb3phy-v3-0-00e12315b6f9@aspeedtech.com>
Add maintainer entry for ASPEED USB3 PHY driver.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 895a87b571c3..10c08f322618 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4062,6 +4062,14 @@ S: Maintained
F: Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml
F: drivers/usb/gadget/udc/aspeed_udc.c
+ASPEED USB3 PHY DRIVER
+M: Ryan Chen <ryan_chen@aspeedtech.com>
+L: linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
+L: linux-phy@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
+F: drivers/phy/aspeed/phy-aspeed-usb3.c
+
ASPEED VIDEO ENGINE DRIVER
M: Eddie James <eajames@linux.ibm.com>
L: linux-media@vger.kernel.org
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/3] phy: aspeed: Add AST2700 USB3.2 PHY driver
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260701-upstream_usb3phy-v3-0-00e12315b6f9@aspeedtech.com>
Add AST2700 USB3.2 PHY driver support.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/aspeed/Kconfig | 15 +++
drivers/phy/aspeed/Makefile | 2 +
drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++++++++++++++++
5 files changed, 255 insertions(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b7d..85fa381978f8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -171,6 +171,7 @@ config PHY_XGENE
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
+source "drivers/phy/aspeed/Kconfig"
source "drivers/phy/axiado/Kconfig"
source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d7aa516bcc49..c6dd02003bbe 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
amlogic/ \
apple/ \
+ aspeed/ \
axiado/ \
broadcom/ \
cadence/ \
diff --git a/drivers/phy/aspeed/Kconfig b/drivers/phy/aspeed/Kconfig
new file mode 100644
index 000000000000..7b5f48db2be8
--- /dev/null
+++ b/drivers/phy/aspeed/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+#
+# PHY drivers for ASPEED
+#
+
+config PHY_ASPEED_USB3
+ tristate "ASPEED USB3 PHY driver"
+ select GENERIC_PHY
+ depends on (ARCH_ASPEED || COMPILE_TEST)
+ help
+ Enable this to support the USB 3.2 PHY on the Aspeed AST2700 SoC.
+ It supports SuperSpeedPlus Gen2x1 (10 Gbps), SuperSpeed (5 Gbps),
+ High Speed (480 Mbps), Full Speed (12 Mbps) and Low Speed
+ (1.5 Mbps), and is paired with the DWC3 USB controller.
diff --git a/drivers/phy/aspeed/Makefile b/drivers/phy/aspeed/Makefile
new file mode 100644
index 000000000000..d96d9d73a009
--- /dev/null
+++ b/drivers/phy/aspeed/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_ASPEED_USB3) += phy-aspeed-usb3.o
diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
new file mode 100644
index 000000000000..eff148faa14c
--- /dev/null
+++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2026 Aspeed Technology Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#define PHY3S00 0x00
+#define PHY3S00_INIT_DONE BIT(15)
+#define PHY3S00_SRAM_BYPASS BIT(7)
+#define PHY3S00_SRAM_EXT_LOAD BIT(6)
+#define PHY3S04 0x04
+#define PHY3C00 0x08
+#define PHY3C04 0x0C
+#define PHY3P00 0x10
+#define PHY3P00_RX_ADAPT_AFE_EN_G1 BIT(0)
+#define PHY3P00_RX_ADAPT_AFE_EN_G2 BIT(1)
+#define PHY3P00_RX_ADAPT_DFE_EN_G1 BIT(2)
+#define PHY3P00_RX_ADAPT_DFE_EN_G2 BIT(3)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G1 BIT(4)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G2 BIT(5)
+#define PHY3P00_RX_EQ_AFE_GAIN_G1 GENMASK(9, 6)
+#define PHY3P00_RX_EQ_AFE_GAIN_G2 GENMASK(13, 10)
+#define PHY3P00_RX_EQ_ATT_LVL_G1 GENMASK(16, 14)
+#define PHY3P00_RX_EQ_ATT_LVL_G2 GENMASK(19, 17)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G1 GENMASK(24, 20)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G2 GENMASK(29, 25)
+#define PHY3P00_RX_EQ_DELTA_IQ_G1_LO GENMASK(31, 30)
+
+#define PHY3P04 0x14
+#define PHY3P04_RX_EQ_DELTA_IQ_G1_HI GENMASK(1, 0)
+#define PHY3P04_RX_EQ_DELTA_IQ_G2 GENMASK(5, 2)
+#define PHY3P04_RX_EQ_DFE_TAP1_G1 GENMASK(13, 6)
+#define PHY3P04_RX_EQ_DFE_TAP1_G2 GENMASK(21, 14)
+#define PHY3P04_RX_LOS_LFPS_EN BIT(22)
+#define PHY3P04_RX_LOS_THRESHOLD GENMASK(25, 23)
+#define PHY3P04_RX_TERM_CTRL GENMASK(28, 26)
+#define PHY3P04_TX_EQ_MAIN_G1_LO GENMASK(31, 29)
+
+#define PHY3P08 0x18
+#define PHY3P08_TX_EQ_MAIN_G1_HI GENMASK(1, 0)
+#define PHY3P08_TX_EQ_MAIN_G2 GENMASK(6, 2)
+#define PHY3P08_TX_EQ_OVRD BIT(7)
+#define PHY3P08_TX_EQ_POST_G1 GENMASK(12, 9)
+#define PHY3P08_TX_EQ_POST_G2 GENMASK(16, 13)
+#define PHY3P08_TX_EQ_PRE_G1 GENMASK(20, 17)
+#define PHY3P08_TX_EQ_PRE_G2 GENMASK(24, 21)
+#define PHY3P08_TX_IBOOST_LVL GENMASK(28, 25)
+#define PHY3P08_TX_TERM_CTRL GENMASK(31, 29)
+
+#define PHY3P0C 0x1C
+#define PHY3P0C_TX_VBOOST_EN BIT(0)
+
+#define PHY3CMD 0x40
+
+#define PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT 0x7
+#define PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT 0x7
+#define PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT 0x3
+#define PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT 0x5
+#define PHY3P_RX_LOS_THRESHOLD_DEFAULT 0x3
+#define PHY3P_RX_TERM_CTRL_DEFAULT 0x2
+#define PHY3P_TX_EQ_MAIN_G1_DEFAULT 0xa
+#define PHY3P_TX_EQ_MAIN_G2_DEFAULT 0x9
+#define PHY3P_TX_EQ_POST_G1_DEFAULT 0x4
+#define PHY3P_TX_EQ_POST_G2_DEFAULT 0x3
+#define PHY3P_TX_EQ_PRE_G2_DEFAULT 0x2
+#define PHY3P_TX_IBOOST_LVL_DEFAULT 0xf
+#define PHY3P_TX_TERM_CTRL_DEFAULT 0x2
+
+#define PHY3P00_DEFAULT ( \
+ PHY3P00_RX_ADAPT_AFE_EN_G1 | \
+ PHY3P00_RX_ADAPT_AFE_EN_G2 | \
+ PHY3P00_RX_ADAPT_DFE_EN_G1 | \
+ PHY3P00_RX_ADAPT_DFE_EN_G2 | \
+ FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G1, PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT) | \
+ FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G2, PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P00_RX_EQ_DELTA_IQ_G1_LO, \
+ PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT & 0x3) \
+)
+
+#define PHY3P04_DEFAULT ( \
+ FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G1_HI, \
+ PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT >> 2) | \
+ FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G2, PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT) | \
+ PHY3P04_RX_LOS_LFPS_EN | \
+ FIELD_PREP(PHY3P04_RX_LOS_THRESHOLD, PHY3P_RX_LOS_THRESHOLD_DEFAULT) | \
+ FIELD_PREP(PHY3P04_RX_TERM_CTRL, PHY3P_RX_TERM_CTRL_DEFAULT) | \
+ FIELD_PREP(PHY3P04_TX_EQ_MAIN_G1_LO, \
+ PHY3P_TX_EQ_MAIN_G1_DEFAULT & 0x7) \
+)
+
+#define PHY3P08_DEFAULT ( \
+ FIELD_PREP(PHY3P08_TX_EQ_MAIN_G1_HI, PHY3P_TX_EQ_MAIN_G1_DEFAULT >> 3) | \
+ FIELD_PREP(PHY3P08_TX_EQ_MAIN_G2, PHY3P_TX_EQ_MAIN_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_POST_G1, PHY3P_TX_EQ_POST_G1_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_POST_G2, PHY3P_TX_EQ_POST_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_PRE_G2, PHY3P_TX_EQ_PRE_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_IBOOST_LVL, PHY3P_TX_IBOOST_LVL_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_TERM_CTRL, PHY3P_TX_TERM_CTRL_DEFAULT) \
+)
+
+#define PHY3P0C_DEFAULT \
+ PHY3P0C_TX_VBOOST_EN
+
+struct aspeed_usb3_phy {
+ void __iomem *regs;
+ struct reset_control *rst;
+ struct device *dev;
+ struct clk *clk;
+};
+
+static int aspeed_usb3_phy_init(struct phy *phy)
+{
+ struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(aspeed_phy->clk);
+ if (ret) {
+ dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
+ return ret;
+ }
+
+ ret = reset_control_deassert(aspeed_phy->rst);
+ if (ret) {
+ clk_disable_unprepare(aspeed_phy->clk);
+ return ret;
+ }
+
+ /* Wait for USB3 PHY internal SRAM initialization done */
+ ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
+ val & PHY3S00_INIT_DONE,
+ USEC_PER_MSEC, 10 * USEC_PER_MSEC);
+ if (ret) {
+ dev_err(aspeed_phy->dev, "SRAM init timeout\n");
+ goto err_assert_reset;
+ }
+
+ val = readl(aspeed_phy->regs + PHY3S00);
+ val |= PHY3S00_SRAM_BYPASS;
+ writel(val, aspeed_phy->regs + PHY3S00);
+
+ /* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
+ * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
+ */
+ writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
+ writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
+ writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
+ writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
+
+ return 0;
+
+err_assert_reset:
+ reset_control_assert(aspeed_phy->rst);
+ clk_disable_unprepare(aspeed_phy->clk);
+ return ret;
+}
+
+static int aspeed_usb3_phy_exit(struct phy *phy)
+{
+ struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+
+ reset_control_assert(aspeed_phy->rst);
+ clk_disable_unprepare(aspeed_phy->clk);
+
+ return 0;
+}
+
+static const struct phy_ops aspeed_usb3_phy_ops = {
+ .init = aspeed_usb3_phy_init,
+ .exit = aspeed_usb3_phy_exit,
+ .owner = THIS_MODULE,
+};
+
+static int aspeed_usb3_phy_probe(struct platform_device *pdev)
+{
+ struct aspeed_usb3_phy *aspeed_phy;
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct phy *phy;
+
+ aspeed_phy = devm_kzalloc(dev, sizeof(*aspeed_phy), GFP_KERNEL);
+ if (!aspeed_phy)
+ return -ENOMEM;
+
+ aspeed_phy->dev = dev;
+
+ aspeed_phy->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(aspeed_phy->clk))
+ return PTR_ERR(aspeed_phy->clk);
+
+ aspeed_phy->rst = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(aspeed_phy->rst))
+ return PTR_ERR(aspeed_phy->rst);
+
+ aspeed_phy->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(aspeed_phy->regs))
+ return PTR_ERR(aspeed_phy->regs);
+
+ phy = devm_phy_create(dev, NULL, &aspeed_usb3_phy_ops);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ phy_set_drvdata(phy, aspeed_phy);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id aspeed_usb3_phy_match_table[] = {
+ {
+ .compatible = "aspeed,ast2700-usb3-phy",
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_usb3_phy_match_table);
+
+static struct platform_driver aspeed_usb3_phy_driver = {
+ .probe = aspeed_usb3_phy_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = aspeed_usb3_phy_match_table,
+ },
+};
+module_platform_driver(aspeed_usb3_phy_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ASPEED USB3.2 PHY Driver");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Thorsten Leemhuis @ 2026-07-01 6:16 UTC (permalink / raw)
To: stable@vger.kernel.org, Greg KH, Sasha Levin
Cc: Felix Fietkau, Lorenzo Bianconi, Jiajia Liu, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Ming Yen Hsieh, Leon Yen,
linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Linux kernel regressions list
In-Reply-To: <akSoHk-BozrpWPmZ@nature>
On 7/1/26 07:39, Jiajia Liu wrote:
> On Tue, Jun 30, 2026 at 01:29:51PM +0200, Thorsten Leemhuis wrote:
>> On 5/28/26 05:38, Jiajia Liu wrote:
>>> Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
>>> to avoid reinitializing the wcid->poll_list.
>>>
>>> Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
>>
>> Jiajia Liu, Felox:
BTW: @Felix, sorry for the typo!
>> given that the problem seems to be in 7.1, should we
>> ask the stable team to pick this regression fix up, as this change was
>> mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
>> mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
>
> Yes. It seems to be related to cbf5e61da660 ("wifi: mt76: initialize
> more wcid fields mt76_wcid_init") [v6.14-rc1]. But I didn't reproduce
> when I checked it out and tested. So Fixes was not added.
In that case:
@Stable team, you you please pick up 20b126920a259d ("wifi: mt76: add
wcid publish check in mt76_sta_add") [v7.2-rc1] for 7.1? It lacks a
fixes tag and the problem might be older, but I saw two reports about
this with 7.1-rc -- so it seems some recent change made that problem
more likely to occur, so it might be good to fix it at least in 7.1.y.
Ciao, Thorsten
>>> According to the corruption information, prev->next was changed to itself.
>>>
>>> wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
>>> wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
>>> wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
>>> slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
>>> list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
>>>
>>> mt76_wcid_add_poll+0x95/0xd0 [mt76]
>>> mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
>>> mt7925_rx_check+0xa7/0xc0 [mt7925_common]
>>> mt76_dma_rx_poll+0x50d/0x790 [mt76]
>>> mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
>>>
>>> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
>>> ---
>>>
>>> Changes in v2:
>>> - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
>>> wcid publish check suggested by Sean
>>> - subject and commit message update
>>>
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> index 4ae5e4715a9c..b78b4cd206e0 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
>>> {
>>> struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
>>> struct mt76_dev *dev = phy->dev;
>>> + struct mt76_wcid *published;
>>> int ret;
>>> int i;
>>>
>>> @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
>>> mtxq->wcid = wcid->idx;
>>> }
>>>
>>> - ewma_signal_init(&wcid->rssi);
>>> - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
>>> + published = rcu_dereference_protected(dev->wcid[wcid->idx],
>>> + lockdep_is_held(&dev->mutex));
>>> + if (published != wcid) {
>>> + WARN_ON_ONCE(published);
>>> + ewma_signal_init(&wcid->rssi);
>>> + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
>>> + mt76_wcid_init(wcid, phy->band_idx);
>>> + } else {
>>> + wcid->phy_idx = phy->band_idx;
>>> + }
>>> +
>>> phy->num_sta++;
>>>
>>> - mt76_wcid_init(wcid, phy->band_idx);
>>> out:
>>> mutex_unlock(&dev->mutex);
>>>
^ permalink raw reply
* [PATCH 0/3] can: rockchip: add RK3588 CAN-FD support
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
From: luch00 <1579567540@qq.com>
Add initial support for the RK3588v2 CAN-FD controller.
RK3588 integrates three CAN-FD controllers that are closely related to
the existing Rockchip CAN-FD IP already supported in the kernel, but
they cannot reuse the rk3568v2 description unchanged.
This series therefore:
- extends the existing Rockchip CAN-FD binding with the
rockchip,rk3588v2-canfd compatible
- adds a dedicated RK3588v2 match entry and devtype in the driver
- describes the three CAN-FD controller nodes in rk3588-base.dtsi
The dedicated driver data is needed because RK3588v2 encodes
RX_FIFO_CNT in bits 7:5 instead of 6:4. Runtime validation on RK3588v2
also showed that its observed errata profile differs from rk3568v2 and
rk3568v3, so using a fallback compatible would be misleading.
Tested on an embedfire,rk3588-lubancat-5io board with can0/can1
directly connected. Runtime testing used a 198 MHz CAN clock, nominal
bitrate 500 kbit/s, data bitrate 1 Mbit/s, and included stress and
error-path coverage for the existing Rockchip errata handling.
luch00 (3):
dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
can: rockchip: add RK3588 CAN-FD support
arm64: dts: rockchip: add CAN-FD nodes for RK3588
.../net/can/rockchip,rk3568v2-canfd.yaml | 1 +
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
.../net/can/rockchip/rockchip_canfd-core.c | 14 +++++++
drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++-
drivers/net/can/rockchip/rockchip_canfd.h | 12 +++++-
5 files changed, 69 insertions(+), 2 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
In-Reply-To: <20260701070128.2096267-1-1579567540@qq.com>
From: luch00 <1579567540@qq.com>
The RK3588 CAN-FD controller uses the same DT properties as the
existing Rockchip CAN-FD blocks, so extend the current schema with a
SoC-specific rockchip,rk3588v2-canfd compatible instead of creating a
new binding file.
Keep RK3588v2 as its own compatible rather than an rk3568v2 fallback.
Driver support uses separate match data and the RX FIFO count field
layout differs from rk3568v2, so a dedicated compatible is the safer
description.
Signed-off-by: luch00 <1579567540@qq.com>
---
.../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c0330..aa31ec78e 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
oneOf:
- const: rockchip,rk3568v2-canfd
+ - const: rockchip,rk3588v2-canfd
- items:
- const: rockchip,rk3568v3-canfd
- const: rockchip,rk3568v2-canfd
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] can: rockchip: add RK3588 CAN-FD support
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
In-Reply-To: <20260701070128.2096267-1-1579567540@qq.com>
From: luch00 <1579567540@qq.com>
Add support for the RK3588v2 CAN-FD controller by introducing a
dedicated model ID and OF match entry.
The block is closely related to the existing RK3568 variants, but it
cannot reuse their match data unchanged. In particular, RK3588v2
encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
SoC-specific handling.
Validation on RK3588v2 also shows that its observed errata profile does
not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
variant instead of relying on an rk3568 fallback.
Signed-off-by: luch00 <1579567540@qq.com>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++++-
drivers/net/can/rockchip/rockchip_canfd.h | 12 +++++++++++-
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e..3c2480785 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
RKCANFD_QUIRK_CANFD_BROKEN,
};
+/* Tests on the rk3588v2 reproduce Erratum 5, but not
+ * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
+ * on rk3568v2/rk3568v3.
+ */
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588v2 = {
+ .model = RKCANFD_MODEL_RK3588V2,
+ .quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5,
+};
+
static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
{
switch (model) {
@@ -57,6 +66,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
return "rk3568v2";
case RKCANFD_MODEL_RK3568V3:
return "rk3568v3";
+ case RKCANFD_MODEL_RK3588V2:
+ return "rk3588v2";
}
return "<unknown>";
@@ -846,6 +857,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
}, {
.compatible = "rockchip,rk3568v3-canfd",
.data = &rkcanfd_devtype_data_rk3568v3,
+ }, {
+ .compatible = "rockchip,rk3588v2-canfd",
+ .data = &rkcanfd_devtype_data_rk3588v2,
}, {
/* sentinel */
},
diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
index 475c0409e..fe64db373 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
{
const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
- return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
+ if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
+ return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
+
+ return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
}
int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7..f6105b904 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -214,7 +214,8 @@
#define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
#define RKCANFD_REG_RX_FIFO_CTRL 0x118
-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)
#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)
@@ -331,6 +332,11 @@
* rarely with the standard clock of 300 MHz, but almost immediately
* at 80 MHz.
*
+ * Test on the rk3588v2 shows the same empty FIFO condition.
+ * In that setup rx_fifo_empty_errors increments when the bus
+ * transitions from idle to high CAN-FD load and stops growing once
+ * the bus reaches a steady state.
+ *
* To workaround this problem, check for empty FIFO with
* rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit
* early.
@@ -424,6 +430,9 @@
* cansequence -rv -i 1
*
* - TX starvation after repeated Bus-Off
+ * Tests on the rk3588v2 show the same problem. In a
+ * 10-cycle Bus-Off recovery test, 9 cycles failed to send after the
+ * controller restarted.
* To reproduce:
* host:
* sleep 3 && cangen can0 -I2 -Li -Di -p10 -g 0.0
@@ -434,6 +443,7 @@
enum rkcanfd_model {
RKCANFD_MODEL_RK3568V2 = 0x35682,
RKCANFD_MODEL_RK3568V3 = 0x35683,
+ RKCANFD_MODEL_RK3588V2 = 0x35882,
};
struct rkcanfd_devtype_data {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: rockchip: add CAN-FD nodes for RK3588
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
In-Reply-To: <20260701070128.2096267-1-1579567540@qq.com>
From: luch00 <1579567540@qq.com>
Describe the three CAN-FD controllers integrated in RK3588 in the base
SoC .dtsi.
Add CAN0, CAN1 and CAN2 nodes with their register ranges, interrupts,
clocks and resets, and keep them disabled by default so board DTS files
can enable them as needed.
Signed-off-by: luch00 <1579567540@qq.com>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index fc1fdbfd3..f38cd8bd4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -2648,6 +2648,45 @@ dmac1: dma-controller@fea30000 {
#dma-cells = <1>;
};
+ can0: can@fea50000 {
+ compatible = "rockchip,rk3588v2-canfd";
+ reg = <0x0 0xfea50000 0x0 0x1000>;
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can0m0_pins>;
+ status = "disabled";
+ };
+
+ can1: can@fea60000 {
+ compatible = "rockchip,rk3588v2-canfd";
+ reg = <0x0 0xfea60000 0x0 0x1000>;
+ interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN1>, <&cru PCLK_CAN1>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN1>, <&cru SRST_P_CAN1>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can1m0_pins>;
+ status = "disabled";
+ };
+
+ can2: can@fea70000 {
+ compatible = "rockchip,rk3588v2-canfd";
+ reg = <0x0 0xfea70000 0x0 0x1000>;
+ interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN2>, <&cru PCLK_CAN2>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN2>, <&cru SRST_P_CAN2>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can2m0_pins>;
+ status = "disabled";
+ };
+
i2c1: i2c@fea90000 {
compatible = "rockchip,rk3588-i2c", "rockchip,rk3399-i2c";
reg = <0x0 0xfea90000 0x0 0x1000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add graperain
From: Krzysztof Kozlowski @ 2026-07-01 7:05 UTC (permalink / raw)
To: Coia Prant
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260630153810.3574714-4-coiaprant@gmail.com>
On Tue, Jun 30, 2026 at 11:38:09PM +0800, Coia Prant wrote:
> Add graperain to the vendor prefixes.
>
> Link: https://www.graperain.cn/ (China)
> Link: https://www.graperain.com/ (Global)
>
> Signed-off-by: Coia Prant <coiaprant@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Krzysztof Kozlowski @ 2026-07-01 7:07 UTC (permalink / raw)
To: Coia Prant
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260630153810.3574714-6-coiaprant@gmail.com>
On Tue, Jun 30, 2026 at 11:38:11PM +0800, Coia Prant wrote:
> Document Graperain G3568 v2
> which is a development board based on RK3568 SoC.
Broken wrapping.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] RFC: ARM: breakpoint: CFI breakpoints only on demand
From: Linus Walleij @ 2026-07-01 7:11 UTC (permalink / raw)
To: Russell King, Nathan Chancellor, Sami Tolvanen, Kees Cook,
Russell King (Oracle)
Cc: linux-arm-kernel, linux-kernel, stable, slipher, Linus Walleij
This removes the stub hw_breakpoint_cfi_handler() from ARM, making
it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
CFI is actively used in the kernel.
When not instrumenting with CFI, we fall through to return 1 from
hw_breakpoint_pending() "unhandled fault" so userspace can make use
of this breakpoint.
This of course does not work if userspace want to use CFI and custom
breakpoints at the same time, and CONFIG_CFI does exist as something
users might want to select for their kernel. If this is not good
acceptable we need to think about other ways for CFI to interfer, such
as not using BKPT at all (rather something like BUG()) and back out
the offending patch until the compiler behaviour has changed.
Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints")
Reported-by: slipher <slipher@protonmail.com>
Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Trying to solve the CFI bug. Let's see of this first
approach is acceptable for the reporter.
---
Changes in v2:
- Resending as non-RFC so it can be applied as a band-aid.
- Link to v1: https://patch.msgid.link/20260626-arm32-cfi-bug-v1-1-a467b5050c0b@kernel.org
---
arch/arm/kernel/hw_breakpoint.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index cd4b34c96e35..007023db6a5d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -929,10 +929,6 @@ static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
break;
}
}
-#else
-static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
-{
-}
#endif
/*
@@ -964,9 +960,11 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
case ARM_ENTRY_SYNC_WATCHPOINT:
watchpoint_handler(addr, fsr, regs);
break;
+#ifdef CONFIG_CFI
case ARM_ENTRY_CFI_BREAKPOINT:
hw_breakpoint_cfi_handler(regs);
break;
+#endif
default:
ret = 1; /* Unhandled fault. */
}
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260626-arm32-cfi-bug-10fb960749c4
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply related
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Jie Gan @ 2026-07-01 7:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-stirring-piculet-of-vastness-a361e5@quoll>
On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>> The TNOC compatible previously only allowed the two-string AMBA form
>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>> AMBA bus.
>>
>> Convert the compatible to a oneOf and add a standalone
>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>> standalone string carries no "arm,primecell" entry, so the device is
>> created on the platform bus instead of the AMBA bus.
>
> That's a Linux driver specific reason, so not a valid one.
>
> Describe the hardware instead.
>
> Also, you do not get other compatible for the same device.
The device is intended to be discovered and probed via the AMBA bus.
However, due to a hardware issue, AMBA probing does not work correctly.
While adding the arm,primecell-periphid property would allow the
existing AMBA driver to bind, but I think that's a temp WA. As
Suzuki/Leo pointed out, we should not add the property to pretend the
device as an AMBA device.
Instead, I introduced a dedicated compatible string so the device can be
handled by the existing platform driver without relying on the missing
AMBA primecell identification. The purpose of the new compatible is to
clearly distinguish this platform-specific case from the standard
AMBA-based implementation. Or shall I re-use the existing compatible
"qcom,coresight-tnoc" as platform standalone compatible?
We already have a similar pattern for the interconnect TraceNoC device,
which uses the platform-specific compatible string qcom,coresight-itnoc.
Thanks,
Jie
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Krzysztof Kozlowski @ 2026-07-01 7:24 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20260630-rpi-tryboot-v2-2-f68d2dc6aa27@linutronix.de>
On Tue, Jun 30, 2026 at 10:59:28PM +0200, Gregor Herburger wrote:
> The Raspberry Pi firmware allows to set a reboot mode called tryboot
> that allows to try booting from a different partition to allow updating
> of the boot partition. Allow reboot mode properties by referencing the
> reboot-mode schema. The firmware allows a 32bit value to be sent as
> reboot flag so restrict the maxItems to 1.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Krzysztof Kozlowski @ 2026-07-01 7:26 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <4117c406-0d75-4eb1-842e-1d346b7fbf99@oss.qualcomm.com>
On 01/07/2026 09:16, Jie Gan wrote:
>
>
> On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
>> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>>> The TNOC compatible previously only allowed the two-string AMBA form
>>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>>> AMBA bus.
>>>
>>> Convert the compatible to a oneOf and add a standalone
>>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>>> standalone string carries no "arm,primecell" entry, so the device is
>>> created on the platform bus instead of the AMBA bus.
>>
>> That's a Linux driver specific reason, so not a valid one.
>>
>> Describe the hardware instead.
>>
>> Also, you do not get other compatible for the same device.
>
> The device is intended to be discovered and probed via the AMBA bus.
> However, due to a hardware issue, AMBA probing does not work correctly.
> While adding the arm,primecell-periphid property would allow the
If this is not AMBA bus device, then drop primecell compatible.
> existing AMBA driver to bind, but I think that's a temp WA. As
> Suzuki/Leo pointed out, we should not add the property to pretend the
> device as an AMBA device.
>
> Instead, I introduced a dedicated compatible string so the device can be
> handled by the existing platform driver without relying on the missing
As I said, that's a Linux driver specific reason, so not a valid one.
Fix your drivers if you insist on that.
> AMBA primecell identification. The purpose of the new compatible is to
> clearly distinguish this platform-specific case from the standard
> AMBA-based implementation. Or shall I re-use the existing compatible
> "qcom,coresight-tnoc" as platform standalone compatible?
>
> We already have a similar pattern for the interconnect TraceNoC device,
> which uses the platform-specific compatible string qcom,coresight-itnoc.
I do not see there a fake, duplicated compatible for the same device.
Can you elaborate how is that relevant?
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-07-01 7:27 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Viacheslav Bocharov
Cc: Bartosz Golaszewski, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260625115718.1678991-1-v@baodeep.com>
On Thu, 25 Jun 2026 14:57:16 +0300, Viacheslav Bocharov wrote:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> [...]
Applied, thanks!
[2/2] pinctrl: meson: restore non-sleeping GPIO access
https://git.kernel.org/brgl/c/9777530157e7b82fd994327ff878c4245dadc931
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards
From: Krzysztof Kozlowski @ 2026-07-01 7:30 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Daniel Baluta, Dario Binacchi, Josua Mayer,
Alexander Stein, Ernest Van Hoecke, Maud Spierings,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <449840f7b6ffb71b677ccf814a0294c981854033.1782812572.git.stefano.r@variscite.com>
On Tue, Jun 30, 2026 at 11:46:54AM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add DT compatible strings for Variscite VAR-SOM-MX8 QuadMax SoM and
> Variscite Symphony development carrier Board.
>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 3/5] mfd: aaeon: Add SRG-IMX8P MCU driver
From: Bartosz Golaszewski @ 2026-07-01 7:31 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric)
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
In-Reply-To: <20260630-dev-b4-aaeon-mcu-driver-v6-3-d66b5fcbd2f0@bootlin.com>
On Tue, 30 Jun 2026 14:51:13 +0200, "Thomas Perrot (Schneider
Electric)" <thomas.perrot@bootlin.com> said:
> Add Multi-Function Device (MFD) driver for the Aaeon SRG-IMX8P
> embedded controller. This driver provides the core I2C communication
> interface and registers child devices (GPIO and watchdog controllers).
>
> The driver implements a custom regmap bus over I2C to match the MCU's
> fixed 3-byte command format [opcode, arg, value]. Register addresses
> are encoded as 16-bit values (opcode << 8 | arg) using the
> AAEON_MCU_REG() macro defined in the shared header. The regmap
> instance is shared with child drivers via dev_get_regmap(). Concurrent
> I2C accesses from child drivers are serialized by regmap's built-in
> locking.
>
> I2C transfers use heap-allocated DMA-safe buffers rather than
> stack-allocated ones, as required by I2C controllers that perform DMA.
>
> Regmap caching is enabled (REGCACHE_MAPLE) with a volatile_reg
> callback that marks GPIO input read registers (opcode 0x72) and the
> watchdog status register (opcode 0x63, arg 0x02) as volatile. All
> other registers written by the driver (GPIO direction,
> GPO state, watchdog control) are stable and can be safely cached.
>
> Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
> ---
> MAINTAINERS | 2 +
> drivers/mfd/Kconfig | 11 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/aaeon-mcu.c | 205 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/aaeon-mcu.h | 40 +++++++++
> 5 files changed, 259 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea9d55f76f35..f91b6a1826d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -191,6 +191,8 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
> R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> S: Maintained
> F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
> +F: drivers/mfd/aaeon-mcu.c
> +F: include/linux/mfd/aaeon-mcu.h
>
> AAEON UPBOARD FPGA MFD DRIVER
> M: Thomas Richard <thomas.richard@bootlin.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aace5766b38a..ed5169c7a683 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1561,6 +1561,17 @@ config ABX500_CORE
> remain unchanged when IC changes. Binding of the functions to
> actual register access is done by the IC core driver.
>
> +config MFD_AAEON_MCU
> + tristate "Aaeon SRG-IMX8P MCU Driver"
> + depends on I2C
> + select MFD_CORE
> + select REGMAP
> + help
> + Select this option to enable support for the Aaeon SRG-IMX8P
> + onboard microcontroller (MCU). This driver provides the core
> + functionality to communicate with the MCU over I2C. The MCU
> + provides GPIO and watchdog functionality.
> +
> config AB8500_CORE
> bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
> depends on ABX500_CORE && MFD_DB8500_PRCMU
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index e75e8045c28a..34db5b033584 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
> +obj-$(CONFIG_MFD_AAEON_MCU) += aaeon-mcu.o
> obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> obj-$(CONFIG_MFD_SM501) += sm501.o
> obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
> diff --git a/drivers/mfd/aaeon-mcu.c b/drivers/mfd/aaeon-mcu.c
> new file mode 100644
> index 000000000000..306aaac1bd60
> --- /dev/null
> +++ b/drivers/mfd/aaeon-mcu.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Aaeon MCU driver
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/mfd/aaeon-mcu.h>
> +#include <linux/mfd/core.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +struct aaeon_mcu {
> + struct i2c_client *client;
> + u8 *cmd; /* DMA-safe 3-byte write buffer [opcode, arg, value] */
> + u8 *response; /* DMA-safe 1-byte read buffer for MCU acknowledgment */
> +};
> +
> +static const struct mfd_cell aaeon_mcu_devs[] = {
> + MFD_CELL_BASIC("aaeon-mcu-wdt", NULL, NULL, 0, 0),
> + MFD_CELL_BASIC("aaeon-mcu-gpio", NULL, NULL, 0, 0),
> +};
> +
> +/* Number of bytes in a MCU command: [opcode, arg, value] */
> +#define AAEON_MCU_CMD_LEN 3
> +
> +/*
> + * Custom regmap bus for the Aaeon MCU I2C protocol.
> + *
> + * The MCU uses a fixed 3-byte command format [opcode, arg, value] followed
> + * by a 1-byte response. It requires a STOP condition between the command
> + * write and the response read, so two separate i2c_transfer() calls are
> + * issued. The regmap lock serialises concurrent accesses from the GPIO
> + * and watchdog child drivers.
> + *
> + * Register addresses are encoded as a 16-bit big-endian value where the
> + * high byte is the opcode and the low byte is the argument, matching the
> + * wire layout produced by regmap for reg_bits=16.
> + */
I would have preferred this implemented as a quirk in the i2c regmap but
won't die on that hill.
> +
> +static int aaeon_mcu_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + /* The MCU always sends a response byte after each command; discard it. */
> + struct i2c_msg response_msg;
> + int ret;
> +
> + memcpy(mcu->cmd, data, count);
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = I2C_M_DMA_SAFE;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = count;
> +
> + response_msg.addr = client->addr;
> + response_msg.flags = I2C_M_RD | I2C_M_DMA_SAFE;
> + response_msg.buf = mcu->response;
> + response_msg.len = 1;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &response_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int aaeon_mcu_regmap_read(void *context, const void *reg_buf,
> + size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + struct i2c_msg read_msg;
> + int ret;
> +
> + /*
> + * reg_buf holds the 2-byte big-endian register address [opcode, arg].
> + * Append a trailing 0x00 to form the full 3-byte MCU command.
> + */
> + mcu->cmd[0] = ((u8 *)reg_buf)[0];
> + mcu->cmd[1] = ((u8 *)reg_buf)[1];
> + mcu->cmd[2] = 0x00;
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = I2C_M_DMA_SAFE;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = AAEON_MCU_CMD_LEN;
> +
> + read_msg.addr = client->addr;
> + read_msg.flags = I2C_M_RD | I2C_M_DMA_SAFE;
> + read_msg.buf = val_buf;
> + read_msg.len = val_size;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &read_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static const struct regmap_bus aaeon_mcu_regmap_bus = {
> + .write = aaeon_mcu_regmap_write,
> + .read = aaeon_mcu_regmap_read,
> +};
> +
> +static bool aaeon_mcu_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * GPIO input registers are driven by external signals and can change
> + * at any time without CPU involvement, always read from hardware.
> + *
> + * The watchdog status register reflects hardware state and can change
> + * autonomously.
> + *
> + * All other registers are written by the driver and their values are
> + * stable, so they can be safely cached.
> + */
> + if ((reg >> 8) == AAEON_MCU_READ_GPIO_OPCODE)
> + return true;
> + if (reg == AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02))
> + return true;
> + return false;
> +}
> +
> +static const struct regmap_config aaeon_mcu_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .reg_format_endian = REGMAP_ENDIAN_BIG,
> + .max_register = AAEON_MCU_MAX_REGISTER,
> + .volatile_reg = aaeon_mcu_volatile_reg,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static int aaeon_mcu_probe(struct i2c_client *client)
> +{
> + struct aaeon_mcu *ddata;
> + struct regmap *regmap;
> +
> + ddata = devm_kzalloc(&client->dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + ddata->client = client;
> +
> + ddata->cmd = devm_kzalloc(&client->dev, AAEON_MCU_CMD_LEN * sizeof(*ddata->cmd),
Why not devm_kcalloc()?
> + GFP_KERNEL);
> + if (!ddata->cmd)
> + return -ENOMEM;
> +
> + ddata->response = devm_kzalloc(&client->dev, sizeof(*ddata->response), GFP_KERNEL);
> + if (!ddata->response)
> + return -ENOMEM;
> +
> + regmap = devm_regmap_init(&client->dev, &aaeon_mcu_regmap_bus,
> + ddata, &aaeon_mcu_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(&client->dev, PTR_ERR(regmap),
> + "failed to initialize regmap\n");
> +
> + return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + aaeon_mcu_devs, ARRAY_SIZE(aaeon_mcu_devs),
> + NULL, 0, NULL);
> +}
> +
> +static const struct of_device_id aaeon_mcu_of_match[] = {
> + { .compatible = "aaeon,srg-imx8p-mcu" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, aaeon_mcu_of_match);
> +
> +static struct i2c_driver aaeon_mcu_driver = {
> + .driver = {
> + .name = "aaeon-mcu",
> + .of_match_table = aaeon_mcu_of_match,
> + },
> + .probe = aaeon_mcu_probe,
> +};
> +module_i2c_driver(aaeon_mcu_driver);
> +
> +MODULE_DESCRIPTION("Aaeon MCU Driver");
> +MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/aaeon-mcu.h b/include/linux/mfd/aaeon-mcu.h
> new file mode 100644
> index 000000000000..3a1aeec85d60
> --- /dev/null
> +++ b/include/linux/mfd/aaeon-mcu.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Aaeon MCU driver definitions
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#ifndef __LINUX_MFD_AAEON_MCU_H
> +#define __LINUX_MFD_AAEON_MCU_H
> +
> +/*
> + * MCU register address: the high byte is the command opcode, the low
> + * byte is the argument. This matches the 3-byte wire format
> + * [opcode, arg, value] used by the MCU I2C protocol.
> + */
> +#define AAEON_MCU_REG(op, arg) (((op) << 8) | (arg))
> +
> +/*
> + * Opcode for GPIO input reads. These registers are volatile, their values
> + * are driven by external signals and can change without CPU involvement.
> + * Used by the MFD driver's volatile_reg callback to bypass the regmap cache.
> + */
> +#define AAEON_MCU_READ_GPIO_OPCODE 0x72
> +
> +/*
> + * Opcode for watchdog control and status commands.
> + * The status register (arg=0x02) reflects hardware state and is volatile.
> + */
> +#define AAEON_MCU_CONTROL_WDT_OPCODE 0x63
> +
> +/*
> + * Highest register address in the MCU register map.
> + * The WRITE_GPIO opcode (0x77) with the highest GPIO argument (0x0B = 11,
> + * i.e. MAX_GPIOS - 1) produces the largest encoded address.
> + */
> +#define AAEON_MCU_MAX_REGISTER AAEON_MCU_REG(0x77, 0x0B)
> +
> +#endif /* __LINUX_MFD_AAEON_MCU_H */
>
> --
> 2.54.0
>
>
Bart
^ permalink raw reply
* RE: [PATCH] hwrng: xilinx-trng: propagate timeout before any data is read
From: Jain, Harsh (AECG-SSW) @ 2026-07-01 7:31 UTC (permalink / raw)
To: Pengpeng Hou, Botcha, Mounika, Olivia Mackall, Herbert Xu,
Simek, Michal, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Pandey, Radhey Shyam, Savitala, Sarat Chand
In-Reply-To: <20260623060728.18906-1-pengpeng@iscas.ac.cn>
AMD General
Reviewed-by : Harsh Jain <h.jain@amd.com>
> -----Original Message-----
> From: Pengpeng Hou <pengpeng@iscas.ac.cn>
> Sent: Tuesday, June 23, 2026 11:37 AM
> To: Botcha, Mounika <Mounika.Botcha@amd.com>; Jain, Harsh (AECG-SSW)
> <h.jain@amd.com>; Olivia Mackall <olivia@selenic.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; Simek, Michal <michal.simek@amd.com>; linux-
> crypto@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Cc: Pengpeng Hou <pengpeng@iscas.ac.cn>
> Subject: [PATCH] hwrng: xilinx-trng: propagate timeout before any data is read
>
>
> xtrng_readblock32() polls for 16-byte chunks but returns the number of
> bytes read even when the first poll times out. Its caller then treats a
> zero return as a short successful read, and partial reads for full
> 32-byte blocks can make the tail copy use a fixed block offset rather
> than the amount already produced.
>
> Return the poll error when no data has been read, preserve partial
> positive returns after some data is available, stop the generator on all
> collection exits, and append tail bytes at the current output count.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/char/hw_random/xilinx-trng.c | 32 +++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/hw_random/xilinx-trng.c b/drivers/char/hw_random/xilinx-
> trng.c
> index f615d5adddde..4a1a168bb46a 100644
> --- a/drivers/char/hw_random/xilinx-trng.c
> +++ b/drivers/char/hw_random/xilinx-trng.c
> @@ -87,8 +87,8 @@ static void xtrng_softreset(struct xilinx_rng *rng)
> xtrng_readwrite32(rng->rng_base + TRNG_CTRL_OFFSET,
> TRNG_CTRL_PRNGSRST_MASK, 0);
> }
>
> -/* Return no. of bytes read */
> -static size_t xtrng_readblock32(void __iomem *rng_base, __be32 *buf, int
> blocks32, bool wait)
> +/* Return no. of bytes read or a negative error before any data is read. */
> +static int xtrng_readblock32(void __iomem *rng_base, __be32 *buf, int blocks32,
> bool wait)
> {
> int read = 0, ret;
> int timeout = 1;
> @@ -103,8 +103,11 @@ static size_t xtrng_readblock32(void __iomem *rng_base,
> __be32 *buf, int blocks3
> ret = readl_poll_timeout(rng_base + TRNG_STATUS_OFFSET, val,
> (val & TRNG_STATUS_QCNT_MASK) ==
> TRNG_STATUS_QCNT_16_BYTES, !!wait, timeout);
> - if (ret)
> + if (ret) {
> + if (!read)
> + return ret;
> break;
> + }
>
> for (idx = 0; idx < TRNG_READ_4_WORD; idx++) {
> *(buf + read) = cpu_to_be32(ioread32(rng_base +
> TRNG_CORE_OUTPUT_OFFSET));
> @@ -119,27 +122,40 @@ static int xtrng_collect_random_data(struct xilinx_rng
> *rng, u8 *rand_gen_buf,
> {
> u8 randbuf[TRNG_SEC_STRENGTH_BYTES];
> int byteleft, blocks, count = 0;
> + int full_blocks_bytes;
> int ret;
>
> byteleft = no_of_random_bytes & (TRNG_SEC_STRENGTH_BYTES - 1);
> blocks = no_of_random_bytes >> TRNG_SEC_STRENGTH_SHIFT;
> + full_blocks_bytes = blocks * TRNG_SEC_STRENGTH_BYTES;
> xtrng_readwrite32(rng->rng_base + TRNG_CTRL_OFFSET,
> TRNG_CTRL_PRNGSTART_MASK,
> TRNG_CTRL_PRNGSTART_MASK);
> if (blocks) {
> ret = xtrng_readblock32(rng->rng_base, (__be32 *)rand_gen_buf, blocks,
> wait);
> - if (!ret)
> - return 0;
> + if (ret <= 0) {
> + count = ret;
> + goto out_stop;
> + }
> count += ret;
> + if (ret < full_blocks_bytes)
> + goto out_stop;
> }
>
> if (byteleft) {
> ret = xtrng_readblock32(rng->rng_base, (__be32 *)randbuf, 1, wait);
> + if (ret < 0) {
> + if (!count)
> + count = ret;
> + goto out_stop;
> + }
> if (!ret)
> - return count;
> - memcpy(rand_gen_buf + (blocks * TRNG_SEC_STRENGTH_BYTES),
> randbuf, byteleft);
> - count += byteleft;
> + goto out_stop;
> + ret = min(ret, no_of_random_bytes - count);
> + memcpy(rand_gen_buf + count, randbuf, ret);
> + count += ret;
> }
>
> +out_stop:
> xtrng_readwrite32(rng->rng_base + TRNG_CTRL_OFFSET,
> TRNG_CTRL_PRNGMODE_MASK |
> TRNG_CTRL_PRNGSTART_MASK, 0U);
>
> --
> 2.50.1 (Apple Git-155)
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Jie Gan @ 2026-07-01 7:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <9aa63427-ba41-436d-ab19-a533082d336a@kernel.org>
On 7/1/2026 3:26 PM, Krzysztof Kozlowski wrote:
> On 01/07/2026 09:16, Jie Gan wrote:
>>
>>
>> On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
>>> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>>>> The TNOC compatible previously only allowed the two-string AMBA form
>>>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>>>> AMBA bus.
>>>>
>>>> Convert the compatible to a oneOf and add a standalone
>>>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>>>> standalone string carries no "arm,primecell" entry, so the device is
>>>> created on the platform bus instead of the AMBA bus.
>>>
>>> That's a Linux driver specific reason, so not a valid one.
>>>
>>> Describe the hardware instead.
>>>
>>> Also, you do not get other compatible for the same device.
>>
>> The device is intended to be discovered and probed via the AMBA bus.
>> However, due to a hardware issue, AMBA probing does not work correctly.
>> While adding the arm,primecell-periphid property would allow the
>
> If this is not AMBA bus device, then drop primecell compatible.
Will drop the primecell compatible and update the description.
>
>> existing AMBA driver to bind, but I think that's a temp WA. As
>> Suzuki/Leo pointed out, we should not add the property to pretend the
>> device as an AMBA device.
>>
>> Instead, I introduced a dedicated compatible string so the device can be
>> handled by the existing platform driver without relying on the missing
>
> As I said, that's a Linux driver specific reason, so not a valid one.
>
> Fix your drivers if you insist on that.
>
>> AMBA primecell identification. The purpose of the new compatible is to
>> clearly distinguish this platform-specific case from the standard
>> AMBA-based implementation. Or shall I re-use the existing compatible
>> "qcom,coresight-tnoc" as platform standalone compatible?
>>
>> We already have a similar pattern for the interconnect TraceNoC device,
>> which uses the platform-specific compatible string qcom,coresight-itnoc.
> I do not see there a fake, duplicated compatible for the same device.
> Can you elaborate how is that relevant?
Will fix it by removing AMBA related description.
Shall I update the clock name from apb_pclk to apb as a platform device?
Thanks,
Jie
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: can: rockchip_canfd: add compatible for the RK3588 variant
From: Krzysztof Kozlowski @ 2026-07-01 7:33 UTC (permalink / raw)
To: Heiko Stuebner
Cc: mkl, mailhol, kernel, robh, krzk+dt, conor+dt, shawn.lin,
linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-2-heiko@sntech.de>
On Tue, Jun 30, 2026 at 06:43:31PM +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>
> The RK3588 uses a variant of the CAN(-FD) controller introduced at first
> with the RK3568 SoC.
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> ---
> .../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> index a077c0330013..02211ea3ec41 100644
> --- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> @@ -20,6 +20,7 @@ properties:
> - items:
> - const: rockchip,rk3568v3-canfd
> - const: rockchip,rk3568v2-canfd
> + - const: rockchip,rk3588-canfd
So this is just an enum with the first entry.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Krzysztof Kozlowski @ 2026-07-01 7:35 UTC (permalink / raw)
To: Markus Probst
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <20260630-rtc_s35390a_int1-v1-1-1b2239e16be2@posteo.de>
On Tue, Jun 30, 2026 at 07:22:21PM +0000, Markus Probst wrote:
> Synology NAS devices use the output pin for interrupt signal 1 to wake up
> the system.
>
> Move devicetree bindings for sii,s35390a into its own file.
> Add sii,wakealarm-output-pin property to enable the use of the output
> pin for interrupt signal 1 for the wake alarm, which makes it possible to
> set an wake alarm on Synology NAS devices.
>
> Signed-off-by: Markus Probst <markus.probst@posteo.de>
> ---
> .../devicetree/bindings/rtc/sii,s35390a.yaml | 54 ++++++++++++++++++++++
> .../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
> MAINTAINERS | 1 +
> include/dt-bindings/rtc/s35390a.h | 9 ++++
> 4 files changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> new file mode 100644
> index 000000000000..31a578673870
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/sii,s35390a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: S-35390A 2-WIRE REAL-TIME CLOCK
> +
> +maintainers:
> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
This should be someone caring about this hardware.
> +
> +description:
> + The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
> + very low current consumption in the wide range of operation voltage.
> +
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + const: sii,s35390a
> +
> + reg:
> + maxItems: 1
> +
> + sii,wakealarm-output-pin:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 2]
> + description: |
> + The output pin to wake up the system.
> + Default will use the output pin for interrupt signal 2.
> + <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
> + <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
Does that mean device generates the interrupts?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Ioana Ciornei @ 2026-07-01 7:42 UTC (permalink / raw)
To: Frank Li
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel
In-Reply-To: <akQlJlYaZkaZI_jh@lizhi-Precision-Tower-5810>
On Tue, Jun 30, 2026 at 04:20:54PM -0400, Frank Li wrote:
> On Tue, Jun 30, 2026 at 02:04:54PM +0300, Ioana Ciornei wrote:
> > This patch set adds the device tree nodes for the Lynx10G SerDes blocks
> > found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
> >
> > The first patch also transitions the LX2160A SoC dtsi to use the
> > device-specific Lynx28G SerDes compatible.
> >
>
> Next time please cc imx@lists.linux.dev, otherwise, patchwork can't see
> this patch.
Ok, sure. Will send shortly a v2 integrating some changes generated by
the sashiko review.
Thanks!
^ permalink raw reply
* [PATCH v3 0/2] MT8189 SMI SUPPORT
From: Congcong Yao @ 2026-07-01 7:44 UTC (permalink / raw)
To: Yong Wu, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-mediatek, linux-kernel, devicetree, linux-arm-kernel,
Project_Global_Chrome_Upstream_Group, jarried.lin, vince-wl.liu,
justin.yeh, Congcong Yao
Based on tag: next-20260629, linux-next/master
This patchset add mt8189 smi support.
---
Changes in v3:
- Change the clock numbers of smi-sub-common to minium 3
- Link to v2:
https://lore.kernel.org/linux-mediatek/20260427070444.20247-1-zhengnan.chen@mediatek.com/
---
Zhengnan Chen (2):
dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
memory: mtk-smi: Add mt8189 support
.../mediatek,smi-common.yaml | 18 ++++++++
.../memory-controllers/mediatek,smi-larb.yaml | 3 ++
drivers/memory/mtk-smi.c | 44 +++++++++++++++++++
3 files changed, 65 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
From: Congcong Yao @ 2026-07-01 7:44 UTC (permalink / raw)
To: Yong Wu, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-mediatek, linux-kernel, devicetree, linux-arm-kernel,
Project_Global_Chrome_Upstream_Group, jarried.lin, vince-wl.liu,
justin.yeh, Zhengnan Chen, Congcong Yao
In-Reply-To: <20260701074533.175803-1-Congcong.Yao@mediatek.com>
From: Zhengnan Chen <zhengnan.chen@mediatek.com>
Add smi larb, common and sub-commom binding description for mt8189.
About what smi-sub-common is, please check the below diagram,
we add it in mediatek,smi-common.yaml file.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Signed-off-by: Congcong Yao <congcong.yao@mediatek.com>
---
.../mediatek,smi-common.yaml | 18 ++++++++++++++++++
.../memory-controllers/mediatek,smi-larb.yaml | 3 +++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
index 0762e0ff66ef..4e1deeff92b1 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -25,6 +25,21 @@ description: |
SMI generation 1 to transform the smi clock into emi clock domain, but that is
not needed for SMI generation 2.
+ The smi-common connects with smi-larb and IOMMU. The maximum inputs number of
+ a smi-common is 8. In SMI generation 2, the engines number may be over 8.
+ In this case, we use a smi-sub-common to merge some larbs.
+ The block diagram something is like:
+
+ IOMMU
+ | |
+ smi-common
+ ---------------------------
+ | | ...
+ larb0 sub-common ... <-max number is 8
+ ----------------
+ | | ...
+ larb1 larbX ... <-max number is 8
+
properties:
compatible:
oneOf:
@@ -40,6 +55,8 @@ properties:
- mediatek,mt8186-smi-common
- mediatek,mt8188-smi-common-vdo
- mediatek,mt8188-smi-common-vpp
+ - mediatek,mt8189-smi-common
+ - mediatek,mt8189-smi-sub-common
- mediatek,mt8192-smi-common
- mediatek,mt8195-smi-common-vdo
- mediatek,mt8195-smi-common-vpp
@@ -108,6 +125,7 @@ allOf:
compatible:
contains:
enum:
+ - mediatek,mt8189-smi-sub-common
- mediatek,mt8195-smi-sub-common
then:
required:
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index 2e7fac4b5094..9a5dafd7c07e 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -27,6 +27,7 @@ properties:
- mediatek,mt8183-smi-larb
- mediatek,mt8186-smi-larb
- mediatek,mt8188-smi-larb
+ - mediatek,mt8189-smi-larb
- mediatek,mt8192-smi-larb
- mediatek,mt8195-smi-larb
@@ -85,6 +86,7 @@ allOf:
- mediatek,mt8183-smi-larb
- mediatek,mt8186-smi-larb
- mediatek,mt8188-smi-larb
+ - mediatek,mt8189-smi-larb
- mediatek,mt8195-smi-larb
then:
@@ -119,6 +121,7 @@ allOf:
- mediatek,mt6779-smi-larb
- mediatek,mt8186-smi-larb
- mediatek,mt8188-smi-larb
+ - mediatek,mt8189-smi-larb
- mediatek,mt8192-smi-larb
- mediatek,mt8195-smi-larb
--
2.43.0
^ permalink raw reply related
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