* [PATCH v4 7/8] arm64: dts: s32n79: add FlexCAN nodes
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Andra-Teodora Ilie
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
The S32N79 integrates multiple FlexCAN instances connected through the RCU
irqsteer interrupt controller.
Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 +++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/s32n79.dtsi b/arch/arm64/boot/dts/freescale/s32n79.dtsi
index 94ab58783fdc..c1a4fdead91d 100644
--- a/arch/arm64/boot/dts/freescale/s32n79.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32n79.dtsi
@@ -352,6 +352,56 @@ pmu: pmu {
interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
};
+ rcu-bus {
+ compatible = "simple-bus";
+ ranges = <0x54000000 0x0 0x54000000 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ irqsteer_rcu: interrupt-controller@55101000 {
+ compatible = "nxp,s32n79-irqsteer";
+ reg = <0x55101000 0x1000>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0xf9>;
+ clock-names = "ipg";
+ fsl,channel = <0>;
+ fsl,num-irqs = <512>;
+ status = "disabled";
+ };
+
+ can0: can@55b60000 {
+ compatible = "nxp,s32n79-flexcan";
+ reg = <0x55b60000 0x4000>;
+ interrupt-parent = <&irqsteer_rcu>;
+ interrupts = <0>, <64>;
+ interrupt-names = "mb-0", "berr";
+ clocks = <&clks 0xf9>, <&clks 0xfc>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+ };
+
+ can1: can@55b70000 {
+ compatible = "nxp,s32n79-flexcan";
+ reg = <0x55b70000 0x4000>;
+ interrupt-parent = <&irqsteer_rcu>;
+ interrupts = <1>, <65>;
+ interrupt-names = "mb-0", "berr";
+ clocks = <&clks 0xf9>, <&clks 0xfc>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+ };
+ };
+
timer: timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
--
2.43.0
^ permalink raw reply related
* [PATCH v4 6/8] can: flexcan: add NXP S32N79 SoC support
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Andra-Teodora Ilie, Larisa Grigore
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Add device data and compatible string for NXP S32N79 SoC.
FlexCAN IP integration on S32N79 SoC uses two interrupts:
- one for mailboxes 0-127
- one for signaling bus errors and device state changes
Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
---
drivers/net/can/flexcan/flexcan-core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index 23ddf7910641..9ae0d9eb4ccc 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -397,6 +397,15 @@ static const struct flexcan_devtype_data nxp_s32g2_devtype_data = {
FLEXCAN_QUIRK_SECONDARY_MB_IRQ,
};
+static const struct flexcan_devtype_data nxp_s32n_devtype_data = {
+ .quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
+ FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_RX_MAILBOX |
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE | FLEXCAN_QUIRK_SUPPORT_FD |
+ FLEXCAN_QUIRK_SUPPORT_ECC | FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX |
+ FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX_RTR |
+ FLEXCAN_QUIRK_IRQ_BERR,
+};
+
static const struct can_bittiming_const flexcan_bittiming_const = {
.name = DRV_NAME,
.tseg1_min = 4,
@@ -2232,6 +2241,7 @@ static const struct of_device_id flexcan_of_match[] = {
{ .compatible = "fsl,ls1021ar2-flexcan", .data = &fsl_ls1021a_r2_devtype_data, },
{ .compatible = "fsl,lx2160ar1-flexcan", .data = &fsl_lx2160a_r1_devtype_data, },
{ .compatible = "nxp,s32g2-flexcan", .data = &nxp_s32g2_devtype_data, },
+ { .compatible = "nxp,s32n79-flexcan", .data = &nxp_s32n_devtype_data, },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, flexcan_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 5/8] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Larisa Grigore
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Introduce FLEXCAN_QUIRK_IRQ_BERR quirk to handle hardware integration
where the FlexCAN module has a dedicated interrupt line for signaling
bus errors and device state changes.
This adds the flexcan_irq_esr() handler which composes
flexcan_do_state() and flexcan_do_berr() to handle platforms where
these events share a single IRQ line.
Also extend flexcan_chip_interrupts_enable() to disable/enable the
new IRQ line during IMASK register writes.
This is required for NXP S32N79 SoC support.
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
---
drivers/net/can/flexcan/flexcan-core.c | 54 +++++++++++++++++++++-----
drivers/net/can/flexcan/flexcan.h | 2 +
2 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index 32e4d4da00a1..23ddf7910641 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -1293,6 +1293,22 @@ static irqreturn_t flexcan_irq_boff(int irq, void *dev_id)
return handled;
}
+/* Combined bus error and state change IRQ handler */
+static irqreturn_t flexcan_irq_esr(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ irqreturn_t handled;
+
+ handled = flexcan_do_state(dev);
+ handled |= flexcan_do_berr(dev);
+
+ if (handled)
+ can_rx_offload_irq_finish(&priv->offload);
+
+ return handled;
+}
+
static void flexcan_set_bittiming_ctrl(const struct net_device *dev)
{
const struct flexcan_priv *priv = netdev_priv(dev);
@@ -1549,10 +1565,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
u64 reg_imask;
disable_irq(dev->irq);
- if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
+ if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
disable_irq(priv->irq_boff);
+ if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
disable_irq(priv->irq_err);
- }
if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
disable_irq(priv->irq_secondary_mb);
@@ -1564,10 +1580,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
enable_irq(dev->irq);
if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
enable_irq(priv->irq_secondary_mb);
- if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
- enable_irq(priv->irq_boff);
+ if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
enable_irq(priv->irq_err);
- }
+ if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ enable_irq(priv->irq_boff);
}
static void flexcan_chip_interrupts_disable(const struct net_device *dev)
@@ -1891,7 +1907,8 @@ static int flexcan_open(struct net_device *dev)
can_rx_offload_enable(&priv->offload);
- if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ if (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
err = request_irq(dev->irq, flexcan_irq_mb,
IRQF_SHARED, dev->name, dev);
else
@@ -1912,6 +1929,13 @@ static int flexcan_open(struct net_device *dev)
goto out_free_irq_boff;
}
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
+ err = request_irq(priv->irq_err,
+ flexcan_irq_esr, IRQF_SHARED, dev->name, dev);
+ if (err)
+ goto out_free_irq_boff;
+ }
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
err = request_irq(priv->irq_secondary_mb,
flexcan_irq_mb, IRQF_SHARED, dev->name, dev);
@@ -1926,7 +1950,8 @@ static int flexcan_open(struct net_device *dev)
return 0;
out_free_irq_err:
- if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ if (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
free_irq(priv->irq_err, dev);
out_free_irq_boff:
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
@@ -1958,10 +1983,12 @@ static int flexcan_close(struct net_device *dev)
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
free_irq(priv->irq_secondary_mb, dev);
- if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
+ if (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
free_irq(priv->irq_err, dev);
+
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
free_irq(priv->irq_boff, dev);
- }
free_irq(dev->irq, dev);
can_rx_offload_disable(&priv->offload);
@@ -2348,12 +2375,21 @@ static int flexcan_probe(struct platform_device *pdev)
if (transceiver)
priv->can.bitrate_max = transceiver->attrs.max_link_rate;
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
+ priv->irq_err = platform_get_irq_byname(pdev, "berr");
+ if (priv->irq_err < 0) {
+ err = priv->irq_err;
+ goto failed_platform_get_irq;
+ }
+ }
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
priv->irq_boff = platform_get_irq(pdev, 1);
if (priv->irq_boff < 0) {
err = priv->irq_boff;
goto failed_platform_get_irq;
}
+
priv->irq_err = platform_get_irq(pdev, 2);
if (priv->irq_err < 0) {
err = priv->irq_err;
diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
index 22aa097ec3c0..43d4e0da3779 100644
--- a/drivers/net/can/flexcan/flexcan.h
+++ b/drivers/net/can/flexcan/flexcan.h
@@ -74,6 +74,8 @@
* both need to have an interrupt handler registered.
*/
#define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
+/* Setup dedicated bus error and state change IRQ */
+#define FLEXCAN_QUIRK_IRQ_BERR BIT(19)
#define FLEXCAN_NR_MB_IRQS 2
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/8] dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea, Andra-Teodora Ilie, Larisa Grigore,
Conor Dooley
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Add NXP S32N79 SoC compatible string and interrupt properties.
On S32N79, FlexCAN IP is integrated with two interrupt lines:
one for the mailbox interrupts (0-127) and one for signaling
bus errors and device state changes.
Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/net/can/fsl,flexcan.yaml | 30 ++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
index f81d56f7c12a..d098a44c2b9c 100644
--- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
+++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
@@ -26,6 +26,7 @@ properties:
- fsl,ls1021ar2-flexcan
- fsl,lx2160ar1-flexcan
- nxp,s32g2-flexcan
+ - nxp,s32n79-flexcan
- items:
- enum:
- fsl,imx53-flexcan
@@ -173,11 +174,38 @@ allOf:
- const: mb-1
required:
- interrupt-names
- else:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,s32n79-flexcan
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: Message Buffer interrupt for mailboxes 0-127
+ - description: Bus Error and Device state change interrupt
+ interrupt-names:
+ items:
+ - const: mb-0
+ - const: berr
+ required:
+ - interrupt-names
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,s32g2-flexcan
+ - nxp,s32n79-flexcan
+ then:
properties:
interrupts:
maxItems: 1
interrupt-names: false
+
- if:
required:
- xceiver-supply
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
On S32G2, which has two mailbox IRQ lines (mb-0 for MBs 0-7, mb-1
for MBs 8-127), both handlers currently process the full rx_mask/tx_mask
range,
Introduce struct flexcan_mb_irq to hold per-IRQ-line rx and tx masks.
In flexcan_irq_mb(), the irq argument selects the correct mask set: the
primary MB IRQ uses mb_irq[0] and the secondary uses mb_irq[1].
For single-IRQ platforms, mb_irq[0] holds the full combined masks with no
functional change.
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
---
drivers/net/can/flexcan/flexcan-core.c | 61 +++++++++++++++++++-------
drivers/net/can/flexcan/flexcan.h | 10 ++++-
2 files changed, 52 insertions(+), 19 deletions(-)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index 7dde2e623def..32e4d4da00a1 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -957,14 +957,16 @@ static inline void flexcan_write64(struct flexcan_priv *priv, u64 val, void __io
priv->write(lower_32_bits(val), addr);
}
-static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
+static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv,
+ u64 rx_mask)
{
- return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->rx_mask);
+ return flexcan_read64_mask(priv, &priv->regs->iflag1, rx_mask);
}
-static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv)
+static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv,
+ u64 tx_mask)
{
- return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->tx_mask);
+ return flexcan_read64_mask(priv, &priv->regs->iflag1, tx_mask);
}
static inline struct flexcan_priv *rx_offload_to_priv(struct can_rx_offload *offload)
@@ -1071,7 +1073,8 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
}
/* Process mailbox (RX + TX) events */
-static irqreturn_t flexcan_do_mb(struct net_device *dev)
+static irqreturn_t flexcan_do_mb(struct net_device *dev,
+ const struct flexcan_mb_irq *mb_irq)
{
struct net_device_stats *stats = &dev->stats;
struct flexcan_priv *priv = netdev_priv(dev);
@@ -1084,7 +1087,8 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
u64 reg_iflag_rx;
int ret;
- while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv))) {
+ while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv,
+ mb_irq->rx_mask))) {
handled = IRQ_HANDLED;
ret = can_rx_offload_irq_offload_timestamp(&priv->offload,
reg_iflag_rx);
@@ -1110,10 +1114,10 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
}
}
- reg_iflag_tx = flexcan_read_reg_iflag_tx(priv);
+ reg_iflag_tx = flexcan_read_reg_iflag_tx(priv, mb_irq->tx_mask);
/* transmission complete interrupt */
- if (reg_iflag_tx & priv->tx_mask) {
+ if (reg_iflag_tx & mb_irq->tx_mask) {
u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
handled = IRQ_HANDLED;
@@ -1125,7 +1129,7 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
/* after sending a RTR frame MB is in RX mode */
priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
&priv->tx_mb->can_ctrl);
- flexcan_write64(priv, priv->tx_mask, ®s->iflag1);
+ flexcan_write64(priv, mb_irq->tx_mask, ®s->iflag1);
netif_wake_queue(dev);
}
@@ -1228,7 +1232,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
struct flexcan_priv *priv = netdev_priv(dev);
irqreturn_t handled;
- handled = flexcan_do_mb(dev);
+ handled = flexcan_do_mb(dev, &priv->mb_irq[0]);
handled |= flexcan_do_state(dev);
handled |= flexcan_do_berr(dev);
@@ -1243,9 +1247,15 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct flexcan_priv *priv = netdev_priv(dev);
+ const struct flexcan_mb_irq *mb_irq;
irqreturn_t handled;
+ int idx;
- handled = flexcan_do_mb(dev);
+ idx = (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ &&
+ irq == priv->irq_secondary_mb) ? 1 : 0;
+ mb_irq = &priv->mb_irq[idx];
+
+ handled = flexcan_do_mb(dev, mb_irq);
if (handled)
can_rx_offload_irq_finish(&priv->offload);
@@ -1473,6 +1483,7 @@ static void flexcan_ram_init(struct net_device *dev)
static int flexcan_rx_offload_setup(struct net_device *dev)
{
struct flexcan_priv *priv = netdev_priv(dev);
+ u64 rx_mask, tx_mask;
int err;
if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
@@ -1494,20 +1505,35 @@ static int flexcan_rx_offload_setup(struct net_device *dev)
flexcan_get_mb(priv, FLEXCAN_TX_MB_RESERVED_RX_FIFO);
priv->tx_mb_idx = priv->mb_count - 1;
priv->tx_mb = flexcan_get_mb(priv, priv->tx_mb_idx);
- priv->tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
-
priv->offload.mailbox_read = flexcan_mailbox_read;
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_USE_RX_MAILBOX) {
priv->offload.mb_first = FLEXCAN_RX_MB_RX_MAILBOX_FIRST;
priv->offload.mb_last = priv->mb_count - 2;
- priv->rx_mask = GENMASK_ULL(priv->offload.mb_last,
- priv->offload.mb_first);
+ rx_mask = GENMASK_ULL(priv->offload.mb_last,
+ priv->offload.mb_first);
+ tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
+
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
+ /* S32G2 has two MB IRQ lines with the split at MB 8:
+ * mb-0 IRQ handles MBs 0-7,
+ * mb-1 IRQ handles MBs 8-127.
+ */
+ priv->mb_irq[0].rx_mask = rx_mask & GENMASK_ULL(7, 0);
+ priv->mb_irq[0].tx_mask = tx_mask & GENMASK_ULL(7, 0);
+ priv->mb_irq[1].rx_mask = rx_mask & GENMASK_ULL(63, 8);
+ priv->mb_irq[1].tx_mask = tx_mask & GENMASK_ULL(63, 8);
+ } else {
+ priv->mb_irq[0].rx_mask = rx_mask;
+ priv->mb_irq[0].tx_mask = tx_mask;
+ }
+
err = can_rx_offload_add_timestamp(dev, &priv->offload);
} else {
- priv->rx_mask = FLEXCAN_IFLAG_RX_FIFO_OVERFLOW |
+ priv->mb_irq[0].rx_mask = FLEXCAN_IFLAG_RX_FIFO_OVERFLOW |
FLEXCAN_IFLAG_RX_FIFO_AVAILABLE;
+ priv->mb_irq[0].tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
err = can_rx_offload_add_fifo(dev, &priv->offload,
FLEXCAN_NAPI_WEIGHT);
}
@@ -1531,7 +1557,8 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
disable_irq(priv->irq_secondary_mb);
priv->write(priv->reg_ctrl_default, ®s->ctrl);
- reg_imask = priv->rx_mask | priv->tx_mask;
+ reg_imask = priv->mb_irq[0].rx_mask | priv->mb_irq[0].tx_mask |
+ priv->mb_irq[1].rx_mask | priv->mb_irq[1].tx_mask;
priv->write(upper_32_bits(reg_imask), ®s->imask2);
priv->write(lower_32_bits(reg_imask), ®s->imask1);
enable_irq(dev->irq);
diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
index 16692a2502eb..22aa097ec3c0 100644
--- a/drivers/net/can/flexcan/flexcan.h
+++ b/drivers/net/can/flexcan/flexcan.h
@@ -75,10 +75,17 @@
*/
#define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
+#define FLEXCAN_NR_MB_IRQS 2
+
struct flexcan_devtype_data {
u32 quirks; /* quirks needed for different IP cores */
};
+struct flexcan_mb_irq {
+ u64 rx_mask;
+ u64 tx_mask;
+};
+
struct flexcan_stop_mode {
struct regmap *gpr;
u8 req_gpr;
@@ -99,8 +106,7 @@ struct flexcan_priv {
u8 clk_src; /* clock source of CAN Protocol Engine */
u8 scu_idx;
- u64 rx_mask;
- u64 tx_mask;
+ struct flexcan_mb_irq mb_irq[FLEXCAN_NR_MB_IRQS];
u32 reg_ctrl_default;
struct clk *clk_ipg;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/8] can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
On platforms with multiple IRQ lines (S32G2, MCF5441X), all lines are
registered to the same flexcan_irq() handler. Since these are distinct IRQ
numbers, they can be dispatched concurrently on different CPUs. Both
instances then read the same iflag and ESR registers unconditionally,
leading to duplicate frame processing.
Fix this by splitting the monolithic handler into focused parts:
- flexcan_do_mb(): processes mailbox events
- flexcan_do_state(): processes device state change events
- flexcan_do_berr(): processes bus error events
Introduce dedicated IRQ handlers for multi-IRQ platforms:
- flexcan_irq_mb(): mailbox-only, used for mb-0, mb-1 IRQ lines
- flexcan_irq_boff(): state-change-only, used for boff/state IRQ line
- flexcan_irq_berr(): bus-error-only, used for berr IRQ line
The combined flexcan_irq() handler is preserved for single-IRQ
platforms with no functional change.
Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
---
drivers/net/can/flexcan/flexcan-core.c | 128 +++++++++++++++++++++----
1 file changed, 111 insertions(+), 17 deletions(-)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index f5d22c61503f..f73ff442d530 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -1070,16 +1070,14 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
return skb;
}
-static irqreturn_t flexcan_irq(int irq, void *dev_id)
+/* Process mailbox (RX + TX) events */
+static irqreturn_t flexcan_do_mb(struct net_device *dev)
{
- struct net_device *dev = dev_id;
struct net_device_stats *stats = &dev->stats;
struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->regs;
irqreturn_t handled = IRQ_NONE;
u64 reg_iflag_tx;
- u32 reg_esr;
- enum can_state last_state = priv->can.state;
/* reception interrupt */
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_USE_RX_MAILBOX) {
@@ -1131,25 +1129,57 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
netif_wake_queue(dev);
}
+ return handled;
+}
+
+/* Process bus error events */
+static irqreturn_t flexcan_do_berr(struct net_device *dev)
+{
+ struct flexcan_priv *priv = netdev_priv(dev);
+ struct flexcan_regs __iomem *regs = priv->regs;
+ irqreturn_t handled = IRQ_NONE;
+ u32 reg_esr;
+
reg_esr = priv->read(®s->esr);
- /* ACK all bus error, state change and wake IRQ sources */
- if (reg_esr & (FLEXCAN_ESR_ALL_INT | FLEXCAN_ESR_WAK_INT)) {
+ /* ACK bus error interrupt source */
+ if (reg_esr & FLEXCAN_ESR_ERR_INT) {
handled = IRQ_HANDLED;
- priv->write(reg_esr & (FLEXCAN_ESR_ALL_INT | FLEXCAN_ESR_WAK_INT), ®s->esr);
+ priv->write(FLEXCAN_ESR_ERR_INT, ®s->esr);
}
- /* state change interrupt or broken error state quirk fix is enabled */
- if ((reg_esr & FLEXCAN_ESR_ERR_STATE) ||
- (priv->devtype_data.quirks & (FLEXCAN_QUIRK_BROKEN_WERR_STATE |
- FLEXCAN_QUIRK_BROKEN_PERR_STATE)))
- flexcan_irq_state(dev, reg_esr);
-
/* bus error IRQ - handle if bus error reporting is activated */
if ((reg_esr & FLEXCAN_ESR_ERR_BUS) &&
(priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING))
flexcan_irq_bus_err(dev, reg_esr);
+ return handled;
+}
+
+/* Process device state change events */
+static irqreturn_t flexcan_do_state(struct net_device *dev)
+{
+ struct flexcan_priv *priv = netdev_priv(dev);
+ struct flexcan_regs __iomem *regs = priv->regs;
+ irqreturn_t handled = IRQ_NONE;
+ u32 reg_esr;
+ enum can_state last_state = priv->can.state;
+
+ reg_esr = priv->read(®s->esr);
+
+ /* ACK state change and wake IRQ sources */
+ if (reg_esr & (FLEXCAN_ESR_ERR_STATE | FLEXCAN_ESR_WAK_INT)) {
+ handled = IRQ_HANDLED;
+ priv->write(reg_esr & (FLEXCAN_ESR_ERR_STATE | FLEXCAN_ESR_WAK_INT),
+ ®s->esr);
+ }
+
+ /* state change interrupt or broken error state quirk fix is enabled */
+ if ((reg_esr & FLEXCAN_ESR_ERR_STATE) ||
+ (priv->devtype_data.quirks &
+ (FLEXCAN_QUIRK_BROKEN_WERR_STATE | FLEXCAN_QUIRK_BROKEN_PERR_STATE)))
+ flexcan_irq_state(dev, reg_esr);
+
/* availability of error interrupt among state transitions in case
* bus error reporting is de-activated and
* FLEXCAN_QUIRK_BROKEN_PERR_STATE is enabled:
@@ -1188,6 +1218,65 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
}
}
+ return handled;
+}
+
+/* Combined IRQ handler for single-IRQ platforms */
+static irqreturn_t flexcan_irq(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ irqreturn_t handled;
+
+ handled = flexcan_do_mb(dev);
+ handled |= flexcan_do_state(dev);
+ handled |= flexcan_do_berr(dev);
+
+ if (handled)
+ can_rx_offload_irq_finish(&priv->offload);
+
+ return handled;
+}
+
+/* Mailbox IRQ handler for multi-IRQ platforms */
+static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ irqreturn_t handled;
+
+ handled = flexcan_do_mb(dev);
+
+ if (handled)
+ can_rx_offload_irq_finish(&priv->offload);
+
+ return handled;
+}
+
+/* Bus error IRQ handler for multi-IRQ platforms */
+static irqreturn_t flexcan_irq_berr(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ irqreturn_t handled;
+
+ handled = flexcan_do_berr(dev);
+
+ if (handled)
+ can_rx_offload_irq_finish(&priv->offload);
+
+ return handled;
+}
+
+/* Device state change IRQ handler for multi-IRQ platforms */
+static irqreturn_t flexcan_irq_boff(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ irqreturn_t handled;
+
+ handled = flexcan_do_state(dev);
+
if (handled)
can_rx_offload_irq_finish(&priv->offload);
@@ -1761,25 +1850,30 @@ static int flexcan_open(struct net_device *dev)
can_rx_offload_enable(&priv->offload);
- err = request_irq(dev->irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
+ err = request_irq(dev->irq, flexcan_irq_mb,
+ IRQF_SHARED, dev->name, dev);
+ else
+ err = request_irq(dev->irq, flexcan_irq,
+ IRQF_SHARED, dev->name, dev);
if (err)
goto out_can_rx_offload_disable;
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
err = request_irq(priv->irq_boff,
- flexcan_irq, IRQF_SHARED, dev->name, dev);
+ flexcan_irq_boff, IRQF_SHARED, dev->name, dev);
if (err)
goto out_free_irq;
err = request_irq(priv->irq_err,
- flexcan_irq, IRQF_SHARED, dev->name, dev);
+ flexcan_irq_berr, IRQF_SHARED, dev->name, dev);
if (err)
goto out_free_irq_boff;
}
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
err = request_irq(priv->irq_secondary_mb,
- flexcan_irq, IRQF_SHARED, dev->name, dev);
+ flexcan_irq_mb, IRQF_SHARED, dev->name, dev);
if (err)
goto out_free_irq_err;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/8] can: flexcan: disable all IRQ lines in flexcan_chip_interrupts_enable()
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
flexcan_chip_interrupts_enable() disables only the primary IRQ line while
writing to the IMASK and CTRL registers.
On multi-IRQ platforms (S32G2, MCF5441X), the additional IRQ lines (boff,
err, secondary-mb) remain active so their handlers can fire while
registers are inconsistent.
Disable all registered IRQ lines around the IMASK/CTRL writes. This
also fixes the resume path, which calls this function.
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
---
drivers/net/can/flexcan/flexcan-core.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
index f73ff442d530..7dde2e623def 100644
--- a/drivers/net/can/flexcan/flexcan-core.c
+++ b/drivers/net/can/flexcan/flexcan-core.c
@@ -1519,14 +1519,28 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
{
const struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->regs;
+ u32 quirks = priv->devtype_data.quirks;
u64 reg_imask;
disable_irq(dev->irq);
+ if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
+ disable_irq(priv->irq_boff);
+ disable_irq(priv->irq_err);
+ }
+ if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
+ disable_irq(priv->irq_secondary_mb);
+
priv->write(priv->reg_ctrl_default, ®s->ctrl);
reg_imask = priv->rx_mask | priv->tx_mask;
priv->write(upper_32_bits(reg_imask), ®s->imask2);
priv->write(lower_32_bits(reg_imask), ®s->imask1);
enable_irq(dev->irq);
+ if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
+ enable_irq(priv->irq_secondary_mb);
+ if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
+ enable_irq(priv->irq_boff);
+ enable_irq(priv->irq_err);
+ }
}
static void flexcan_chip_interrupts_disable(const struct net_device *dev)
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Costea @ 2026-03-26 13:58 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Ciprian Marian Costea
From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
This patch series adds FlexCAN support for the NXP S32N79 SoC.
The S32N79 is an automotive-grade processor from NXP with multiple
FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
other SoCs in the interrupt routing - it uses two separate interrupt
lines:
- one interrupt for mailboxes 0-127
- one interrupt for bus error detection and device state changes
The CAN controllers are connected through an irqsteer interrupt
controller in the RCU (Resource Control Unit) domain.
This series:
1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
2. Adds dt-bindings documentation for S32N79 FlexCAN
3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
configuration
4. Adds S32N79 device data and compatible string to the driver
5. Adds FlexCAN device tree nodes for S32N79 SoC
6. Enables FlexCAN devices on the S32N79-RDB board
Tested on S32N79-RDB board with CAN and CAN FD communication.
v4 -> v3
- flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
(not just dev->irq) during IMASK register writes
- Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
each handler on S32G2 only processes its own MB range
- Added received Acked-by tag on DT bindings patch
v3 -> v2
- Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
processing when multiple IRQ lines run concurrently (new patch).
- Added flexcan_irq_esr() handler composing state + berr for S32N79
- Ordered quirks used by s32n devtype data by value.
v2 -> v1
- Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
describe the actual hardware feature
- Appended new quirk at the end
- Switched from platform_get_irq to platform_get_irq_byname usage
- Updated interrupt description in dt-bindings
Ciprian Marian Costea (8):
can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
can: flexcan: disable all IRQ lines in
flexcan_chip_interrupts_enable()
can: flexcan: split rx/tx masks per mailbox IRQ line
dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
can: flexcan: add NXP S32N79 SoC support
arm64: dts: s32n79: add FlexCAN nodes
arm64: dts: s32n79: enable FlexCAN devices
.../bindings/net/can/fsl,flexcan.yaml | 30 ++-
arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
drivers/net/can/flexcan/flexcan-core.c | 249 +++++++++++++++---
drivers/net/can/flexcan/flexcan.h | 12 +-
5 files changed, 316 insertions(+), 37 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v9 04/11] drm/fourcc: Add DRM_FORMAT_XYYY2101010
From: Simon Ser @ 2026-03-26 13:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen,
Pekka Paalanen
In-Reply-To: <20260325-xilinx-formats-v9-4-d03b7e3752e4@ideasonboard.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
^ permalink raw reply
* Re: [PATCH v8 04/11] drm/fourcc: Add DRM_FORMAT_Y10_P32
From: Simon Ser @ 2026-03-26 13:55 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen,
Pekka Paalanen
In-Reply-To: <d0728f98-f964-4321-a34a-022f28f268cc@ideasonboard.com>
On Friday, March 20th, 2026 at 11:48, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
> Hi,
>
> On 19/03/2026 16:59, Simon Ser wrote:
> > On Wednesday, January 28th, 2026 at 18:25, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
> >
> >> Add Y10_P32, a 10 bit greyscale format, with 3 pixels packed into
> >> 32-bit container.
> >>
> >> The fourcc for the format is 'YPA4', which comes from Y - Y only, P -
> >> packed, A - 10 (as in 0xA), 4 - 4 bytes.
> >
> > I know we aren't super consistent about DRM format names, but… this _P32
> > suffix doesn't make sense to me: we never had it before, and a lot of
> > DRM formats are packed (in the Vulkan sense [1]), so I'm not sure why
> > this one would need it.
> >
> > What's special about this one is that it's the first (AFAIK) which has
> > 3 pixels per block. Some YCbCr formats are sub-sampled, but always use a
> > square block.
> >
> > I would suggest something like YYYX1010102. We use the "channels
> > followed by bits per component" pattern elsewhere.
> I'm ok with that. But wouldn't it be XYYY2101010 instead?
Oh yes, indeed.
> And then we just wait for someone to add a x:Y0:Y1:Y2 format (instead of
> x:Y2:Y1:Y0). Should we be more specific, and already make this one
> XY2Y1Y0_2101010...
Looking at all existing YCbCr formats, they all use the Y2-Y1-Y0 ordering,
none of them use the reverse. So I'd say it's safe enough to just leave it
out and treat it as the default. We can think of a new pattern if/when we
hit the reverse case.
^ permalink raw reply
* [PATCH] arm64: dts: ti: k3-j7200: Fix QSGMII overlay by adding SERDES PHY
From: Chintan Vankar @ 2026-03-26 13:49 UTC (permalink / raw)
To: Siddharth Vadapalli, Andrew Davis, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, Tero Kristo,
Vignesh Raghavendra, Nishanth Menon
Cc: linux-kernel, devicetree, linux-arm-kernel, c-vankar
For CPSW5G QSGMII ports, CPSW assumes SERDES to be configured. Since it
may not be always true, add SERDES phys to guarantee it.
Fixes: 496cdc82e05f ("arm64: dts: ti: k3-j7200: Add overlay to enable CPSW5G ports in QSGMII mode")
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
---
This patch is based on commit "0138af2472df" of origin/master branch of
Linux repo.
arch/arm64/boot/dts/ti/k3-j7200-evm-quad-port-eth-exp.dtso | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-evm-quad-port-eth-exp.dtso b/arch/arm64/boot/dts/ti/k3-j7200-evm-quad-port-eth-exp.dtso
index 6432ca08ee8e..4824d53c95bb 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-evm-quad-port-eth-exp.dtso
+++ b/arch/arm64/boot/dts/ti/k3-j7200-evm-quad-port-eth-exp.dtso
@@ -32,7 +32,8 @@ &cpsw0_port1 {
phy-handle = <&cpsw5g_phy0>;
phy-mode = "qsgmii";
mac-address = [00 00 00 00 00 00];
- phys = <&cpsw0_phy_gmii_sel 1>;
+ phys = <&cpsw0_phy_gmii_sel 1>, <&serdes0_qsgmii_link>;
+ phy-names = "mac", "serdes";
};
&cpsw0_port2 {
--
2.34.1
^ permalink raw reply related
* Re: Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Miguel Ojeda @ 2026-03-26 13:47 UTC (permalink / raw)
To: Alice Ryhl, Christian Schrefl, Ard Biesheuvel, Jamie Cunliffe,
Will Deacon, Catalin Marinas
Cc: Russell King (Oracle), Miguel Ojeda, a.hindborg, acourbot, akpm,
anton.ivanov, bjorn3_gh, boqun.feng, dakr, david, gary, johannes,
justinstitt, linux-arm-kernel, linux-kbuild, linux-kernel,
linux-mm, linux-um, llvm, lossin, mark.rutland, mmaurer, morbo,
nathan, nick.desaulniers+lkml, nicolas.schier, nsc, peterz,
richard, rust-for-linux, tmgross, urezki
In-Reply-To: <acUGAsjYvNvTEO92@google.com>
On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> I noticed that the Makefile currently uses the arm-unknown-linux-gnueabi
> target. It should probably not be -linux target to avoid this? Probably
> it should just be armv7a-none-eabi, right? We gate HAVE_RUST on
> CPU_32v7, so we should not need to consider the other variants.
I think Christian tried several targets back then and eventually
picked that one.
Christian: what was the reason to pick the `-linux-` one? e.g. was
there something you wanted to rely on that target spec that you
couldn't enable or disable via `rustc` flags or similar?
Cc'ing a few folks.
Thanks!
Cheers,
Miguel
^ permalink raw reply
* [GIT PULL] Qualcomm clock fix for v7.0
From: Bjorn Andersson @ 2026-03-26 13:45 UTC (permalink / raw)
To: Stephen Boyd, linux-clk; +Cc: linux-arm-msm, linux-arm-kernel, Dmitry Baryshkov
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-fixes-for-7.0
for you to fetch changes up to 141af1be817c42c7f1e1605348d4b1983d319bea:
clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source (2026-02-23 10:45:35 -0600)
----------------------------------------------------------------
Qualcomm clock fix for v7.0
Fix the clock ops for SM8450 DPTX1 aux clock src to ensure DisplayPort
works.
----------------------------------------------------------------
Dmitry Baryshkov (1):
clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source
drivers/clk/qcom/dispcc-sm8450.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Dave Stevenson @ 2026-03-26 13:39 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acUi6NEPJ0p48a3U@intel.com>
On Thu, 26 Mar 2026 at 12:13, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Mar 26, 2026 at 11:16:12AM +0000, Dave Stevenson wrote:
> > On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > > On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > >
> > > > > Add a new general DRM property named "color format" which can be used by
> > > > > userspace to request the display driver to output a particular color
> > > > > format.
> > > > >
> > > > > Possible options are:
> > > > > - auto (setup by default, driver internally picks the color format)
> > > > > - rgb
> > > > > - ycbcr444
> > > > > - ycbcr422
> > > > > - ycbcr420
> > > > >
> > > > > Drivers should advertise from this list which formats they support.
> > > > > Together with this list and EDID data from the sink we should be able
> > > > > to relay a list of usable color formats to users to pick from.
> > > > >
> > > > > Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
> > > > > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> > > > > Co-developed-by: Andri Yngvason <andri@yngvason.is>
> > > > > Signed-off-by: Andri Yngvason <andri@yngvason.is>
> > > > > Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> > > > > Reviewed-by: Maxime Ripard <mripard@kernel.org>
> > > > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > > > > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > > > > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > > > > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > > > > 4 files changed, 228 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > index 26953ed6b53e..b7753454b777 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > > > > if (old_connector_state->max_requested_bpc !=
> > > > > new_connector_state->max_requested_bpc)
> > > > > new_crtc_state->connectors_changed = true;
> > > > > +
> > > > > + if (old_connector_state->color_format !=
> > > > > + new_connector_state->color_format)
> > > > > + new_crtc_state->connectors_changed = true;
> > > > > +
> > > > > }
> > > > >
> > > > > if (funcs->atomic_check)
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > index 5bd5bf6661df..dee510c85e59 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > > state->privacy_screen_sw_state = val;
> > > > > } else if (property == connector->broadcast_rgb_property) {
> > > > > state->hdmi.broadcast_rgb = val;
> > > > > + } else if (property == connector->color_format_property) {
> > > > > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > > > > + drm_dbg_atomic(connector->dev,
> > > > > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > > > > + connector->base.id, connector->name, val);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + state->color_format = val;
> > > > > } else if (connector->funcs->atomic_set_property) {
> > > > > return connector->funcs->atomic_set_property(connector,
> > > > > state, property, val);
> > > > > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > > > > *val = state->privacy_screen_sw_state;
> > > > > } else if (property == connector->broadcast_rgb_property) {
> > > > > *val = state->hdmi.broadcast_rgb;
> > > > > + } else if (property == connector->color_format_property) {
> > > > > + *val = state->color_format;
> > > > > } else if (connector->funcs->atomic_get_property) {
> > > > > return connector->funcs->atomic_get_property(connector,
> > > > > state, property, val);
> > > > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > > > index 47dc53c4a738..e848374dee0b 100644
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> > > > >
> > > > > +static const u32 hdmi_colorformats =
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > > +
> > > > > +static const u32 dp_colorformats =
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > > +
> > > > > /*
> > > > > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > > > > * Format Table 2-120
> > > > > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > > > > }
> > > > > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> > > > >
> > > > > +/**
> > > > > + * drm_connector_attach_color_format_property - create and attach color format property
> > > > > + * @connector: connector to create the color format property on
> > > > > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > > > > + * values the connector supports
> > > > > + *
> > > > > + * Called by a driver to create a color format property. The property is
> > > > > + * attached to the connector automatically on success.
> > > > > + *
> > > > > + * @supported_color_formats should only include color formats the connector
> > > > > + * type can actually support.
> > > > > + *
> > > > > + * Returns:
> > > > > + * 0 on success, negative errno on error
> > > > > + */
> > > > > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > > > > + unsigned long supported_color_formats)
> > > > > +{
> > > > > + struct drm_device *dev = connector->dev;
> > > > > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > > > > + unsigned int i = 0;
> > > > > + unsigned long fmt;
> > > > > +
> > > > > + if (connector->color_format_property)
> > > > > + return 0;
> > > > > +
> > > > > + if (!supported_color_formats) {
> > > > > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > > > > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + switch (connector->connector_type) {
> > > > > + case DRM_MODE_CONNECTOR_HDMIA:
> > > > > + case DRM_MODE_CONNECTOR_HDMIB:
> > > > > + if (supported_color_formats & ~hdmi_colorformats) {
> > > > > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + break;
> > > > > + case DRM_MODE_CONNECTOR_DisplayPort:
> > > > > + case DRM_MODE_CONNECTOR_eDP:
> > > > > + if (supported_color_formats & ~dp_colorformats) {
> > > > > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + enum_list[0].name = "AUTO";
> > > > > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > > > > +
> > > > > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > > > > + switch (fmt) {
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > > > > + break;
> > > > > + default:
> > > > > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > > > > + fmt, connector->base.id, connector->name);
> > > > > + continue;
> > > > > + }
> > > > > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > > > > + }
> > > > > +
> > > > > + connector->color_format_property =
> > > > > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > > > > + enum_list, i + 1);
> > > > > +
> > > > > + if (!connector->color_format_property)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > > > > +
> > > > > /**
> > > > > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > > > > * @old_state: old connector state to compare
> > > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > > --- a/include/drm/drm_connector.h
> > > > > +++ b/include/drm/drm_connector.h
> > > > > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > > > > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > > > > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > > > > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > > > > + * Number of valid output color format values in this enum
> > > > > */
> > > > > enum drm_output_color_format {
> > > > > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > > > > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > > > > };
> > > > >
> > > > > +/**
> > > > > + * enum drm_connector_color_format - Connector Color Format Request
> > > > > + *
> > > > > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > > > > + * for a specific color format on a connector through the DRM "color format"
> > > > > + * property. The difference is that it has an "AUTO" value to specify that
> > > > > + * no specific choice has been made.
> > > > > + */
> > > > > +enum drm_connector_color_format {
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > + * semantics.
> > > > > + *
> > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > + * YCbCr 4:2:0.
> > > >
> > > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> > >
> > > On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
> > > compared to 8bpc 4:4:4.
> >
> > It does save bandwidth against 10 or 12bpc RGB 4:4:4.
> >
> > Or is the implication that max_bpc = 12 and
> > DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select
> > RGB in preference to selecting 4:2:2?
>
> Yeah, YCbCr has all kinds of extra complications compared to RGB, so
> the policy is to use RGB if possible, and only fall back to YCbCr as a
> last resort. And in that case 4:2:0 is the only thing that can help.
So a media player wanting to do 12bpc HDR playback at 4k60 over HDMI
2.0 ends up with 8bpc RGB regardless. That sucks.
I guess at least an override is being added so userspace can take control.
I'd missed that vc4 had its behaviour changed with the
drm_hdmi_state_helper update :-(
Dave
^ permalink raw reply
* [GIT PULL] Qualcomm Arm64 DeviceTree fixes for v7.0
From: Bjorn Andersson @ 2026-03-26 13:38 UTC (permalink / raw)
To: arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Sumit Garg,
Loic Poulain, Daniel J Blueman, Ravi Hothi
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-fixes-for-7.0
for you to fetch changes up to 2c409e03fc04b5cded81b7add9ce509706c922e3:
arm64: dts: qcom: agatti: Fix IOMMU DT properties (2026-03-23 22:31:40 -0500)
----------------------------------------------------------------
Qualcomm Arm64 DeviceTree fixes for v7.0
Fix the idle exit latency numbers on Hamoa, to resolve the issue that
Linux points out that the numbers are incorrect.
Fix the WCD9370 reset polarity on QCM6490 IDP.
Correct the Monaco UART10 pinconf, to apply to the correct pins.
Add reserved-memory region for Gunyah in Monaco, as the entry in UEFI
memory map is incomplete.
Fix the iommu stream specifiers for display, GPU, and video codec as the
current values aren't accepted on systems with Gunyah.
----------------------------------------------------------------
Daniel J Blueman (1):
arm64: dts: qcom: hamoa/x1: fix idle exit latency
Loic Poulain (2):
arm64: dts: qcom: monaco: Fix UART10 pinconf
arm64: dts: qcom: monaco: Reserve full Gunyah metadata region
Ravi Hothi (1):
arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity
Sumit Garg (3):
dt-bindings: display: msm: qcm2290-mdss: Fix iommus property
dt-bindings: media: venus: Fix iommus property
arm64: dts: qcom: agatti: Fix IOMMU DT properties
.../devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 6 ++----
.../devicetree/bindings/media/qcom,qcm2290-venus.yaml | 7 ++-----
arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
arch/arm64/boot/dts/qcom/monaco.dtsi | 9 +++++++--
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 2 +-
6 files changed, 16 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: connector: add pd-disable dependency
From: Frank Li @ 2026-03-26 13:36 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, amitsd,
gregkh, kyletso, Xu Yang
Cc: devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260312071609.388047-1-xu.yang_2@nxp.com>
On Thu, 12 Mar 2026 15:16:08 +0800, Xu Yang wrote:
> When Power Delivery is not supported, the source is unable to obtain the
> current capability from the Source PDO. As a result, typec-power-opmode
> needs to be added to advertise such capability.
>
>
Applied, thanks!
[2/2] arm64: dts: freescale: imx8mp-moduline-display-106: add typec-power-opmode property
commit: 057756df6770c033eb8ebbc9b0066f6602e99b08
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 05/17] firmware: arm_scmi: Add Telemetry protocol support
From: Cristian Marussi @ 2026-03-26 13:32 UTC (permalink / raw)
To: Elif Topuz
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, d-gole, jonathan.cameron, lukasz.luba,
philip.radford, souvik.chakravarty
In-Reply-To: <02534a48-6795-4948-9348-fe507e8810fd@arm.com>
On Fri, Jan 23, 2026 at 11:00:46AM +0000, Elif Topuz wrote:
>
> Hi Cristian,
HI Elif,
a long overdue reply from me !
Thanks for having a look at this series...
>
> On 14/01/2026 11:46, Cristian Marussi wrote:
> > Add basic support for SCMI V4.0 Telemetry protocol including SHMTI,
> > FastChannels, Notifications and Single Sample Reads collection methods.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > v1 --> v2
> > - Add proper ioread accessors for TDCF areas
> > - Rework resource allocation logic and lifecycle
> > - Introduce new resources accessors and res_get() operation to
> > implement lazy enumeration
> > - Support boot-on telemetry:
> > + Add DE_ENABLED_LIST cmd support
> > + Add CONFIG_GET cmd support
> > + Add TDCF_SCAN for best effort enumeration
> > + Harden driver against out-of-spec FW with out of spec cmds
> > - Use FCs list
> > - Rework de_info_lookup to a moer general de_lookup
> > - Fixed reset to use CONFIG_GET and DE_ENABLED_LIST to gather initial
> > state
> > - Using sign_extend32 helper
> > - Added counted_by marker where appropriate
> > ---
> > drivers/firmware/arm_scmi/Makefile | 2 +-
> > drivers/firmware/arm_scmi/driver.c | 2 +
> > drivers/firmware/arm_scmi/protocols.h | 1 +
> > drivers/firmware/arm_scmi/telemetry.c | 2671 +++++++++++++++++++++++++
> > include/linux/scmi_protocol.h | 188 +-
> > 5 files changed, 2862 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/firmware/arm_scmi/telemetry.c
> >
[snip]
> > + /* Build composing DES string */
> > + for (int i = 0; i < ti->info.base.num_groups; i++) {
> > + struct scmi_telemetry_group *grp = &rinfo->grps[i];
> > + size_t bufsize = grp->info->num_des * 11 + 1;
> > + char *buf = grp->des_str;
> > +
> > + for (int j = 0; j < grp->info->num_des; j++) {
> > + char term = j != (grp->info->num_des - 1) ? ' ' : '\0';
> > + int len;
> > +
> > + len = scnprintf(buf, bufsize, "0x%04X%c",
>
> I think it should be 0x%08X%c to print 8 bytes.
>
Good catch ! I will fix..
> > + rinfo->des[grp->des[j]]->info->id, term);
> > +
> > + buf += len;
> > + bufsize -= len;
> > + }
> > + }
> > +
[snip]
> > +
> > +static int scmi_telemetry_tdcf_line_parse(struct telemetry_info *ti,
> > + struct payload __iomem *payld,
> > + struct telemetry_shmti *shmti,
> > + enum scan_mode mode)
> > +{
> > + int used_qwords;
> > +
> > + used_qwords = (USE_LINE_TS(payld) && TS_VALID(payld)) ?
> > + QWORDS_TS_LINE_DATA_PAYLD : QWORDS_LINE_DATA_PAYLD;
>
> If I understand correctly from the "chat with ATG" comments below, when
> timestamp is disabled (after DE is enabled with timestamp), physically ts line
> is still there (use_line_ts = 1 and ts_valid = 0). That's why I think we need to
> drop TS_VALID(payld) check. Otherwise qwords will be QWORDS_LINE_DATA_PAYLD
> although ts line exists.
>
> Also, for the alpha version of the spec, the combination of use_line_ts = 1 and
> ts_valid = 0 doesn't seem to be possible as I understand. But I think beta
> version allows us?
Yes indeed ALPHA_0 definition of TS Line fields was ambiguos but now in
BETA the field is more explicitly called as LineExtension bit field...so
the code in the upcoming V3 will change accordingly.
>
> > +
> > + /* Invalid lines are not an error, could simply be disabled DEs */
> > + if (DATA_INVALID(payld))
> > + return used_qwords;
> > +
> > + if (!IS_BLK_TS(payld))
> > + scmi_telemetry_tdcf_data_parse(ti, payld, shmti, mode);
> > + else
> > + scmi_telemetry_tdcf_blkts_parse(ti, payld, shmti);
> > +
> > + return used_qwords;
> > +}
> > +
> > +static int scmi_telemetry_shmti_scan(struct telemetry_info *ti,
> > + unsigned int shmti_id, u64 ts,
> > + enum scan_mode mode)
>
> ts is not used in the function.
>
Yes indeed I have removed it in V3.
> > +{
> > + struct telemetry_shmti *shmti = &ti->shmti[shmti_id];
> > + struct tdcf __iomem *tdcf = shmti->base;
> > + int retries = SCMI_TLM_TDCF_MAX_RETRIES;
> > + u64 startm = 0, endm = TDCF_BAD_END_SEQ;
> > + void *eplg = SHMTI_EPLG(shmti);
> > +
> > + if (!tdcf)
> > + return -ENODEV;
> > +
[snip]
> > +
> > + de_id = le32_to_cpu(payld->id);
> > + de = xa_load(&ti->xa_des, de_id);
> > + if (!de || !de->enabled) {
> > + dev_err(ti->ph->dev,
> > + "MSG - Received INVALID DE - ID:%u enabled:%d\n",
>
> enabled:%c?
>
Yep
> > + de_id, de ? (de->enabled ? 'Y' : 'N') : 'X');
> > + continue;
[snip]
> > struct scmi_power_state_changed_report {
> > @@ -1114,4 +1292,12 @@ struct scmi_powercap_meas_changed_report {
> > unsigned int domain_id;
> > unsigned int power;
> > };
> > +
> > +struct scmi_telemetry_update_report {
> > + ktime_t timestamp;
> > + unsigned int agent_id;
> > + int status;
> > + unsigned int num_dwords;
> > + unsigned int dwords[];
> > +};
> > #endif /* _LINUX_SCMI_PROTOCOL_H */
>
> Thanks,
> Elif
Thanks for the review !
Cristian
PS: (nitpick) you should trim your review replies to remove all the long
bunch of code that you are not comenting on (leaving a [snip] placeholder
as I did above)... it helps finding your comments in the sea of code...
^ permalink raw reply
* [GIT PULL] Qualcomm driver fixes for v7.0
From: Bjorn Andersson @ 2026-03-26 13:31 UTC (permalink / raw)
To: arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Konrad Dybcio,
Mukesh Ojha
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-fixes-for-7.0
for you to fetch changes up to a343fb1e03cfc9f6dc83a5efb2a8d33e9cdaf6b9:
soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition (2026-03-18 21:51:11 -0500)
----------------------------------------------------------------
Qualcomm driver fixes for v7.0
Fix the length of the PD restart reason string in pd-mapper to avoid
QMI decoding errors, resulting in the notification being dropped.
Fix the newly introduce handling of TBT/USB4 notifications in pmic_glink
altmode driver, as it broke the handling of non-TBT/USB4 DisplayPort
unplug events.
----------------------------------------------------------------
Konrad Dybcio (2):
soc: qcom: pmic_glink_altmode: Fix SVID=DP && unconnected edge case
soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition
Mukesh Ojha (1):
soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei
drivers/soc/qcom/pdr_internal.h | 2 +-
drivers/soc/qcom/pmic_glink_altmode.c | 39 +++++++++++++++++++++++++----------
drivers/soc/qcom/qcom_pdr_msg.c | 2 +-
include/linux/soc/qcom/pdr.h | 1 +
4 files changed, 31 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-26 13:26 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acUvg3Y7kMf2qioK@intel.com>
On Thursday, 26 March 2026 14:07:15 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 01:44:03PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > +enum drm_connector_color_format {
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > + * semantics.
> > > > > > > > + *
> > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > + *
> > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > + * how HDMI does it).
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > + * not subsampled)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > + * with horizontal subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > >
> > > > > > > Seems like this should document what the quantization range
> > > > > > > should be for each format.
> > > > > > >
> > > > > >
> > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > enum is more abstract than that, and is there to communicate
> > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > by other properties.
> > > > > >
> > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > be added; no digital display protocol standard supports it to my
> > > > > > knowledge, and hopefully none ever will.
> > > > >
> > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > >
> > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > RGB can either be full or limited range depending on the
> > > > > "Broadcast RGB" property and other related factors.
> > > >
> > > > So far the HDMI state has both the format and quantization range as
> > > > different fields. I'm not sure we need to document the range in the
> > > > format field, maybe only mention it's not part of the format but has a
> > > > field of its own?
> > >
> > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > I think the assumption is limited range everywhere.
> > >
> > > But I'm not really concerned about documenting struct members.
> > > What I'm talking about is the *uapi* docs. Surely userspace
> > > will want to know what the new property actually does so the
> > > uapi needs to be documented properly. And down the line some
> > > new driver might also implement the wrong behaviour if there
> > > is no clear specification.
> > >
> > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > - YCbCr limited range
> > > - RGB full range if "Broadcast RGB" property is not present
> > > - RGB full or limited range based on the "Broadcast RGB" property
> > > if it's present
> > >
> > > I think the "Broadcast RGB" property itself might also be lacking
> > > proper uapi docs, so that may need to be remedied as well.
> > >
> > >
> >
> > Alright, so in v12 I'll do the following:
> >
> > - Add a line to all YCBCR connector formats that specifies they're
> > limited range as long as Broadcast RGB is limited. Whether it's limited
> > range when Broadcast RGB is full is purposefully left undefined.
>
> "Broadcast RGB", as the name implies, only affects RGB output.
Alright, I'll scratch the overcomplicated undefined behaviour thing
and just say it's limited range, and in the future, we can extend it
to limited range by default but full range if another new property is
set.
>
> > In the future, we can expand this to state they're limited range by
> > default unless some other property is set. If we're not re-using
> > Broadcast RGB for that, this will work out fine, because users who
> > don't know about the eventual new property won't have this behaviour
> > changed. If we do re-use "Broadcast RGB" for that, then only users
> > relying on things we explicitly left undefined will get surprise
> > full range YCBCR.
> > - Add a line to the RGB connector format that specifies its range
> > depends on the "Broadcast RGB" property
> >
> > This is a bit of a mess, because it's entirely reasonable that a
> > future YCBCR range property would want to default to full range
> > so that users get the most color out of their monitors. But with
> > this description of the connector color formats, we can't do that.
> >
> > If there are alternate suggestions, I'm open for them. We can't
> > really rename "Broadcast RGB" but if I had a time machine, that'd
> > be my first choice.
> >
> > Kind regards,
> > Nicolas Frattaroli
> >
>
>
^ permalink raw reply
* Re: [PATCH] ACPI: APEI: Handle repeated SEA error interrupts storm scenarios
From: hejunhao @ 2026-03-26 13:26 UTC (permalink / raw)
To: Shuai Xue, Rafael J. Wysocki, Luck, Tony
Cc: bp, guohanjun, mchehab, jarkko, yazen.ghannam, jane.chu, lenb,
Jonathan.Cameron, linux-acpi, linux-arm-kernel, linux-kernel,
linux-edac, shiju.jose, tanxiaofei, Linuxarm, Junhao He
In-Reply-To: <96f505ac-dc5e-45df-8641-deabb973b5f3@linux.alibaba.com>
On 2026/3/25 20:40, Shuai Xue wrote:
>
>
> On 3/25/26 5:24 PM, hejunhao wrote:
>>
>>
>> On 2026/3/25 10:12, Shuai Xue wrote:
>>> Hi, junhao
>>>
>>> On 3/24/26 6:04 PM, hejunhao wrote:
>>>> Hi shuai xue,
>>>>
>>>>
>>>> On 2026/3/3 22:42, Shuai Xue wrote:
>>>>> Hi, junhao,
>>>>>
>>>>> On 2/27/26 8:12 PM, hejunhao wrote:
>>>>>>
>>>>>>
>>>>>> On 2025/11/4 9:32, Shuai Xue wrote:
>>>>>>>
>>>>>>>
>>>>>>> 在 2025/11/4 00:19, Rafael J. Wysocki 写道:
>>>>>>>> On Thu, Oct 30, 2025 at 8:13 AM Junhao He <hejunhao3@h-partners.com> wrote:
>>>>>>>>>
>>>>>>>>> The do_sea() function defaults to using firmware-first mode, if supported.
>>>>>>>>> It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA
>>>>>>>>> error, The GHES uses a buffer to cache the most recent 4 kinds of SEA
>>>>>>>>> errors. If the same kind SEA error continues to occur, GHES will skip to
>>>>>>>>> reporting this SEA error and will not add it to the "ghes_estatus_llist"
>>>>>>>>> list until the cache times out after 10 seconds, at which point the SEA
>>>>>>>>> error will be reprocessed.
>>>>>>>>>
>>>>>>>>> The GHES invoke ghes_proc_in_irq() to handle the SEA error, which
>>>>>>>>> ultimately executes memory_failure() to process the page with hardware
>>>>>>>>> memory corruption. If the same SEA error appears multiple times
>>>>>>>>> consecutively, it indicates that the previous handling was incomplete or
>>>>>>>>> unable to resolve the fault. In such cases, it is more appropriate to
>>>>>>>>> return a failure when encountering the same error again, and then proceed
>>>>>>>>> to arm64_do_kernel_sea for further processing.
>>>>>
>>>>> There is no such function in the arm64 tree. If apei_claim_sea() returns
>>>>
>>>> Sorry for the mistake in the commit message. The function arm64_do_kernel_sea() should
>>>> be arm64_notify_die().
>>>>
>>>>> an error, the actual fallback path in do_sea() is arm64_notify_die(),
>>>>> which sends SIGBUS?
>>>>>
>>>>
>>>> If apei_claim_sea() returns an error, arm64_notify_die() will call arm64_force_sig_fault(inf->sig /* SIGBUS */, , , ),
>>>> followed by force_sig_fault(SIGBUS, , ) to force the process to receive the SIGBUS signal.
>>>
>>> So the process is expected to killed by SIGBUS?
>>
>> Yes. The devmem process is expected to terminate upon receiving a SIGBUS signal, you can
>> see this at the last line of the test log after the patch is applied.
>> For other processes whether it terminates depends on whether it catches the signal; the kernel is
>> responsible for sending it immediately.
>>
>>>
>>>>
>>>>>>>>>
>>>>>>>>> When hardware memory corruption occurs, a memory error interrupt is
>>>>>>>>> triggered. If the kernel accesses this erroneous data, it will trigger
>>>>>>>>> the SEA error exception handler. All such handlers will call
>>>>>>>>> memory_failure() to handle the faulty page.
>>>>>>>>>
>>>>>>>>> If a memory error interrupt occurs first, followed by an SEA error
>>>>>>>>> interrupt, the faulty page is first marked as poisoned by the memory error
>>>>>>>>> interrupt process, and then the SEA error interrupt handling process will
>>>>>>>>> send a SIGBUS signal to the process accessing the poisoned page.
>>>>>>>>>
>>>>>>>>> However, if the SEA interrupt is reported first, the following exceptional
>>>>>>>>> scenario occurs:
>>>>>>>>>
>>>>>>>>> When a user process directly requests and accesses a page with hardware
>>>>>>>>> memory corruption via mmap (such as with devmem), the page containing this
>>>>>>>>> address may still be in a free buddy state in the kernel. At this point,
>>>>>>>>> the page is marked as "poisoned" during the SEA claim memory_failure().
>>>>>>>>> However, since the process does not request the page through the kernel's
>>>>>>>>> MMU, the kernel cannot send SIGBUS signal to the processes. And the memory
>>>>>>>>> error interrupt handling process not support send SIGBUS signal. As a
>>>>>>>>> result, these processes continues to access the faulty page, causing
>>>>>>>>> repeated entries into the SEA exception handler. At this time, it lead to
>>>>>>>>> an SEA error interrupt storm.
>>>>>
>>>>> In such case, the user process which accessing the poisoned page will be killed
>>>>> by memory_fauilre?
>>>>>
>>>>> // memory_failure():
>>>>>
>>>>> if (TestSetPageHWPoison(p)) {
>>>>> res = -EHWPOISON;
>>>>> if (flags & MF_ACTION_REQUIRED)
>>>>> res = kill_accessing_process(current, pfn, flags);
>>>>> if (flags & MF_COUNT_INCREASED)
>>>>> put_page(p);
>>>>> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
>>>>> goto unlock_mutex;
>>>>> }
>>>>>
>>>>> I think this problem has already been fixed by commit 2e6053fea379 ("mm/memory-failure:
>>>>> fix infinite UCE for VM_PFNMAP pfn").
>>>>>
>>>>> The root cause is that walk_page_range() skips VM_PFNMAP vmas by default when
>>>>> no .test_walk callback is set, so kill_accessing_process() returns 0 for a
>>>>> devmem-style mapping (remap_pfn_range, VM_PFNMAP), making the caller believe
>>>>> the UCE was handled properly while the process was never actually killed.
>>>>>
>>>>> Did you try the lastest kernel version?
>>>>>
>>>>
>>>> I retested this issue on the kernel v7.0.0-rc4 with the following debug patch and was still able to reproduce it.
>>>>
>>>>
>>>> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
>>>> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>>>>
>>>> /* This error has been reported before, don't process it again. */
>>>> - if (ghes_estatus_cached(estatus))
>>>> + if (ghes_estatus_cached(estatus)) {
>>>> + pr_info("This error has been reported before, don't process it again.\n");
>>>> goto no_work;
>>>> + }
>>>>
>>>> the test log Only some debug logs are retained here.
>>>>
>>>> [2026/3/24 14:51:58.199] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
>>>> [2026/3/24 14:51:58.369] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
>>>> [2026/3/24 14:51:58.458] [ 130.558038][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>> [2026/3/24 14:51:58.459] [ 130.572517][ C40] {1}[Hardware Error]: event severity: recoverable
>>>> [2026/3/24 14:51:58.459] [ 130.578861][ C40] {1}[Hardware Error]: Error 0, type: recoverable
>>>> [2026/3/24 14:51:58.459] [ 130.585203][ C40] {1}[Hardware Error]: section_type: ARM processor error
>>>> [2026/3/24 14:51:58.459] [ 130.592238][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
>>>> [2026/3/24 14:51:58.459] [ 130.598492][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>>>> [2026/3/24 14:51:58.459] [ 130.607871][ C40] {1}[Hardware Error]: error affinity level: 0
>>>> [2026/3/24 14:51:58.459] [ 130.614038][ C40] {1}[Hardware Error]: running state: 0x1
>>>> [2026/3/24 14:51:58.459] [ 130.619770][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
>>>> [2026/3/24 14:51:58.459] [ 130.627673][ C40] {1}[Hardware Error]: Error info structure 0:
>>>> [2026/3/24 14:51:58.459] [ 130.633839][ C40] {1}[Hardware Error]: num errors: 1
>>>> [2026/3/24 14:51:58.459] [ 130.639137][ C40] {1}[Hardware Error]: error_type: 0, cache error
>>>> [2026/3/24 14:51:58.459] [ 130.645652][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
>>>> [2026/3/24 14:51:58.459] [ 130.652514][ C40] {1}[Hardware Error]: cache level: 1
>>>> [2026/3/24 14:51:58.551] [ 130.658073][ C40] {1}[Hardware Error]: the error has not been corrected
>>>> [2026/3/24 14:51:58.551] [ 130.665194][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
>>>> [2026/3/24 14:51:58.551] [ 130.673097][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>> [2026/3/24 14:51:58.551] [ 130.680744][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:51:58.551] [ 130.690471][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:51:58.552] [ 130.700198][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:51:58.552] [ 130.710083][ T9767] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
>>>> [2026/3/24 14:51:58.638] [ 130.790952][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:51:58.903] [ 131.046994][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:51:58.991] [ 131.132360][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:51:59.969] [ 132.071431][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:00.860] [ 133.010255][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:01.927] [ 134.034746][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:02.906] [ 135.058973][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:03.971] [ 136.083213][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:04.860] [ 137.021956][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:06.018] [ 138.131460][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:06.905] [ 139.070280][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:07.886] [ 140.009147][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:08.596] [ 140.777368][ C40] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>> [2026/3/24 14:52:08.683] [ 140.791921][ C40] {2}[Hardware Error]: event severity: recoverable
>>>> [2026/3/24 14:52:08.683] [ 140.798263][ C40] {2}[Hardware Error]: Error 0, type: recoverable
>>>> [2026/3/24 14:52:08.683] [ 140.804606][ C40] {2}[Hardware Error]: section_type: ARM processor error
>>>> [2026/3/24 14:52:08.683] [ 140.811641][ C40] {2}[Hardware Error]: MIDR: 0x0000000000000000
>>>> [2026/3/24 14:52:08.684] [ 140.817895][ C40] {2}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>>>> [2026/3/24 14:52:08.684] [ 140.827274][ C40] {2}[Hardware Error]: error affinity level: 0
>>>> [2026/3/24 14:52:08.684] [ 140.833440][ C40] {2}[Hardware Error]: running state: 0x1
>>>> [2026/3/24 14:52:08.684] [ 140.839173][ C40] {2}[Hardware Error]: Power State Coordination Interface state: 0
>>>> [2026/3/24 14:52:08.684] [ 140.847076][ C40] {2}[Hardware Error]: Error info structure 0:
>>>> [2026/3/24 14:52:08.684] [ 140.853241][ C40] {2}[Hardware Error]: num errors: 1
>>>> [2026/3/24 14:52:08.684] [ 140.858540][ C40] {2}[Hardware Error]: error_type: 0, cache error
>>>> [2026/3/24 14:52:08.684] [ 140.865055][ C40] {2}[Hardware Error]: error_info: 0x0000000020400014
>>>> [2026/3/24 14:52:08.684] [ 140.871917][ C40] {2}[Hardware Error]: cache level: 1
>>>> [2026/3/24 14:52:08.684] [ 140.877475][ C40] {2}[Hardware Error]: the error has not been corrected
>>>> [2026/3/24 14:52:08.764] [ 140.884596][ C40] {2}[Hardware Error]: physical fault address: 0x0000001351811800
>>>> [2026/3/24 14:52:08.764] [ 140.892499][ C40] {2}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>> [2026/3/24 14:52:08.766] [ 140.900145][ C40] {2}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:52:08.767] [ 140.909872][ C40] {2}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:52:08.767] [ 140.919598][ C40] {2}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:52:08.768] [ 140.929346][ T9767] Memory failure: 0x1351811: already hardware poisoned
>>>> [2026/3/24 14:52:08.768] [ 140.936072][ T9767] Memory failure: 0x1351811: Sending SIGBUS to busybox:9767 due to hardware memory corruption
>>>
>>> Did you cut off some logs here?
>>
>> I just removed some duplicate debug logs: "This error has already been...", these were added by myself.
Hi, Shuai
Compared to the original commit message and the logs reproducing this issue
on kernel v7.0.0-rc4, perhaps you are asking whether the current log is missing
information such as 'NOTICE: SEA Handle'?
These miss logs are from the firmware. To reduce serial output, the firmware has
hidden these debug prints. However, using my own custom debug logs, I can
still see that the kernel's do_sea() process is continuously running during the
10-second cache timeout. Although only one debug log is retained per second.
This confirms that the issue is still present on the latest kernel v7.0.0-rc4.
>>> The error log also indicates that the SIGBUS is delivered as expected.
>>
>> An SError occurs at kernel time 130.558038. Then, after 10 seconds, the kernel
>> can re-enter the SEA processing flow and send the SIGBUS signal to the process.
>> This 10-second delay corresponds to the cache timeout threshold of the
>> ghes_estatus_cached() feature.
>> Therefore, the purpose of this patch is to send the SIGBUS signal to the process
>> immediately, rather than waiting for the timeout to expire.
>
> Hi, hejun,
>
> Sorry, but I am still not convinced by the log you provided.
>
> As I understand your commit message, there are two different cases being discussed:
>
> Case 1: memory error interrupt first, then SEA
>
> When hardware memory corruption occurs, a memory error interrupt is
> triggered first. If the kernel later accesses the corrupted data, it may
> then enter the SEA handler. In this case, the faulty page would already
> have been marked poisoned by the memory error interrupt path, and the SEA
> handling path would eventually send SIGBUS to the task accessing that page.
>
> Case 2: SEA first, then memory error interrupt
>
> Your commit message describes this as the problematic scenario:
>
> A user process directly accesses hardware-corrupted memory through a
> PFNMAP-style mapping such as devmem. The page may still be in the free
> buddy state when SEA is handled first. In that case, memory_failure()
> poisons the page during SEA handling, but the process is not killed
> immediately. Since the task continues accessing the same corrupted
> location, it keeps re-entering the SEA handler, leading to an SEA storm.
> Later, the memory error interrupt path also cannot kill the task, so the
> system remains stuck in this repeated SEA loop.
Yes.
>
> My concern is that your recent explanation and log seem to demonstrate
> something different from what the commit message claims to fix.
>
> From the log, what I can see is:
>
> the first SEA occurs,
> the page is marked poisoned as a free buddy page,
> repeated SEAs are suppressed by ghes_estatus_cached(),
> after the cache timeout expires, the SEA path runs again,
> then memory_failure() reports "already hardware poisoned" and SIGBUS is
> sent to the busybox devmem process.
> This seems to show a delayed SIGBUS delivery caused by the GHES cache
> timeout, rather than clearly demonstrating the SEA storm problem described
> in the commit message.
>
> So I think there is still a mismatch here:
>
> If the patch is intended to fix the SEA storm described in case 2,
> then I would expect evidence that the storm still exists on the latest
> kernel and that this patch is what actually breaks that loop.
> If instead the patch is intended to avoid the 10-second delay before
> SIGBUS delivery, then that should be stated explicitly, because that is
> a different problem statement from what the current commit message says.
> Also, regarding the devmem/PFNMAP case: I previously pointed to commit
> 2e6053fea379 ("mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn"),
> which was meant to address the failure to kill tasks accessing poisoned
> VM_PFNMAP mappings.
>
This patch was already merged prior to kernel v7.0.0-rc4, therefore, it cannot fix this issue.
I reverted the patch on kernel v7.0.0-rc4 to reproduce the issue.
The debug logs show that the message 'This error has already been...' persists
for more than 10 seconds, and the printing cannot be stopped. so it fixes other issue.
> So my main question is:
>
> Does the SEA storm issue still exist on the latest kernel version, or is
> the remaining issue only that SIGBUS is delayed by the GHES estatus cache
> timeout?
We should not treat them separately.
In case 2, First SEA can only poisons the page, and then re-enter the SEA processing flow.
Due to the reporting throttle of the ghes_estatus_cached(), SEA cannot timely invoke
memory_failure() to kill the task, the task will continues accessing the same corrupted
location, then re-enter the SEA processing flow loop, so causing the SEA storm...
Perhaps I never clearly explained why the SEA storm occurred.
Best regards,
Junhao.
>
> I think the answer to that question is important before deciding whether
> this patch is correct, and before finalizing the commit message.
>
> Thanks,
> Shuai
>
> .
>
^ permalink raw reply
* Re: [PATCH V2 4/5] dt-bindings: dma: xlnx,axi-dma: Add "xlnx,include-stscntrl-strm" property
From: Rob Herring (Arm) @ 2026-03-26 13:22 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Radhey Shyam Pandey, Michal Simek, Frank Li, devicetree, git,
Conor Dooley, Vinod Koul, Tomi Valkeinen, Suraj Gupta,
Abin Joseph, Thomas Gessler, Folker Schwesinger, linux-kernel,
Krzysztof Kozlowski, linux-arm-kernel, dmaengine, Kees Cook
In-Reply-To: <20260313062533.421249-5-srinivas.neeli@amd.com>
On Fri, 13 Mar 2026 11:55:32 +0530, Srinivas Neeli wrote:
> Add an optional boolean DT property "xlnx,include-stscntrl-strm" to
> indicate that the AXI DMA IP is configured with the AXI4-Stream status
> and control interface. This enables the use of APP fields in DMA
> descriptors for metadata reporting.
>
> This property is distinct from "xlnx,axistream-connected" and serves a
> different purpose:
>
> - "xlnx,include-stscntrl-strm": Indicates whether APP fields are present
> in DMA descriptors. When enabled, the driver can access status/control
> metadata through these descriptor fields.
>
> - "xlnx,axistream-connected": Indicates whether a streaming IP (client)
> is connected to the DMA IP.
>
> These two configurations are independent of each other. For example, in
> TSN (Time-Sensitive Networking) designs, a streaming client may be
> connected to the DMA IP, but the status/control stream interface is not
> enabled. In such cases, "xlnx,axistream-connected" would be present while
> "xlnx,include-stscntrl-strm" would be absent.
>
> Adding this property allows the driver to correctly determine descriptor
> layout and access APP fields only when the hardware supports them.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> .../devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Jie Zhan @ 2026-03-26 13:14 UTC (permalink / raw)
To: cw00.choi, myungjoo.ham, kyungmin.park, tianyaxiong
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <20260326123428.800407-1-zhanjie9@hisilicon.com>
On 3/26/2026 8:34 PM, Jie Zhan wrote:
> When compiled as a kernel module, the governor module can be dynamically
> inserted or removed. 'devfreq->governor' would become NULL if the governor
> module is removed when it's in use, and NULL pointer dereference would be
> triggered. A similar issue was also reported in [1].
>
> To address this issue:
>
> Patch 1-5 rework mutex, factor out a common governor setting function, and
> clean up some unreachable code.
>
> Patch 6-8 prevent a governor module in use from being removed (except for
> force unload) by getting/putting a refcount of the governor's module when
> switching governors.
>
> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
> when a governor module in use is force unloaded.
>
> Note that this series is based on [1] or devfreq-next, otherwise code
sorry, based on [2] or devfreq-next
> would conflict.
>
> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-03-26 13:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <177453048347.439230.1647215482099213609.b4-ty@linaro.org>
On 3/26/26 14:08, Neil Armstrong wrote:
> Hi,
>
> On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
>> This patch series depends on Jian's SCMI clock patches yet to merge
>> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>>
>> This series adds device tree support for the MMC, SD card and SDIO
>> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>>
>> The first patches add the necessary building blocks in the T7 SoC
>> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
>> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
>> strings are introduced with fallbacks to existing drivers, avoiding
>> the need for new driver code.
>>
>> [...]
>
> Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
>
> [1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
> https://git.kernel.org/amlogic/c/fb69fa2cabc68da247bcc0bc99a14dc857b16842
> [4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
> https://git.kernel.org/amlogic/c/b1e49f6c1ac15b2c947bdb1d22a82b823de22d27
> [6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
> https://git.kernel.org/amlogic/c/60eff75ac67bbf5445bdbd2842b0109ac591441c
I'll pick patch 3,5,7 & 9 once patches 1 & 2 from [1] are merged.
[1] https://lore.kernel.org/all/20260326092645.1053261-1-jian.hu@amlogic.com/
Thanks,
Neil
>
> These changes has been applied on the intermediate git tree [1].
>
> The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
> for inclusion in their intermediate git branches in order to be sent to Linus during
> the next merge window, or sooner if it's a set of fixes.
>
> In the cases of fixes, those will be merged in the current release candidate
> kernel and as soon they appear on the Linux master branch they will be
> backported to the previous Stable and Long-Stable kernels [2].
>
> The intermediate git branches are merged daily in the linux-next tree [3],
> people are encouraged testing these pre-release kernels and report issues on the
> relevant mailing-lists.
>
> If problems are discovered on those changes, please submit a signed-off-by revert
> patch followed by a corrective changeset.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
^ permalink raw reply
* Re: [PATCH] clocksource/drivers/timer-mediatek: initialize GPT6 as system counter
From: Akari Tsuyukusa @ 2026-03-26 13:08 UTC (permalink / raw)
To: rva333
Cc: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260326-archtimer-v1-1-5328574e5935@protonmail.com>
On Thu, Mar 26, 2026 at 10:00 AM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
> On certain MediaTek SoCs like mt6572 (likely before the CPUXGPT was
> introduced), the generic arch timer is fed by the GPT6. Some bootloaders
> don't initialize it properly, leading to dead arch timer.
>
> Fix this by configuring GPT6 when the MediaTek timer is probed. This
> makes arch timer work properly and removes IPI overhead from MediaTek
> timer broadcast when arch timer is used.
>
> If the timer was configured by the bootloader, this change is no-op.
>
> Tested-by: Akari Tsuyukusa <akkun11.open@gmail.com> # MT6589
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> drivers/clocksource/timer-mediatek.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> index 7bcb4a3f26fb..7de34cace572 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -22,6 +22,8 @@
>
> #define TIMER_SYNC_TICKS (3)
>
> +#define TIMER_SYSCNT (6)
> +
> /* gpt */
> #define GPT_IRQ_EN_REG 0x00
> #define GPT_IRQ_ENABLE(val) BIT((val) - 1)
> @@ -335,6 +337,9 @@ static int __init mtk_gpt_init(struct device_node *node)
>
> mtk_gpt_enable_irq(&to, TIMER_CLK_EVT);
>
> + /* Configure GPT6 to feed arch timer */
> + mtk_gpt_setup(&to, TIMER_SYSCNT, GPT_CTRL_OP_FREERUN);
> +
> return 0;
> }
> TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
>
> ---
Although it has already been written,
I tested this patch on MT6589 (Lenovo YOGA Tablet 10 Wi-Fi),
and I have confirmed that MediaTek's timer and Arm Generic Timer are
working properly as before the patch was applied.
Therefore,
Tested-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Best regards,
Akari Tsuyukusa
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-03-26 13:08 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
https://git.kernel.org/amlogic/c/fb69fa2cabc68da247bcc0bc99a14dc857b16842
[4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
https://git.kernel.org/amlogic/c/b1e49f6c1ac15b2c947bdb1d22a82b823de22d27
[6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
https://git.kernel.org/amlogic/c/60eff75ac67bbf5445bdbd2842b0109ac591441c
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ 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