* [PATCH net-next 04/10] net: airoha: Rely on net_device pointer in ETS callbacks
From: Lorenzo Bianconi @ 2026-03-29 13:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260329-airoha-eth-multi-serdes-v1-0-00f52dc360ca@kernel.org>
Remove airoha_gdm_port dependency in ETS tc callback signatures and rely
on net_device pointer instead. Please note this patch does not introduce
any logical change and it is a preliminary patch in order to support
multiple net_devices connected to the same GDM3 or GDM4 port via an
external hw multiplexer.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index e8d4fdbc990195e4b0121ae591066e4fc11ab647..cefe251234989f05c7a2b36161eb63ba861d8b34 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2122,10 +2122,11 @@ airoha_ethtool_get_rmon_stats(struct net_device *dev,
} while (u64_stats_fetch_retry(&port->stats.syncp, start));
}
-static int airoha_qdma_set_chan_tx_sched(struct airoha_gdm_port *port,
+static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
int channel, enum tx_sched_mode mode,
const u16 *weights, u8 n_weights)
{
+ struct airoha_gdm_port *port = netdev_priv(netdev);
int i;
for (i = 0; i < AIROHA_NUM_TX_RING; i++)
@@ -2157,17 +2158,15 @@ static int airoha_qdma_set_chan_tx_sched(struct airoha_gdm_port *port,
return 0;
}
-static int airoha_qdma_set_tx_prio_sched(struct airoha_gdm_port *port,
- int channel)
+static int airoha_qdma_set_tx_prio_sched(struct net_device *dev, int channel)
{
static const u16 w[AIROHA_NUM_QOS_QUEUES] = {};
- return airoha_qdma_set_chan_tx_sched(port, channel, TC_SCH_SP, w,
+ return airoha_qdma_set_chan_tx_sched(dev, channel, TC_SCH_SP, w,
ARRAY_SIZE(w));
}
-static int airoha_qdma_set_tx_ets_sched(struct airoha_gdm_port *port,
- int channel,
+static int airoha_qdma_set_tx_ets_sched(struct net_device *dev, int channel,
struct tc_ets_qopt_offload *opt)
{
struct tc_ets_qopt_offload_replace_params *p = &opt->replace_params;
@@ -2208,14 +2207,15 @@ static int airoha_qdma_set_tx_ets_sched(struct airoha_gdm_port *port,
else if (nstrict < AIROHA_NUM_QOS_QUEUES - 1)
mode = nstrict + 1;
- return airoha_qdma_set_chan_tx_sched(port, channel, mode, w,
+ return airoha_qdma_set_chan_tx_sched(dev, channel, mode, w,
ARRAY_SIZE(w));
}
-static int airoha_qdma_get_tx_ets_stats(struct airoha_gdm_port *port,
- int channel,
+static int airoha_qdma_get_tx_ets_stats(struct net_device *netdev, int channel,
struct tc_ets_qopt_offload *opt)
{
+ struct airoha_gdm_port *port = netdev_priv(netdev);
+
u64 cpu_tx_packets = airoha_qdma_rr(port->qdma,
REG_CNTR_VAL(channel << 1));
u64 fwd_tx_packets = airoha_qdma_rr(port->qdma,
@@ -2230,7 +2230,7 @@ static int airoha_qdma_get_tx_ets_stats(struct airoha_gdm_port *port,
return 0;
}
-static int airoha_tc_setup_qdisc_ets(struct airoha_gdm_port *port,
+static int airoha_tc_setup_qdisc_ets(struct net_device *dev,
struct tc_ets_qopt_offload *opt)
{
int channel;
@@ -2243,12 +2243,12 @@ static int airoha_tc_setup_qdisc_ets(struct airoha_gdm_port *port,
switch (opt->command) {
case TC_ETS_REPLACE:
- return airoha_qdma_set_tx_ets_sched(port, channel, opt);
+ return airoha_qdma_set_tx_ets_sched(dev, channel, opt);
case TC_ETS_DESTROY:
/* PRIO is default qdisc scheduler */
- return airoha_qdma_set_tx_prio_sched(port, channel);
+ return airoha_qdma_set_tx_prio_sched(dev, channel);
case TC_ETS_STATS:
- return airoha_qdma_get_tx_ets_stats(port, channel, opt);
+ return airoha_qdma_get_tx_ets_stats(dev, channel, opt);
default:
return -EOPNOTSUPP;
}
@@ -2793,11 +2793,9 @@ static int airoha_tc_setup_qdisc_htb(struct net_device *dev,
static int airoha_dev_tc_setup(struct net_device *dev, enum tc_setup_type type,
void *type_data)
{
- struct airoha_gdm_port *port = netdev_priv(dev);
-
switch (type) {
case TC_SETUP_QDISC_ETS:
- return airoha_tc_setup_qdisc_ets(port, type_data);
+ return airoha_tc_setup_qdisc_ets(dev, type_data);
case TC_SETUP_QDISC_HTB:
return airoha_tc_setup_qdisc_htb(dev, type_data);
case TC_SETUP_BLOCK:
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 02/10] net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
From: Lorenzo Bianconi @ 2026-03-29 13:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260329-airoha-eth-multi-serdes-v1-0-00f52dc360ca@kernel.org>
Remove airoha_gdm_port dependency in airoha_dev_setup_tc_block routine
signature and rely on net_device pointer instead. Please note this patch
does not introduce any logical change and it is a preliminary patch to
support multiple net_devices connected to the GDM3 or GDM4 ports via an
external hw multiplexer.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 743ef0db30980ce74059dfb63553030ef3bf735f..421a154ee7189eb7919382b6cd893ae5d4e03766 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2671,7 +2671,7 @@ static int airoha_dev_setup_tc_block_cb(enum tc_setup_type type,
}
}
-static int airoha_dev_setup_tc_block(struct airoha_gdm_port *port,
+static int airoha_dev_setup_tc_block(struct net_device *dev,
struct flow_block_offload *f)
{
flow_setup_cb_t *cb = airoha_dev_setup_tc_block_cb;
@@ -2684,12 +2684,12 @@ static int airoha_dev_setup_tc_block(struct airoha_gdm_port *port,
f->driver_block_list = &block_cb_list;
switch (f->command) {
case FLOW_BLOCK_BIND:
- block_cb = flow_block_cb_lookup(f->block, cb, port->dev);
+ block_cb = flow_block_cb_lookup(f->block, cb, dev);
if (block_cb) {
flow_block_cb_incref(block_cb);
return 0;
}
- block_cb = flow_block_cb_alloc(cb, port->dev, port->dev, NULL);
+ block_cb = flow_block_cb_alloc(cb, dev, dev, NULL);
if (IS_ERR(block_cb))
return PTR_ERR(block_cb);
@@ -2698,7 +2698,7 @@ static int airoha_dev_setup_tc_block(struct airoha_gdm_port *port,
list_add_tail(&block_cb->driver_list, &block_cb_list);
return 0;
case FLOW_BLOCK_UNBIND:
- block_cb = flow_block_cb_lookup(f->block, cb, port->dev);
+ block_cb = flow_block_cb_lookup(f->block, cb, dev);
if (!block_cb)
return -ENOENT;
@@ -2797,7 +2797,7 @@ static int airoha_dev_tc_setup(struct net_device *dev, enum tc_setup_type type,
return airoha_tc_setup_qdisc_htb(port, type_data);
case TC_SETUP_BLOCK:
case TC_SETUP_FT:
- return airoha_dev_setup_tc_block(port, type_data);
+ return airoha_dev_setup_tc_block(dev, type_data);
default:
return -EOPNOTSUPP;
}
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 01/10] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Lorenzo Bianconi @ 2026-03-29 13:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree
In-Reply-To: <20260329-airoha-eth-multi-serdes-v1-0-00f52dc360ca@kernel.org>
EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
or GDM4 ports via a hw multiplexer that manages the traffic in a TDM
manner. As a result multiple net_devices can connect to the same GDM{3,4}
port and there is a theoretical "1:n" relation between GDM ports and
net_devices.
Introduce the ethernet-port property in order to model a given net_device
that is connected via the external multiplexer to the GDM{3,4} port (that
is represented by the ethernet property. Please note GDM1 or GDM2 does not
support the connection with the external multiplexer and are represented
by ethernet property.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../devicetree/bindings/net/airoha,en7581-eth.yaml | 44 +++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
index fbe2ddcdd909cb3d853a4ab9e9fec4af1d096c52..ebbd433e9c9fbfaefd8d07c3678cabc91574d125 100644
--- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
+++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
@@ -130,6 +130,30 @@ patternProperties:
maximum: 4
description: GMAC port identifier
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^ethernet-port@[0-5]$":
+ type: object
+ unevaluatedProperties: false
+ $ref: ethernet-controller.yaml#
+ description: External ethernet port ID available on the GDM port
+
+ properties:
+ compatible:
+ const: airoha,eth-port
+
+ reg:
+ maxItems: 1
+ description: External ethernet port identifier
+
+ required:
+ - compatible
+ - reg
+
required:
- reg
- compatible
@@ -191,9 +215,27 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- mac: ethernet@1 {
+ mac1: ethernet@1 {
compatible = "airoha,eth-mac";
reg = <1>;
};
+
+ mac4: ethernet@4 {
+ compatible = "airoha,eth-mac";
+ reg = <4>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ compatible = "airoha,eth-port";
+ reg = <0>;
+ };
+
+ ethernet-port@1 {
+ compatible = "airoha,eth-port";
+ reg = <1>;
+ };
+ };
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 00/10] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-03-29 13:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw multiplexer that
manages the traffic in a TDM manner. As a result multiple net_devices can
connect to the same GDM{3,4} port and there is a theoretical "1:n"
relation between GDM ports and net_devices.
┌─────────────────────────────────┐
│ │ ┌──────┐
│ P1 GDM1 ├────►MT7530│
│ │ └──────┘
│ │ ETH0 (DSA conduit)
│ │
│ PSE/FE │
│ │
│ │
│ │ ┌─────┐
│ P0 CDM1 ├────►QDMA0│
│ P4 P9 GDM4 │ └─────┘
└──┬─────────────────────────┬────┘
│ │
┌──▼──┐ ┌────▼────┐
│ PPE │ │ MUX │
└─────┘ └─┬─────┬─┘
│ │
┌──▼──┐┌─▼───┐
│ ETH ││ USB │
└─────┘└─────┘
ETH1 ETH2
This series introduces support for multiple net_devices connected to the
same Frame Engine (FE) GDM port (GDM3 or GDM4) via an external hw
multiplexer. Please note GDM1 or GDM2 does not support the connection with
the external multiplexer.
---
Lorenzo Bianconi (10):
dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
net: airoha: Rely on net_device pointer in HTB callbacks
net: airoha: Rely on net_device pointer in ETS callbacks
net: airoha: Introduce airoha_gdm_dev struct
net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
net: airoha: Rely on airoha_gdm_dev pointer in airhoa_is_lan_gdm_port()
net: airoha: Support multiple net_devices for a single FE GDM port
net: airoha: Do not stop GDM port if it is shared
net: airoha: Rename get_src_port_id callback in get_sport
.../devicetree/bindings/net/airoha,en7581-eth.yaml | 44 +-
drivers/net/ethernet/airoha/airoha_eth.c | 626 +++++++++++++--------
drivers/net/ethernet/airoha/airoha_eth.h | 30 +-
drivers/net/ethernet/airoha/airoha_ppe.c | 42 +-
4 files changed, 497 insertions(+), 245 deletions(-)
---
base-commit: 68bb4adb58e114336826e2ecc15ecf62e2890d3e
change-id: 20260324-airoha-eth-multi-serdes-fb4b556ee756
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Jernej Škrabec @ 2026-03-29 13:03 UTC (permalink / raw)
To: Michal Piekos
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <n2bupd37br2mp7ls6c5z5ueoancr53tn4mywg2vvrlpyhmkex4@lxe6tfdhwz5e>
Dne nedelja, 29. marec 2026 ob 14:07:19 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> On Sun, Mar 29, 2026 at 01:53:45PM +0200, Jernej Škrabec wrote:
> > Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> > > Add support for timer by reusing existing sun4i timer driver.
> > >
> > > H616 timer is compatible with earlier sunxi timer variants and provides
> > > both clocksource and clockevent functionality. It runs from 24 MHz
> > > oscillator. It can serve as broadcast clockevent for wake up from idle
> > > states.
> > >
> > > Tested on Orange Pi Zero 3:
> > > - timer is registered as clocksource:
> > > - switching clocksource at runtime works
> > > - timer operates as a broadcast clockevent device
> > > - no regression observed compared to arch_sys_counter
> > >
> > > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > > ---
> > > Test results:
> > >
> > > Clocksource switching:
> > > cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> > > arch_sys_counter timer
> > > echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > > [ 5031.105997] clocksource: Switched to clocksource timer
> > >
> > > Clockevent configuration:
> > > cat /proc/timer_list
> > > ...
> > > Tick Device: mode: 1
> > > Broadcast device
> > > Clock Event Device: sun4i_tick
> > > max_delta_ns: 178956969070
> > > min_delta_ns: 1000
> > > mult: 51539608
> > > shift: 31
> > > mode: 1
> > > next_event: 9223372036854775807 nsecs
> > > set_next_event: sun4i_clkevt_next_event
> > > shutdown: sun4i_clkevt_shutdown
> > > periodic: sun4i_clkevt_set_periodic
> > > oneshot: sun4i_clkevt_set_oneshot
> > > resume: sun4i_clkevt_shutdown
> > > event_handler: tick_handle_oneshot_broadcast
> > > ...
> > >
> > > Cyclictest measurements:
> > > Dominated by system scheduler latency and do not reflect clocksource
> > > precision.
> > > ---
> > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > index 8d1110c14bad..bf054869e78b 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> > > };
> > > };
> > >
> > > + timer0: timer@3009000 {
> > > + compatible = "allwinner,sun50i-h616-timer",
> > > + "allwinner,sun8i-a23-timer";
> >
> > You have to add above combo to DT bindings.
> >
> > Best regards,
> > Jernej
>
> Not sure I understand your comment correctly but binding for h616 is already
> there:
>
> Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml:21-27
> - items:
> - enum:
> - allwinner,sun20i-d1-timer
> - allwinner,sun50i-a64-timer
> - allwinner,sun50i-h6-timer
> - allwinner,sun50i-h616-timer
> - const: allwinner,sun8i-a23-timer
>
> BR
> Michal
Sorry, sometimes tooling fails me. All good.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
>
> >
> > > + reg = <0x03009000 0xa0>;
> > > + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&osc24M>;
> > > + };
> > > +
> > > watchdog: watchdog@30090a0 {
> > > compatible = "allwinner,sun50i-h616-wdt",
> > > "allwinner,sun6i-a31-wdt";
> > >
> > > ---
> > > base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> > > change-id: 20260328-h616-timer-046e6ac3549e
> > >
> > > Best regards,
> > >
> >
> >
> >
> >
>
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Demian Shulhan @ 2026-03-29 13:01 UTC (permalink / raw)
To: Mark Rutland
Cc: Ard Biesheuvel, Christoph Hellwig, Song Liu, Yu Kuai, Will Deacon,
Catalin Marinas, broonie, linux-arm-kernel, robin.murphy, Li Nan,
linux-raid, linux-kernel
In-Reply-To: <acJhCCPfVxjFUZ5R@J2N7QTR9R3>
Hi all,
Thanks for the feedback and for clarifying the current limitations of
the kernel-mode SIMD API regarding SVE context preservation. I
completely understand why this patch cannot be merged in its current
state until the fundamental SVE infrastructure is in place.However, I
want to address the comment about the marginal 0.3% speedup on the
8-disk benchmark. While the pure memory bandwidth on a small array is
indeed bottlenecked, it doesn't reveal the whole picture. I extracted
the SVE and NEON implementations into a user-space benchmark to
measure the actual hardware efficiency using perf stat, running on the
same AWS Graviton3 (Neoverse-V1) instance.The results show a massive
difference in CPU efficiency. For the same 8-disk workload, the svex4
implementation requires about 35% fewer instructions and 46% fewer CPU
cycles compared to neonx4 (7.58 billion instructions vs 11.62
billion). This translates directly into significant energy savings and
reduced pressure on the CPU frontend, which would leave more compute
resources available for network and NVMe queues during an array
rebuild.
Furthermore, as Christoph suggested, I tested scalability on wider
arrays since the default kernel benchmark is hardcoded to 8 disks,
which doesn't give the unrolled SVE loop enough data to shine. On a
16-disk array, svex4 hits 15.1 GB/s compared to 8.0 GB/s for neonx4.
On a 24-disk array, while neonx4 chokes and drops to 7.8 GB/s, svex4
maintains a stable 15.0 GB/s — effectively doubling the throughput.I
agree this patch should be put on hold for now. My intention is to
leave these numbers here as evidence that implementing SVE context
preservation in the kernel (the "good use case") is highly justifiable
from both a power-efficiency and a wide-array throughput perspective
for modern ARM64 hardware.
Thanks again for your time and time and review!
---------------------------------------------------
User space test results:
==================================================
RAID6 SVE Benchmark Results (AWS Graviton3)
==================================================
Instance Details:
Linux ip-172-31-87-234 6.8.0-1047-aws #50~22.04.1-Ubuntu SMP Thu Feb
19 20:49:25 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux
--------------------------------------------------
[Test 1: Energy Efficiency / Instruction Count (8 disks)]
Running baseline (neonx4)...
algo=neonx4 ndisks=8 iterations=1000000 time=2.681s MB/s=8741.36
Running SVE (svex1)...
Performance counter stats for './raid6_bench neonx4 8 1000000':
11626717224 instructions # 1.67
insn per cycle
6946699489 cycles
257013219 L1-dcache-load-misses
2.681213149 seconds time elapsed
2.676771000 seconds user
0.002000000 seconds sys
algo=svex1 ndisks=8 iterations=1000000 time=1.688s MB/s=13885.23
Performance counter stats for './raid6_bench svex1 8 1000000':
10527277490
Running SVE unrolled x4 (svex4)...
instructions # 2.40 insn per cycle
4379539835 cycles
175695656 L1-dcache-load-misses
1.688852006 seconds time elapsed
1.687298000 seconds user
0.000999000 seconds sys
algo=svex4 ndisks=8 iterations=1000000 time=1.445s MB/s=16215.04
Performance counter stats for './raid6_bench svex4 8 1000000':
7587813392 instructions
==================================================
[Test 2: Scalability on Wide RAID Arrays (MB/s)]
--- 16 Disks ---
# 2.02 insn per cycle
3748486131 cycles
213816184 L1-dcache-load-misses
1.446032415 seconds time elapsed
1.442412000 seconds user
0.002996000 seconds sys
algo=neonx4 ndisks=16 iterations=1000000 time=6.783s MB/s=8062.33
algo=svex1 ndisks=16 iterations=1000000 time=4.912s MB/s=11132.90
algo=svex4 ndisks=16 iterations=1000000 time=3.601s MB/s=15188.85
--- 24 Disks ---
algo=neonx4 ndisks=24 iterations=1000000 time=11.011s MB/s=7805.02
algo=svex1 ndisks=24 iterations=1000000 time=8.843s MB/s=9718.26
algo=svex4 ndisks=24 iterations=1000000 time=5.719s MB/s=15026.92
Extra tests:
--- 48 Disks ---
algo=neonx4 ndisks=48 iterations=500000 time=11.826s MB/s=7597.25
algo=svex4 ndisks=48 iterations=500000 time=5.808s MB/s=15468.10
--- 96 Disks ---
algo=neonx4 ndisks=96 iterations=200000 time=9.783s MB/s=7507.01
algo=svex4 ndisks=96 iterations=200000 time=4.701s MB/s=15621.17
==================================================
вт, 24 бер. 2026 р. о 12:05 Mark Rutland <mark.rutland@arm.com> пише:
>
> On Tue, Mar 24, 2026 at 09:00:16AM +0100, Ard Biesheuvel wrote:
> > On Wed, 18 Mar 2026, at 16:02, Demian Shulhan wrote:
> > > Implement Scalable Vector Extension (SVE) optimized routines for RAID6
> > > syndrome generation and recovery on ARM64.
> > >
> > > The SVE instruction set allows for variable vector lengths (from 128 to
> > > 2048 bits), scaling automatically with the hardware capabilities. This
> > > implementation handles arbitrary SVE vector lengths using the `cntb`
> > > instruction to determine the runtime vector length.
> > >
> > > The implementation introduces `svex1`, `svex2`, and `svex4` algorithms.
> > > The `svex4` algorithm utilizes loop unrolling by 4 blocks per iteration
> > > and manual software pipelining (interleaving memory loads with XORs)
> > > to minimize instruction dependency stalls and maximize CPU pipeline
> > > utilization and memory bandwidth.
> > >
> > > Performance was tested on an AWS Graviton3 (Neoverse-V1) instance which
> > > features 256-bit SVE vector length. The `svex4` implementation outperforms
> > > the existing 128-bit `neonx4` baseline for syndrome generation:
> > >
> > > raid6: svex4 gen() 19688 MB/s
> > ...
> > > raid6: neonx4 gen() 19612 MB/s
> >
> > You're being very generous characterising a 0.3% speedup as 'outperforms'
> >
> > But the real problem here is that the kernel-mode SIMD API only
> > supports NEON and not SVE, and preserves/restores only the 128-bit
> > view on the NEON/SVE register file. So any context switch or softirq
> > that uses kernel-mode SIMD too, and your SVE register values will get
> > truncated.
>
> Just to be a bit more explicit, since only the NEON register file is
> saved:
>
> * The vector registers will be truncated to 128-bit across
> preemption or softirq.
>
> * The predicates won't be saved/restored and will change arbitrarily
> across preemption.
>
> * The VL won't be saved/restored, and might change arbitrarily across
> preemption.
>
> * The VL to use hasn't been programmed, so performance might vary
> arbitrarily even in the absence of preemption.
>
> ... so this isn't even safe on machines with (only) a 128-bit VL, and
> there are big open design questions for the infrastructure we'd need.
>
> > Once we encounter a good use case for SVE in the kernel, we might
> > reconsider this, but as it stands, this patch should not be applied.
>
> I agree.
>
> Christoph, please do not pick this or any other in-kernel SVE patches.
> They cannot function correctly without additional infrastructure.
>
> Demian, for patches that use NEON/SVE/SME/etc, please Cc LAKML
> (linux-arm-kernel@lists.infradead.org), so that folk familiar with ARM
> see the patches.
>
> Mark
>
> > (leaving the reply untrimmed for the benefit of the cc'ees I added)
> >
> > > raid6: neonx2 gen() 16248 MB/s
> > > raid6: neonx1 gen() 13591 MB/s
> > > raid6: using algorithm svex4 gen() 19688 MB/s
> > > raid6: .... xor() 11212 MB/s, rmw enabled
> > > raid6: using neon recovery algorithm
> > >
> > > Note that for the recovery path (`xor_syndrome`), NEON may still be
> > > selected dynamically by the algorithm benchmark, as the recovery
> > > workload is heavily memory-bound.
> > >
> > > Signed-off-by: Demian Shulhan <demyansh@gmail.com>
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Closes:
> > > https://lore.kernel.org/oe-kbuild-all/202603181940.cFwYmYoi-lkp@intel.com/
> > > ---
> > > include/linux/raid/pq.h | 3 +
> > > lib/raid6/Makefile | 5 +
> > > lib/raid6/algos.c | 5 +
> > > lib/raid6/sve.c | 675 ++++++++++++++++++++++++++++++++++++++++
> > > 4 files changed, 688 insertions(+)
> > > create mode 100644 lib/raid6/sve.c
> > >
> > > diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
> > > index 2467b3be15c9..787cc57aea9d 100644
> > > --- a/include/linux/raid/pq.h
> > > +++ b/include/linux/raid/pq.h
> > > @@ -140,6 +140,9 @@ extern const struct raid6_calls raid6_neonx1;
> > > extern const struct raid6_calls raid6_neonx2;
> > > extern const struct raid6_calls raid6_neonx4;
> > > extern const struct raid6_calls raid6_neonx8;
> > > +extern const struct raid6_calls raid6_svex1;
> > > +extern const struct raid6_calls raid6_svex2;
> > > +extern const struct raid6_calls raid6_svex4;
> > >
> > > /* Algorithm list */
> > > extern const struct raid6_calls * const raid6_algos[];
> > > diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> > > index 5be0a4e60ab1..6cdaa6f206fb 100644
> > > --- a/lib/raid6/Makefile
> > > +++ b/lib/raid6/Makefile
> > > @@ -8,6 +8,7 @@ raid6_pq-$(CONFIG_X86) += recov_ssse3.o recov_avx2.o
> > > mmx.o sse1.o sse2.o avx2.o
> > > raid6_pq-$(CONFIG_ALTIVEC) += altivec1.o altivec2.o altivec4.o
> > > altivec8.o \
> > > vpermxor1.o vpermxor2.o vpermxor4.o
> > > vpermxor8.o
> > > raid6_pq-$(CONFIG_KERNEL_MODE_NEON) += neon.o neon1.o neon2.o neon4.o
> > > neon8.o recov_neon.o recov_neon_inner.o
> > > +raid6_pq-$(CONFIG_ARM64_SVE) += sve.o
> > > raid6_pq-$(CONFIG_S390) += s390vx8.o recov_s390xc.o
> > > raid6_pq-$(CONFIG_LOONGARCH) += loongarch_simd.o recov_loongarch_simd.o
> > > raid6_pq-$(CONFIG_RISCV_ISA_V) += rvv.o recov_rvv.o
> > > @@ -67,6 +68,10 @@ CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
> > > CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
> > > CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
> > > CFLAGS_REMOVE_recov_neon_inner.o += $(CC_FLAGS_NO_FPU)
> > > +
> > > +CFLAGS_sve.o += $(CC_FLAGS_FPU)
> > > +CFLAGS_REMOVE_sve.o += $(CC_FLAGS_NO_FPU)
> > > +
> > > targets += neon1.c neon2.c neon4.c neon8.c
> > > $(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
> > > $(call if_changed,unroll)
> > > diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> > > index 799e0e5eac26..0ae73c3a4be3 100644
> > > --- a/lib/raid6/algos.c
> > > +++ b/lib/raid6/algos.c
> > > @@ -66,6 +66,11 @@ const struct raid6_calls * const raid6_algos[] = {
> > > &raid6_neonx2,
> > > &raid6_neonx1,
> > > #endif
> > > +#ifdef CONFIG_ARM64_SVE
> > > + &raid6_svex4,
> > > + &raid6_svex2,
> > > + &raid6_svex1,
> > > +#endif
> > > #ifdef CONFIG_LOONGARCH
> > > #ifdef CONFIG_CPU_HAS_LASX
> > > &raid6_lasx,
> > > diff --git a/lib/raid6/sve.c b/lib/raid6/sve.c
> > > new file mode 100644
> > > index 000000000000..d52937f806d4
> > > --- /dev/null
> > > +++ b/lib/raid6/sve.c
> > > @@ -0,0 +1,675 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * RAID-6 syndrome calculation using ARM SVE instructions
> > > + */
> > > +
> > > +#include <linux/raid/pq.h>
> > > +
> > > +#ifdef __KERNEL__
> > > +#include <asm/simd.h>
> > > +#include <linux/cpufeature.h>
> > > +#else
> > > +#define scoped_ksimd()
> > > +#define system_supports_sve() (1)
> > > +#endif
> > > +
> > > +static void raid6_sve1_gen_syndrome_real(int disks, unsigned long
> > > bytes, void **ptrs)
> > > +{
> > > + u8 **dptr = (u8 **)ptrs;
> > > + u8 *p, *q;
> > > + long z0 = disks - 3;
> > > +
> > > + p = dptr[z0 + 1];
> > > + q = dptr[z0 + 2];
> > > +
> > > + asm volatile(
> > > + ".arch armv8.2-a+sve\n"
> > > + "ptrue p0.b\n"
> > > + "cntb x3\n"
> > > + "mov w4, #0x1d\n"
> > > + "dup z4.b, w4\n"
> > > + "mov x5, #0\n"
> > > +
> > > + "0:\n"
> > > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > > + "ld1b z0.b, p0/z, [x6, x5]\n"
> > > + "mov z1.d, z0.d\n"
> > > +
> > > + "mov w7, %w[z0]\n"
> > > + "sub w7, w7, #1\n"
> > > +
> > > + "1:\n"
> > > + "cmp w7, #0\n"
> > > + "blt 2f\n"
> > > +
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > +
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + "sxtw x8, w7\n"
> > > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > > +
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z0.d, z0.d, z2.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 1b\n"
> > > + "2:\n"
> > > +
> > > + "st1b z0.b, p0, [%[p], x5]\n"
> > > + "st1b z1.b, p0, [%[q], x5]\n"
> > > +
> > > + "add x5, x5, x3\n"
> > > + "cmp x5, %[bytes]\n"
> > > + "blt 0b\n"
> > > + :
> > > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > > + [p] "r" (p), [q] "r" (q)
> > > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > > + "z0", "z1", "z2", "z3", "z4"
> > > + );
> > > +}
> > > +
> > > +static void raid6_sve1_xor_syndrome_real(int disks, int start, int
> > > stop,
> > > + unsigned long bytes, void **ptrs)
> > > +{
> > > + u8 **dptr = (u8 **)ptrs;
> > > + u8 *p, *q;
> > > + long z0 = stop;
> > > +
> > > + p = dptr[disks - 2];
> > > + q = dptr[disks - 1];
> > > +
> > > + asm volatile(
> > > + ".arch armv8.2-a+sve\n"
> > > + "ptrue p0.b\n"
> > > + "cntb x3\n"
> > > + "mov w4, #0x1d\n"
> > > + "dup z4.b, w4\n"
> > > + "mov x5, #0\n"
> > > +
> > > + "0:\n"
> > > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > > + "ld1b z1.b, p0/z, [x6, x5]\n"
> > > + "ld1b z0.b, p0/z, [%[p], x5]\n"
> > > + "eor z0.d, z0.d, z1.d\n"
> > > +
> > > + "mov w7, %w[z0]\n"
> > > + "sub w7, w7, #1\n"
> > > +
> > > + "1:\n"
> > > + "cmp w7, %w[start]\n"
> > > + "blt 2f\n"
> > > +
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + "sxtw x8, w7\n"
> > > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > > +
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z0.d, z0.d, z2.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 1b\n"
> > > + "2:\n"
> > > +
> > > + "mov w7, %w[start]\n"
> > > + "sub w7, w7, #1\n"
> > > + "3:\n"
> > > + "cmp w7, #0\n"
> > > + "blt 4f\n"
> > > +
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 3b\n"
> > > + "4:\n"
> > > +
> > > + "ld1b z2.b, p0/z, [%[q], x5]\n"
> > > + "eor z1.d, z1.d, z2.d\n"
> > > +
> > > + "st1b z0.b, p0, [%[p], x5]\n"
> > > + "st1b z1.b, p0, [%[q], x5]\n"
> > > +
> > > + "add x5, x5, x3\n"
> > > + "cmp x5, %[bytes]\n"
> > > + "blt 0b\n"
> > > + :
> > > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > > + [p] "r" (p), [q] "r" (q), [start] "r" (start)
> > > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > > + "z0", "z1", "z2", "z3", "z4"
> > > + );
> > > +}
> > > +
> > > +static void raid6_sve2_gen_syndrome_real(int disks, unsigned long
> > > bytes, void **ptrs)
> > > +{
> > > + u8 **dptr = (u8 **)ptrs;
> > > + u8 *p, *q;
> > > + long z0 = disks - 3;
> > > +
> > > + p = dptr[z0 + 1];
> > > + q = dptr[z0 + 2];
> > > +
> > > + asm volatile(
> > > + ".arch armv8.2-a+sve\n"
> > > + "ptrue p0.b\n"
> > > + "cntb x3\n"
> > > + "mov w4, #0x1d\n"
> > > + "dup z4.b, w4\n"
> > > + "mov x5, #0\n"
> > > +
> > > + "0:\n"
> > > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > > + "ld1b z0.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z5.b, p0/z, [x6, x8]\n"
> > > + "mov z1.d, z0.d\n"
> > > + "mov z6.d, z5.d\n"
> > > +
> > > + "mov w7, %w[z0]\n"
> > > + "sub w7, w7, #1\n"
> > > +
> > > + "1:\n"
> > > + "cmp w7, #0\n"
> > > + "blt 2f\n"
> > > +
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + "mov z8.d, z6.d\n"
> > > + "asr z8.b, p0/m, z8.b, #7\n"
> > > + "lsl z6.b, p0/m, z6.b, #1\n"
> > > + "and z8.d, z8.d, z4.d\n"
> > > + "eor z6.d, z6.d, z8.d\n"
> > > +
> > > + "sxtw x8, w7\n"
> > > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > > +
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z0.d, z0.d, z2.d\n"
> > > +
> > > + "eor z6.d, z6.d, z7.d\n"
> > > + "eor z5.d, z5.d, z7.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 1b\n"
> > > + "2:\n"
> > > +
> > > + "st1b z0.b, p0, [%[p], x5]\n"
> > > + "st1b z1.b, p0, [%[q], x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "st1b z5.b, p0, [%[p], x8]\n"
> > > + "st1b z6.b, p0, [%[q], x8]\n"
> > > +
> > > + "add x5, x5, x3\n"
> > > + "add x5, x5, x3\n"
> > > + "cmp x5, %[bytes]\n"
> > > + "blt 0b\n"
> > > + :
> > > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > > + [p] "r" (p), [q] "r" (q)
> > > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > > + "z0", "z1", "z2", "z3", "z4",
> > > + "z5", "z6", "z7", "z8"
> > > + );
> > > +}
> > > +
> > > +static void raid6_sve2_xor_syndrome_real(int disks, int start, int
> > > stop,
> > > + unsigned long bytes, void **ptrs)
> > > +{
> > > + u8 **dptr = (u8 **)ptrs;
> > > + u8 *p, *q;
> > > + long z0 = stop;
> > > +
> > > + p = dptr[disks - 2];
> > > + q = dptr[disks - 1];
> > > +
> > > + asm volatile(
> > > + ".arch armv8.2-a+sve\n"
> > > + "ptrue p0.b\n"
> > > + "cntb x3\n"
> > > + "mov w4, #0x1d\n"
> > > + "dup z4.b, w4\n"
> > > + "mov x5, #0\n"
> > > +
> > > + "0:\n"
> > > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > > + "ld1b z1.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z6.b, p0/z, [x6, x8]\n"
> > > +
> > > + "ld1b z0.b, p0/z, [%[p], x5]\n"
> > > + "ld1b z5.b, p0/z, [%[p], x8]\n"
> > > +
> > > + "eor z0.d, z0.d, z1.d\n"
> > > + "eor z5.d, z5.d, z6.d\n"
> > > +
> > > + "mov w7, %w[z0]\n"
> > > + "sub w7, w7, #1\n"
> > > +
> > > + "1:\n"
> > > + "cmp w7, %w[start]\n"
> > > + "blt 2f\n"
> > > +
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + "mov z8.d, z6.d\n"
> > > + "asr z8.b, p0/m, z8.b, #7\n"
> > > + "lsl z6.b, p0/m, z6.b, #1\n"
> > > + "and z8.d, z8.d, z4.d\n"
> > > + "eor z6.d, z6.d, z8.d\n"
> > > +
> > > + "sxtw x8, w7\n"
> > > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > > +
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z0.d, z0.d, z2.d\n"
> > > +
> > > + "eor z6.d, z6.d, z7.d\n"
> > > + "eor z5.d, z5.d, z7.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 1b\n"
> > > + "2:\n"
> > > +
> > > + "mov w7, %w[start]\n"
> > > + "sub w7, w7, #1\n"
> > > + "3:\n"
> > > + "cmp w7, #0\n"
> > > + "blt 4f\n"
> > > +
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + "mov z8.d, z6.d\n"
> > > + "asr z8.b, p0/m, z8.b, #7\n"
> > > + "lsl z6.b, p0/m, z6.b, #1\n"
> > > + "and z8.d, z8.d, z4.d\n"
> > > + "eor z6.d, z6.d, z8.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 3b\n"
> > > + "4:\n"
> > > +
> > > + "ld1b z2.b, p0/z, [%[q], x5]\n"
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "st1b z0.b, p0, [%[p], x5]\n"
> > > + "st1b z1.b, p0, [%[q], x5]\n"
> > > +
> > > + "add x8, x5, x3\n"
> > > + "ld1b z7.b, p0/z, [%[q], x8]\n"
> > > + "eor z6.d, z6.d, z7.d\n"
> > > + "st1b z5.b, p0, [%[p], x8]\n"
> > > + "st1b z6.b, p0, [%[q], x8]\n"
> > > +
> > > + "add x5, x5, x3\n"
> > > + "add x5, x5, x3\n"
> > > + "cmp x5, %[bytes]\n"
> > > + "blt 0b\n"
> > > + :
> > > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > > + [p] "r" (p), [q] "r" (q), [start] "r" (start)
> > > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > > + "z0", "z1", "z2", "z3", "z4",
> > > + "z5", "z6", "z7", "z8"
> > > + );
> > > +}
> > > +
> > > +static void raid6_sve4_gen_syndrome_real(int disks, unsigned long
> > > bytes, void **ptrs)
> > > +{
> > > + u8 **dptr = (u8 **)ptrs;
> > > + u8 *p, *q;
> > > + long z0 = disks - 3;
> > > +
> > > + p = dptr[z0 + 1];
> > > + q = dptr[z0 + 2];
> > > +
> > > + asm volatile(
> > > + ".arch armv8.2-a+sve\n"
> > > + "ptrue p0.b\n"
> > > + "cntb x3\n"
> > > + "mov w4, #0x1d\n"
> > > + "dup z4.b, w4\n"
> > > + "mov x5, #0\n"
> > > +
> > > + "0:\n"
> > > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > > + "ld1b z0.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z5.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z10.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z15.b, p0/z, [x6, x8]\n"
> > > +
> > > + "mov z1.d, z0.d\n"
> > > + "mov z6.d, z5.d\n"
> > > + "mov z11.d, z10.d\n"
> > > + "mov z16.d, z15.d\n"
> > > +
> > > + "mov w7, %w[z0]\n"
> > > + "sub w7, w7, #1\n"
> > > +
> > > + "1:\n"
> > > + "cmp w7, #0\n"
> > > + "blt 2f\n"
> > > +
> > > + // software pipelining: load data early
> > > + "sxtw x8, w7\n"
> > > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z12.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z17.b, p0/z, [x6, x8]\n"
> > > +
> > > + // math block 1
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z0.d, z0.d, z2.d\n"
> > > +
> > > + // math block 2
> > > + "mov z8.d, z6.d\n"
> > > + "asr z8.b, p0/m, z8.b, #7\n"
> > > + "lsl z6.b, p0/m, z6.b, #1\n"
> > > + "and z8.d, z8.d, z4.d\n"
> > > + "eor z6.d, z6.d, z8.d\n"
> > > + "eor z6.d, z6.d, z7.d\n"
> > > + "eor z5.d, z5.d, z7.d\n"
> > > +
> > > + // math block 3
> > > + "mov z13.d, z11.d\n"
> > > + "asr z13.b, p0/m, z13.b, #7\n"
> > > + "lsl z11.b, p0/m, z11.b, #1\n"
> > > + "and z13.d, z13.d, z4.d\n"
> > > + "eor z11.d, z11.d, z13.d\n"
> > > + "eor z11.d, z11.d, z12.d\n"
> > > + "eor z10.d, z10.d, z12.d\n"
> > > +
> > > + // math block 4
> > > + "mov z18.d, z16.d\n"
> > > + "asr z18.b, p0/m, z18.b, #7\n"
> > > + "lsl z16.b, p0/m, z16.b, #1\n"
> > > + "and z18.d, z18.d, z4.d\n"
> > > + "eor z16.d, z16.d, z18.d\n"
> > > + "eor z16.d, z16.d, z17.d\n"
> > > + "eor z15.d, z15.d, z17.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 1b\n"
> > > + "2:\n"
> > > +
> > > + "st1b z0.b, p0, [%[p], x5]\n"
> > > + "st1b z1.b, p0, [%[q], x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "st1b z5.b, p0, [%[p], x8]\n"
> > > + "st1b z6.b, p0, [%[q], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "st1b z10.b, p0, [%[p], x8]\n"
> > > + "st1b z11.b, p0, [%[q], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "st1b z15.b, p0, [%[p], x8]\n"
> > > + "st1b z16.b, p0, [%[q], x8]\n"
> > > +
> > > + "add x8, x3, x3\n"
> > > + "add x5, x5, x8, lsl #1\n"
> > > + "cmp x5, %[bytes]\n"
> > > + "blt 0b\n"
> > > + :
> > > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > > + [p] "r" (p), [q] "r" (q)
> > > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > > + "z0", "z1", "z2", "z3", "z4",
> > > + "z5", "z6", "z7", "z8",
> > > + "z10", "z11", "z12", "z13",
> > > + "z15", "z16", "z17", "z18"
> > > + );
> > > +}
> > > +
> > > +static void raid6_sve4_xor_syndrome_real(int disks, int start, int
> > > stop,
> > > + unsigned long bytes, void **ptrs)
> > > +{
> > > + u8 **dptr = (u8 **)ptrs;
> > > + u8 *p, *q;
> > > + long z0 = stop;
> > > +
> > > + p = dptr[disks - 2];
> > > + q = dptr[disks - 1];
> > > +
> > > + asm volatile(
> > > + ".arch armv8.2-a+sve\n"
> > > + "ptrue p0.b\n"
> > > + "cntb x3\n"
> > > + "mov w4, #0x1d\n"
> > > + "dup z4.b, w4\n"
> > > + "mov x5, #0\n"
> > > +
> > > + "0:\n"
> > > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > > + "ld1b z1.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z6.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z11.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z16.b, p0/z, [x6, x8]\n"
> > > +
> > > + "ld1b z0.b, p0/z, [%[p], x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z5.b, p0/z, [%[p], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z10.b, p0/z, [%[p], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z15.b, p0/z, [%[p], x8]\n"
> > > +
> > > + "eor z0.d, z0.d, z1.d\n"
> > > + "eor z5.d, z5.d, z6.d\n"
> > > + "eor z10.d, z10.d, z11.d\n"
> > > + "eor z15.d, z15.d, z16.d\n"
> > > +
> > > + "mov w7, %w[z0]\n"
> > > + "sub w7, w7, #1\n"
> > > +
> > > + "1:\n"
> > > + "cmp w7, %w[start]\n"
> > > + "blt 2f\n"
> > > +
> > > + // software pipelining: load data early
> > > + "sxtw x8, w7\n"
> > > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z12.b, p0/z, [x6, x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z17.b, p0/z, [x6, x8]\n"
> > > +
> > > + // math block 1
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z0.d, z0.d, z2.d\n"
> > > +
> > > + // math block 2
> > > + "mov z8.d, z6.d\n"
> > > + "asr z8.b, p0/m, z8.b, #7\n"
> > > + "lsl z6.b, p0/m, z6.b, #1\n"
> > > + "and z8.d, z8.d, z4.d\n"
> > > + "eor z6.d, z6.d, z8.d\n"
> > > + "eor z6.d, z6.d, z7.d\n"
> > > + "eor z5.d, z5.d, z7.d\n"
> > > +
> > > + // math block 3
> > > + "mov z13.d, z11.d\n"
> > > + "asr z13.b, p0/m, z13.b, #7\n"
> > > + "lsl z11.b, p0/m, z11.b, #1\n"
> > > + "and z13.d, z13.d, z4.d\n"
> > > + "eor z11.d, z11.d, z13.d\n"
> > > + "eor z11.d, z11.d, z12.d\n"
> > > + "eor z10.d, z10.d, z12.d\n"
> > > +
> > > + // math block 4
> > > + "mov z18.d, z16.d\n"
> > > + "asr z18.b, p0/m, z18.b, #7\n"
> > > + "lsl z16.b, p0/m, z16.b, #1\n"
> > > + "and z18.d, z18.d, z4.d\n"
> > > + "eor z16.d, z16.d, z18.d\n"
> > > + "eor z16.d, z16.d, z17.d\n"
> > > + "eor z15.d, z15.d, z17.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 1b\n"
> > > + "2:\n"
> > > +
> > > + "mov w7, %w[start]\n"
> > > + "sub w7, w7, #1\n"
> > > + "3:\n"
> > > + "cmp w7, #0\n"
> > > + "blt 4f\n"
> > > +
> > > + // math block 1
> > > + "mov z3.d, z1.d\n"
> > > + "asr z3.b, p0/m, z3.b, #7\n"
> > > + "lsl z1.b, p0/m, z1.b, #1\n"
> > > + "and z3.d, z3.d, z4.d\n"
> > > + "eor z1.d, z1.d, z3.d\n"
> > > +
> > > + // math block 2
> > > + "mov z8.d, z6.d\n"
> > > + "asr z8.b, p0/m, z8.b, #7\n"
> > > + "lsl z6.b, p0/m, z6.b, #1\n"
> > > + "and z8.d, z8.d, z4.d\n"
> > > + "eor z6.d, z6.d, z8.d\n"
> > > +
> > > + // math block 3
> > > + "mov z13.d, z11.d\n"
> > > + "asr z13.b, p0/m, z13.b, #7\n"
> > > + "lsl z11.b, p0/m, z11.b, #1\n"
> > > + "and z13.d, z13.d, z4.d\n"
> > > + "eor z11.d, z11.d, z13.d\n"
> > > +
> > > + // math block 4
> > > + "mov z18.d, z16.d\n"
> > > + "asr z18.b, p0/m, z18.b, #7\n"
> > > + "lsl z16.b, p0/m, z16.b, #1\n"
> > > + "and z18.d, z18.d, z4.d\n"
> > > + "eor z16.d, z16.d, z18.d\n"
> > > +
> > > + "sub w7, w7, #1\n"
> > > + "b 3b\n"
> > > + "4:\n"
> > > +
> > > + // Load q and XOR
> > > + "ld1b z2.b, p0/z, [%[q], x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "ld1b z7.b, p0/z, [%[q], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z12.b, p0/z, [%[q], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "ld1b z17.b, p0/z, [%[q], x8]\n"
> > > +
> > > + "eor z1.d, z1.d, z2.d\n"
> > > + "eor z6.d, z6.d, z7.d\n"
> > > + "eor z11.d, z11.d, z12.d\n"
> > > + "eor z16.d, z16.d, z17.d\n"
> > > +
> > > + // Store results
> > > + "st1b z0.b, p0, [%[p], x5]\n"
> > > + "st1b z1.b, p0, [%[q], x5]\n"
> > > + "add x8, x5, x3\n"
> > > + "st1b z5.b, p0, [%[p], x8]\n"
> > > + "st1b z6.b, p0, [%[q], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "st1b z10.b, p0, [%[p], x8]\n"
> > > + "st1b z11.b, p0, [%[q], x8]\n"
> > > + "add x8, x8, x3\n"
> > > + "st1b z15.b, p0, [%[p], x8]\n"
> > > + "st1b z16.b, p0, [%[q], x8]\n"
> > > +
> > > + "add x8, x3, x3\n"
> > > + "add x5, x5, x8, lsl #1\n"
> > > + "cmp x5, %[bytes]\n"
> > > + "blt 0b\n"
> > > + :
> > > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > > + [p] "r" (p), [q] "r" (q), [start] "r" (start)
> > > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > > + "z0", "z1", "z2", "z3", "z4",
> > > + "z5", "z6", "z7", "z8",
> > > + "z10", "z11", "z12", "z13",
> > > + "z15", "z16", "z17", "z18"
> > > + );
> > > +}
> > > +
> > > +#define RAID6_SVE_WRAPPER(_n) \
> > > + static void raid6_sve ## _n ## _gen_syndrome(int disks, \
> > > + size_t bytes, void **ptrs) \
> > > + { \
> > > + scoped_ksimd() \
> > > + raid6_sve ## _n ## _gen_syndrome_real(disks, \
> > > + (unsigned long)bytes, ptrs); \
> > > + } \
> > > + static void raid6_sve ## _n ## _xor_syndrome(int disks, \
> > > + int start, int stop, \
> > > + size_t bytes, void **ptrs) \
> > > + { \
> > > + scoped_ksimd() \
> > > + raid6_sve ## _n ## _xor_syndrome_real(disks, \
> > > + start, stop, (unsigned long)bytes, ptrs);\
> > > + } \
> > > + struct raid6_calls const raid6_svex ## _n = { \
> > > + raid6_sve ## _n ## _gen_syndrome, \
> > > + raid6_sve ## _n ## _xor_syndrome, \
> > > + raid6_have_sve, \
> > > + "svex" #_n, \
> > > + 0 \
> > > + }
> > > +
> > > +static int raid6_have_sve(void)
> > > +{
> > > + return system_supports_sve();
> > > +}
> > > +
> > > +RAID6_SVE_WRAPPER(1);
> > > +RAID6_SVE_WRAPPER(2);
> > > +RAID6_SVE_WRAPPER(4);
> > > --
> > > 2.43.0
^ permalink raw reply
* [PATCH 3/3] arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
index 29b298af0d739100d33ff43a8b955a37821b3ef7..1b5ba3c47164f28756bb99210a5961bfaa881220 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
@@ -292,7 +292,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x94>;
+ fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1d4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
--
2.37.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
index 31a3ca137e63640a2387d3497274f10a6b8c6766..48a687926aa1b88a3d8bef25ff97bebec3777b00 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
@@ -283,7 +283,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x84>;
+ fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1c4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
--
2.37.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
While at here, also correct interrupt type as IRQ_TYPE_LEVEL_LOW.
Fixes: cbd3ef64eb9d1 ("arm64: dts: Add support for Emtop SoM & Baseboard")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
index 67d22d3768aa8ae7343cffeebcfdde89ed25cc2d..507d1824d99d99b1f795b14aea538444c9476f65 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
@@ -60,7 +60,7 @@ pmic@25 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
regulators {
buck1: BUCK1 {
@@ -194,7 +194,7 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
pinctrl_pmic: emtop-pmic-grp {
fsl,pins = <
- MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
>;
};
--
2.37.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: imx8m: Correct PAD settings for PMIC_nINT (2nd part)
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
There was a patchset for i.MX8MP [1], but after further check,
i.MX8MM/N were missed, there are three boards that might also has
interrupt storm issue. I not have the boards, per NXP board design
, PMIC_nINT requires CPU internal pull up, I think most vendors will
follow NXP design. So updates the i.MX8MM/N boards, but I not have
the boards for testing. If board owners would give a test, that would
be great.
[1] https://lore.kernel.org/all/20260326-imx8mp-dts-fix-v2-v2-0-62c4ce727448@nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 ++--
arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260329-imx8m-regulator-4e2e3f1b6ed5
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH] media: cedrus: skip invalid H.264 reference list entries
From: Chen-Yu Tsai @ 2026-03-29 12:44 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mripard, Pengpeng Hou, paulk, mchehab, gregkh, samuel,
nicolas.dufresne, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <2823210.mvXUDI8C0e@jernej-laptop>
On Sun, Mar 29, 2026 at 5:21 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Dne torek, 24. marec 2026 ob 09:08:56 Srednjeevropski poletni čas je Pengpeng Hou napisal(a):
> > Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the
> > stateless slice control and later uses their indices to look up
> > decode->dpb[] in _cedrus_write_ref_list().
> >
> > Rejecting such controls in cedrus_try_ctrl() would break existing
> > userspace, since stateless H.264 reference lists may legitimately carry
> > out-of-range indices for missing references. Instead, guard the actual
> > DPB lookup in Cedrus and skip entries whose indices do not fit the fixed
> > V4L2_H264_NUM_DPB_ENTRIES array.
> >
> > This keeps the fix local to the driver use site and avoids out-of-bounds
> > reads from malformed or unsupported reference list entries.
> >
> > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>
> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Chen-Yu Tsai <wens@kernel.org>
This fixes a KASAN slab-use-after-free warning when running fluster H.264
tests.
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: st: spear: remove undocumented thermal_flags property
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
spear13xx.dtsi defines a thermal_flags property in spear thermal sensor
node which is both unused in kernel and undocumented in spear thermal
sensor's binding.
There were no dtbs_check warnings associated with this property as the
underlying spear thermal binding was not converted to DTSchema.
Most likely st,thermal-flags is a misspelling of thermal_flags in
spear13xx.dtsi. Since both st/spear1310.dtsi and st/spear1340.dtsi
define st,thermal-flags property in spear thermal sensor node, we can
safely remove this property from spear13xx.dtsi.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v2:
- Reword the commit message and subject to correct explanation in patch 2
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 159e941708ca..0bb88f2d4ef5 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -332,7 +332,6 @@ wdt@ec800620 {
thermal@e07008c4 {
compatible = "st,thermal-spear1340";
reg = <0xe07008c4 0x4>;
- thermal_flags = <0x7000>;
};
};
};
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Sebastián Alba @ 2026-03-29 12:35 UTC (permalink / raw)
To: Phil Elwell
Cc: Greg Kroah-Hartman, Florian Fainelli,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, linux-staging,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
linux-arm-kernel, Dave Stevenson, Raspberry Pi Kernel Maintenance
In-Reply-To: <CAMEGJJ0zgab3WN=rb2o+UgEq_coX5LnkyPj3UNrBSMQbTGU7Zw@mail.gmail.com>
Hi Phil,
Thanks for the pointer. I've opened PR #7294 against rpi-6.6.y:
https://github.com/raspberrypi/linux/pull/7294
Sebastián
El dom, 29 mar 2026 a las 2:51, Phil Elwell (<phil@raspberrypi.com>) escribió:
>
>
>
> On Sun, 29 Mar 2026, 08:05 Sebastián Alba, <sebasjosue84@gmail.com> wrote:
>>
>> Hi Greg, Thanks for the quick review.
>>
>> Regarding kmalloc_array(): the patch does replace kmalloc() with
>> kmalloc_array() - perhaps the question is about the remaining
>> ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
>> That multiplication is now safe because kmalloc_array() already
>> verified that op_count * sizeof(*block) does not overflow(if it did,
>> kmalloc_array would have returned NULL and we'd have exited). Happy to
>> add a comment clarifying this if you prefer.
>>
>> Regarding the Fixes tag: the commit dfdc7a773374 is from the
>> raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
>> appears to only exist in the Raspberry Pi kernel fork and has not been
>> merged into mainline staging.
>>
>> I apologize for sending this to the wrong tree. Should these patches
>> go directly to the Raspberry Pi kernel maintainers
>> (kernel-list@raspberrypi.com) instead?
>
>
> Open a Pull Request at our Linux repo:
>
> https://github com/raspberrypi/linux/
>
> Phil
>
>> El dom, 29 mar 2026 a las 0:33, Greg Kroah-Hartman
>> (<gregkh@linuxfoundation.org>) escribió:
>> >
>> > On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
>> > > From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>> > >
>> > > vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
>> > > compute the allocation size passed to kmalloc(). Since ioparam.op_count
>> > > is a __u32 supplied directly by userspace via ioctl, an attacker can
>> > > choose a value that causes the multiplication to overflow on 32-bit
>> > > platforms, resulting in a small allocation followed by a large
>> > > copy_from_user() and out-of-bounds heap reads in the subsequent loop.
>> > >
>> > > Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
>> > > Also add an early return for op_count == 0 to avoid a zero-size
>> > > allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
>> > > correctly indicate out of memory.
>> >
>> > Why not use kmalloc_array() instead?
>> >
>> > >
>> > > The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
>> > > reachable by any unprivileged local user.
>> > >
>> > > Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
>> >
>> > I do not see that git id anywhere, what tree is it in?
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>>
>>
>> --
>> Sebastián Alba
--
Sebastián Alba
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry, Krzysztof Kozlowski
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v2:
- No changes
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt
deleted file mode 100644
index 93e3b67c102d..000000000000
--- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* SPEAr Thermal
-
-Required properties:
-- compatible : "st,thermal-spear1340"
-- reg : Address range of the thermal registers
-- st,thermal-flags: flags used to enable thermal sensor
-
-Example:
-
- thermal@fc000000 {
- compatible = "st,thermal-spear1340";
- reg = <0xfc000000 0x1000>;
- st,thermal-flags = <0x7000>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
new file mode 100644
index 000000000000..e3462a974691
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr Thermal Sensor
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+properties:
+ compatible:
+ const: st,thermal-spear1340
+
+ reg:
+ maxItems: 1
+
+ st,thermal-flags:
+ description: flags used to enable thermal sensor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - st,thermal-flags
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* [PATCH v3 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
This patch series converts SPEAr Thermal Sensor bindings to DT schema
and removes the thermal_flags property from spear13xx.dtsi.
Changes since v2:
- Reword the commit message and subject to correct explanation in patch 2
- No changes in patch 1
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Gopi Krishna Menon (2):
dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
ARM: dts: st: spear: remove undocumented thermal_flags property
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
3 files changed, 36 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
--
2.52.0
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Michal Piekos @ 2026-03-29 12:07 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <5977334.DvuYhMxLoT@jernej-laptop>
On Sun, Mar 29, 2026 at 01:53:45PM +0200, Jernej Škrabec wrote:
> Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> > Add support for timer by reusing existing sun4i timer driver.
> >
> > H616 timer is compatible with earlier sunxi timer variants and provides
> > both clocksource and clockevent functionality. It runs from 24 MHz
> > oscillator. It can serve as broadcast clockevent for wake up from idle
> > states.
> >
> > Tested on Orange Pi Zero 3:
> > - timer is registered as clocksource:
> > - switching clocksource at runtime works
> > - timer operates as a broadcast clockevent device
> > - no regression observed compared to arch_sys_counter
> >
> > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > ---
> > Test results:
> >
> > Clocksource switching:
> > cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> > arch_sys_counter timer
> > echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > [ 5031.105997] clocksource: Switched to clocksource timer
> >
> > Clockevent configuration:
> > cat /proc/timer_list
> > ...
> > Tick Device: mode: 1
> > Broadcast device
> > Clock Event Device: sun4i_tick
> > max_delta_ns: 178956969070
> > min_delta_ns: 1000
> > mult: 51539608
> > shift: 31
> > mode: 1
> > next_event: 9223372036854775807 nsecs
> > set_next_event: sun4i_clkevt_next_event
> > shutdown: sun4i_clkevt_shutdown
> > periodic: sun4i_clkevt_set_periodic
> > oneshot: sun4i_clkevt_set_oneshot
> > resume: sun4i_clkevt_shutdown
> > event_handler: tick_handle_oneshot_broadcast
> > ...
> >
> > Cyclictest measurements:
> > Dominated by system scheduler latency and do not reflect clocksource
> > precision.
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > index 8d1110c14bad..bf054869e78b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> > };
> > };
> >
> > + timer0: timer@3009000 {
> > + compatible = "allwinner,sun50i-h616-timer",
> > + "allwinner,sun8i-a23-timer";
>
> You have to add above combo to DT bindings.
>
> Best regards,
> Jernej
Not sure I understand your comment correctly but binding for h616 is already
there:
Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml:21-27
- items:
- enum:
- allwinner,sun20i-d1-timer
- allwinner,sun50i-a64-timer
- allwinner,sun50i-h6-timer
- allwinner,sun50i-h616-timer
- const: allwinner,sun8i-a23-timer
BR
Michal
>
> > + reg = <0x03009000 0xa0>;
> > + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > watchdog: watchdog@30090a0 {
> > compatible = "allwinner,sun50i-h616-wdt",
> > "allwinner,sun6i-a31-wdt";
> >
> > ---
> > base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> > change-id: 20260328-h616-timer-046e6ac3549e
> >
> > Best regards,
> >
>
>
>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Jernej Škrabec @ 2026-03-29 11:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Michal Piekos
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
In-Reply-To: <20260329-h616-timer-v1-1-5966d0420a66@mmpsystems.pl>
Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> Add support for timer by reusing existing sun4i timer driver.
>
> H616 timer is compatible with earlier sunxi timer variants and provides
> both clocksource and clockevent functionality. It runs from 24 MHz
> oscillator. It can serve as broadcast clockevent for wake up from idle
> states.
>
> Tested on Orange Pi Zero 3:
> - timer is registered as clocksource:
> - switching clocksource at runtime works
> - timer operates as a broadcast clockevent device
> - no regression observed compared to arch_sys_counter
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> Test results:
>
> Clocksource switching:
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> arch_sys_counter timer
> echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> [ 5031.105997] clocksource: Switched to clocksource timer
>
> Clockevent configuration:
> cat /proc/timer_list
> ...
> Tick Device: mode: 1
> Broadcast device
> Clock Event Device: sun4i_tick
> max_delta_ns: 178956969070
> min_delta_ns: 1000
> mult: 51539608
> shift: 31
> mode: 1
> next_event: 9223372036854775807 nsecs
> set_next_event: sun4i_clkevt_next_event
> shutdown: sun4i_clkevt_shutdown
> periodic: sun4i_clkevt_set_periodic
> oneshot: sun4i_clkevt_set_oneshot
> resume: sun4i_clkevt_shutdown
> event_handler: tick_handle_oneshot_broadcast
> ...
>
> Cyclictest measurements:
> Dominated by system scheduler latency and do not reflect clocksource
> precision.
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> index 8d1110c14bad..bf054869e78b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> };
> };
>
> + timer0: timer@3009000 {
> + compatible = "allwinner,sun50i-h616-timer",
> + "allwinner,sun8i-a23-timer";
You have to add above combo to DT bindings.
Best regards,
Jernej
> + reg = <0x03009000 0xa0>;
> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h616-wdt",
> "allwinner,sun6i-a31-wdt";
>
> ---
> base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> change-id: 20260328-h616-timer-046e6ac3549e
>
> Best regards,
>
^ permalink raw reply
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Andy Shevchenko @ 2026-03-29 11:49 UTC (permalink / raw)
To: Bartosz Golaszewski, Heikki Krogerus
Cc: Aaro Koskinen, Janusz Krzysztofik, Arnd Bergmann,
Bartosz Golaszewski, Tony Lindgren, Russell King, Dmitry Torokhov,
Hans de Goede, Linux-OMAP, linux-arm-kernel, linux-kernel,
Kevin Hilman
In-Reply-To: <CAMRc=McVPskF4pMQSz=hR8CkyZhoPmCU_yJFT66vgTCPJd3-Vw@mail.gmail.com>
+Cc: Heikki, the author of the code in question.
On Fri, Mar 27, 2026 at 06:23:29PM +0100, Bartosz Golaszewski wrote:
> On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> > > Hmm, I'm wondering if there's a race with consumers already requesting
> > > the GPIOs after the controller device is registered but before the
> > > software node is added. I'll send a version with software nodes being
> > > registered first, then passes as firmware nodes to the platform device
> > > API before the device is registered.
> >
> > It crashes early, I was able to get an UART log from OSK (another
> > 16xx board):
> >
> > [ 1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
> > [ 1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> > [ 1.019500] Stack: (0xc2809ed0 to 0xc280a000)
> > [ 1.024230] 9ec0: c072d000 c0529474 c06b3aa0 c050a3cc
> > [ 1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
> > [ 1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
> > [ 1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
> > [ 1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
> > [ 1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
> > [ 1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
> > [ 1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
> > [ 1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [ 1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> > [ 1.111206] Call trace:
> > [ 1.111328] software_node_to_swnode from device_add_software_node+0x20/0x80
> > [ 1.121704] device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
> > [ 1.128997] omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
> > [ 1.135620] do_one_initcall from kernel_init_freeable+0x1ec/0x240
> > [ 1.142517] kernel_init_freeable from kernel_init+0x10/0x108
> > [ 1.148864] kernel_init from ret_from_fork+0x14/0x28
> > [ 1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
> > [ 1.159820] 9fa0: 00000000 00000000 00000000 00000000
> > [ 1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [ 1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > [ 1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
> > [ 1.191040] ---[ end trace 0000000000000000 ]---
> > [ 1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [ 1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
> Thanks. This makes sense. Both omap16xx_gpio_init() and
> software_node_init() run as postcore_initcall() so if the order is not
> right, it will fail.
>
> Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> reason to run software_node_init() as a postcore initcall? It only
> allocates the kset, can we move it to core_initcall() by any chance?
Good question. I don't know why it's chosen like this.
Let ask Heikki, who is the author of the code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Michal Piekos @ 2026-03-29 11:43 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
Add support for timer by reusing existing sun4i timer driver.
H616 timer is compatible with earlier sunxi timer variants and provides
both clocksource and clockevent functionality. It runs from 24 MHz
oscillator. It can serve as broadcast clockevent for wake up from idle
states.
Tested on Orange Pi Zero 3:
- timer is registered as clocksource:
- switching clocksource at runtime works
- timer operates as a broadcast clockevent device
- no regression observed compared to arch_sys_counter
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Test results:
Clocksource switching:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
arch_sys_counter timer
echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
[ 5031.105997] clocksource: Switched to clocksource timer
Clockevent configuration:
cat /proc/timer_list
...
Tick Device: mode: 1
Broadcast device
Clock Event Device: sun4i_tick
max_delta_ns: 178956969070
min_delta_ns: 1000
mult: 51539608
shift: 31
mode: 1
next_event: 9223372036854775807 nsecs
set_next_event: sun4i_clkevt_next_event
shutdown: sun4i_clkevt_shutdown
periodic: sun4i_clkevt_set_periodic
oneshot: sun4i_clkevt_set_oneshot
resume: sun4i_clkevt_shutdown
event_handler: tick_handle_oneshot_broadcast
...
Cyclictest measurements:
Dominated by system scheduler latency and do not reflect clocksource
precision.
---
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index 8d1110c14bad..bf054869e78b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
};
};
+ timer0: timer@3009000 {
+ compatible = "allwinner,sun50i-h616-timer",
+ "allwinner,sun8i-a23-timer";
+ reg = <0x03009000 0xa0>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
watchdog: watchdog@30090a0 {
compatible = "allwinner,sun50i-h616-wdt",
"allwinner,sun6i-a31-wdt";
---
base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
change-id: 20260328-h616-timer-046e6ac3549e
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply related
* [PATCH] spi: stm32-ospi: Fix resource leak in remove() callback
From: Felix Gu @ 2026-03-29 11:14 UTC (permalink / raw)
To: Mark Brown, Maxime Coquelin, Alexandre Torgue, Patrice Chotard
Cc: linux-spi, linux-stm32, linux-arm-kernel, linux-kernel, Felix Gu
The remove() callback returned early if pm_runtime_resume_and_get()
failed, skipping the cleanup of spi controller and other resources.
Remove the early return so cleanup completes regardless of PM resume
result.
Fixes: 79b8a705e26c ("spi: stm32: Add OSPI driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/spi/spi-stm32-ospi.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/spi/spi-stm32-ospi.c b/drivers/spi/spi-stm32-ospi.c
index acf2d182e8b1..192a20de1ae6 100644
--- a/drivers/spi/spi-stm32-ospi.c
+++ b/drivers/spi/spi-stm32-ospi.c
@@ -984,11 +984,8 @@ static int stm32_ospi_probe(struct platform_device *pdev)
static void stm32_ospi_remove(struct platform_device *pdev)
{
struct stm32_ospi *ospi = platform_get_drvdata(pdev);
- int ret;
- ret = pm_runtime_resume_and_get(ospi->dev);
- if (ret < 0)
- return;
+ pm_runtime_resume_and_get(ospi->dev);
spi_unregister_controller(ospi->ctrl);
/* Disable ospi */
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260329-ospi-6aa5060f090e
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
From: Dmitry Baryshkov @ 2026-03-29 11:08 UTC (permalink / raw)
To: Canfeng Zhuang
Cc: konradybcio, andersson, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-arm-kernel
In-Reply-To: <20260327083101.1343613-3-canfeng.zhuang@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 04:31:01PM +0800, Canfeng Zhuang wrote:
> The monaco-evk mezzanine connector supports a robot expansion board that
> requires UART6, which is currently disabled. This prevents the expansion
> board from exchanging data and control commands.
>
> Enable UART6 and assign the serial2 alias to provide stable device
> enumeration for the expansion board.
>
> Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco-evk.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> index 565418b86b2a..0b26861eac02 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> @@ -21,6 +21,7 @@ aliases {
> ethernet0 = ðernet0;
> i2c1 = &i2c1;
> serial0 = &uart7;
> + serial2 = &uart6;
What happened to serial1?
> };
>
> chosen {
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH net-next v2] net: airoha: Delay offloading until all net_devices are fully registered
From: Lorenzo Bianconi @ 2026-03-29 10:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev
Netfilter flowtable can theoretically try to offload flower rules as soon
as a net_device is registered while all the other ones are not
registered or initialized, triggering a possible NULL pointer dereferencing
of qdma pointer in airoha_ppe_set_cpu_port routine. Moreover, if
register_netdev() fails for a particular net_device, there is a small
race if Netfilter tries to offload flowtable rules before all the
net_devices are properly unregistered in airoha_probe() error patch,
triggering a NULL pointer dereferencing in airoha_ppe_set_cpu_port
routine. In order to avoid any possible race, delay offloading until
all net_devices are registered in the networking subsystem.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v2:
- Do not grab flow_offload_mutex in airoha_register_gdm_devices() since
it can trigger a deadlock. Add DEV_STATE_REGISTERED flag instead to
mark when all net_devices are fully registered.
- Link to v1: https://lore.kernel.org/r/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 ++
drivers/net/ethernet/airoha/airoha_eth.h | 1 +
drivers/net/ethernet/airoha/airoha_ppe.c | 7 +++++++
3 files changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..743ef0db30980ce74059dfb63553030ef3bf735f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2957,6 +2957,8 @@ static int airoha_register_gdm_devices(struct airoha_eth *eth)
return err;
}
+ set_bit(DEV_STATE_REGISTERED, ð->state);
+
return 0;
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 7df4dbcd8861856c54c2a38bc89c69180ac2f6dc..af29fc74165b8fffb59f45b4725dbd963f1b876d 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -88,6 +88,7 @@ enum {
enum {
DEV_STATE_INITIALIZED,
+ DEV_STATE_REGISTERED,
};
enum {
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 58b14aea7c2f33ebce11c51d892eefff692378ca..c057bb2d105d92947bb8c421d89ee94fc0c10f2f 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1389,6 +1389,13 @@ int airoha_ppe_setup_tc_block_cb(struct airoha_ppe_dev *dev, void *type_data)
struct airoha_eth *eth = ppe->eth;
int err = 0;
+ /* Netfilter flowtable can try to offload flower rules while not all
+ * the net_devices are registered or initialized. Delay offloading
+ * until all net_devices are registered in the system.
+ */
+ if (!test_bit(DEV_STATE_REGISTERED, ð->state))
+ return -EBUSY;
+
mutex_lock(&flow_offload_mutex);
if (!eth->npu)
---
base-commit: ced629dc8e5c51ff2b5d847adeeb1035cd655d58
change-id: 20260321-airoha-regiser-race-fix-fe854f61d760
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Andreas Haarmann-Thiemann @ 2026-03-29 10:11 UTC (permalink / raw)
To: linusw; +Cc: ulli.kroll, netdev, linux-arm-kernel
Hello,
I am writing to report an SKB memory leak in the Cortina Gemini Ethernet
driver (drivers/net/ethernet/cortina/gemini.c) that causes the device to
lock up under sustained receive load.
Hardware affected: Raidsonic IB-NAS4220-B (Storlink/Cortina Gemini SL3516,
ARM FA526), running OpenWrt 6.12.67.
--- Observed Behaviour ---
Under sustained RX load (e.g. large file transfers over the network), the
device freezes completely and requires a hard power cycle. No kernel panic
or oops is produced; the system simply stops responding.
--- Root Cause Analysis ---
In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when
gmac_get_queue_page() returns NULL for the second page of a multi-page
fragment, the driver logs an error and continues - but does not free the
in-progress skb that was already being assembled via napi_build_skb() /
napi_get_frags():
gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
if (!gpage) {
dev_err(geth->dev, "could not find mapping\n");
/* BUG: skb leaked here */
port->stats.rx_dropped++;
continue;
}
This path is distinct from the similar block in gmac_cleanup_rxq(), which
correctly only logs "could not find page" without an skb in flight.
Each occurrence of this error path leaks one skb. Under sustained traffic
the leak exhausts kernel memory, causing the observed lockup.
Note: this analysis is based on code review only. The fix below has not
yet been verified on hardware due to the driver being compiled into the
kernel (CONFIG_GEMINI_ETHERNET=y) on the affected device, which prevents
loading a patched module at runtime.
--- Proposed Fix ---
Free the in-progress skb via napi_free_frags() before continuing, matching
the pattern already used elsewhere in the driver:
diff --git a/drivers/net/ethernet/cortina/gemini.c
b/drivers/net/ethernet/cortina/gemini.c
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int
budget)
gpage = gmac_get_queue_page(geth, port, mapping +
PAGE_SIZE);
if (!gpage) {
dev_err(geth->dev, "could not find mapping\n");
+ if (skb) {
+ napi_free_frags(&port->napi);
+ skb = NULL;
+ }
port->stats.rx_dropped++;
continue;
}
--- Additional Notes ---
A similar "could not find page" error path exists in gmac_cleanup_rxq().
That path does not have an skb in flight at that point and does not require
the same fix.
I would be happy to submit this as a formal patch if the analysis looks
correct to you.
Thank you for your time.
Best regards,
Andreas Haarmann-Thiemann
eitschman@nebelreich.de
^ permalink raw reply
* Re: [PATCH net-next 01/10] net: stmmac: fix TSO support when some channels have TBS available
From: Russell King (Oracle) @ 2026-03-29 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <E1w6bKj-0000000ELtf-3md9@rmk-PC.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:36:41PM +0000, Russell King (Oracle) wrote:
> According to the STM32MP25xx manual, which is dwmac v5.3, TBS (time
> based scheduling) is not permitted for channels which have hardware
> TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and
> TBS feature enabling during driver open") concurs with this, but it
> is incomplete.
>
> This commit avoids enabling TSO support on the channels which have
> TBS available, which, as far as the hardware is concerned, means we
> do not set the TSE bit in the DMA channel's transmit control register.
>
> However, the net device's features apply to all queues(channels), which
> means these channels may still be handed TSO skbs to transmit, and the
> driver will pass them to stmmac_tso_xmit(). This will generate the
> descriptors for TSO, even though the channel has the TSE bit clear.
>
> Fix this by checking whether the queue(channel) has TBS available,
> and if it does, fall back to software GSO support.
This is sufficient for the immediate issue of fixing the patch below,
but I think there's another issue that also needs fixing here.
TSO requires the hardware to support checksum offload, and there is
a comment in the driver:
/* DWMAC IPs can be synthesized to support tx coe only for a few tx
* queues. In that case, checksum offloading for those queues that don't
* support tx coe needs to fallback to software checksum calculation.
*
* Packets that won't trigger the COE e.g. most DSA-tagged packets will
* also have to be checksummed in software.
*/
So, it seems at the very least we need to add a check (in a subsequent
patch) for priv->plat->tx_queues_cfg[queue].coe_unsupported to
stmmac_channel_tso_permitted().
I'm also wondering about the stmmac_has_ip_ethertype() thing, which
checks whether the skb can be checksummed by the hardware, and how that
interacts with TSO, and whether that's yet another hole that needs
plugging.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Krzysztof Kozlowski @ 2026-03-29 9:34 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329-starfish-of-eternal-storm-f16de5@quoll>
On 29/03/2026 11:31, Krzysztof Kozlowski wrote:
> On Sun, Mar 29, 2026 at 11:45:20AM +0530, Gopi Krishna Menon wrote:
>> st,thermal-flags is a required property in SPEAr Thermal Sensor node,
>> which is incorrectly written as thermal_flags in spear13xx.dtsi.
>>
>> Rename thermal_flags to st,thermal-flags to fix the property name
>
> Does this have an impact? If yes, then why no fixes? If no, then why
> not? How this could ever worked? Maybe this is completely unnecessary.
>
> We already talked about this and I don't get why this change is neeeded
> and why we discuss the same problem.
and by "this change" I meant, "rename" part, instead of "removal".
Your task is analyze entire code, understand what was wrong and provide
proper solution.
Best regards,
Krzysztof
^ 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