* [RFC PATCH v4 7/9] arm64: dts: rockchip: rk356x: Add the NPU and its IOMMU
From: MidG971 @ 2026-06-13 7:01 UTC (permalink / raw)
To: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson
Cc: dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik,
jonas, Midgy BALON
In-Reply-To: <20260613070116.438906-1-midgy971@gmail.com>
From: Midgy BALON <midgy971@gmail.com>
The RK3568 has an NVDLA-derived NPU at fde40000 with its own IOMMU at
fde4b000. Add both nodes (disabled by default) and the NPU power-domain
child under the PMU power-controller, and point rockchip,pmu at the PMU
syscon that controls the NPU NoC bus-idle.
Besides the SCMI compute clock, assign the CRU CLK_NPU so the NPU AXI
bus clock comes up at 200 MHz rather than the 12 MHz boot default.
The power-domain deliberately carries no pm_qos: qos_npu sits behind the
NPU NoC, which is gated until the NPU is brought up, so a genpd power-off
QoS save would fault reading it.
Signed-off-by: Midgy BALON <midgy971@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index 64bdd8b7754b5..313db59c1aed8 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
@@ -512,6 +512,13 @@ power-domain@RK3568_PD_GPU {
#power-domain-cells = <0>;
};
+ pd_npu: power-domain@RK3568_PD_NPU {
+ reg = <RK3568_PD_NPU>;
+ clocks = <&cru ACLK_NPU_PRE>,
+ <&cru HCLK_NPU_PRE>;
+ #power-domain-cells = <0>;
+ };
+
/* These power domains are grouped by VD_LOGIC */
power-domain@RK3568_PD_VI {
reg = <RK3568_PD_VI>;
@@ -572,6 +579,37 @@ power-domain@RK3568_PD_RKVENC {
};
};
+ rknn_core_0: npu@fde40000 {
+ compatible = "rockchip,rk3568-rknn-core";
+ reg = <0x0 0xfde40000 0x0 0x1000>,
+ <0x0 0xfde41000 0x0 0x1000>,
+ <0x0 0xfde43000 0x0 0x1000>;
+ reg-names = "pc", "cna", "core";
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_NPU>, <&cru HCLK_NPU>,
+ <&scmi_clk SCMI_CLK_NPU>, <&cru PCLK_NPU_PRE>;
+ clock-names = "aclk", "hclk", "npu", "pclk";
+ assigned-clocks = <&scmi_clk SCMI_CLK_NPU>, <&cru CLK_NPU>;
+ assigned-clock-rates = <200000000>, <600000000>;
+ resets = <&cru SRST_A_NPU>, <&cru SRST_H_NPU>;
+ reset-names = "srst_a", "srst_h";
+ power-domains = <&power RK3568_PD_NPU>;
+ rockchip,pmu = <&pmu>;
+ iommus = <&rknn_mmu_0>;
+ status = "disabled";
+ };
+
+ rknn_mmu_0: iommu@fde4b000 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xfde4b000 0x0 0x40>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "aclk", "iface";
+ clocks = <&cru ACLK_NPU>, <&cru HCLK_NPU>;
+ power-domains = <&power RK3568_PD_NPU>;
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
gpu: gpu@fde60000 {
compatible = "rockchip,rk3568-mali", "arm,mali-bifrost";
reg = <0x0 0xfde60000 0x0 0x4000>;
--
2.39.5
^ permalink raw reply related
* [RFC PATCH v4 8/9] arm64: dts: rockchip: rk3568-rock-3b: Enable the NPU
From: MidG971 @ 2026-06-13 7:01 UTC (permalink / raw)
To: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson
Cc: dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik,
jonas, Midgy BALON
In-Reply-To: <20260613070116.438906-1-midgy971@gmail.com>
From: Midgy BALON <midgy971@gmail.com>
Enable the NPU and its IOMMU on ROCK 3B and wire vdd_npu as the NPU
power domain's domain-supply, so genpd brings the rail up and down with
the domain (the domain is marked need_regulator). The PVTPLL compute
clock is brought up later by the driver.
The rail is no longer kept always-on, so pin it to 1000 mV (the NPU's
1 GHz operating voltage; the driver runs a fixed compute rate with no
devfreq voltage scaling) and mark it boot-on, so it is up before the
power domain de-idles the NPU NoC at power-on.
Signed-off-by: Midgy BALON <midgy971@gmail.com>
---
.../arm64/boot/dts/rockchip/rk3568-rock-3b.dts | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
index 69001e453732e..d3f9776c2bdc3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
@@ -330,9 +330,10 @@ regulator-state-mem {
vdd_npu: DCDC_REG4 {
regulator-name = "vdd_npu";
+ regulator-boot-on;
regulator-initial-mode = <0x2>;
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1350000>;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
regulator-ramp-delay = <6001>;
regulator-state-mem {
@@ -787,3 +788,16 @@ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
remote-endpoint = <&hdmi_in_vp0>;
};
};
+
+&pd_npu {
+ domain-supply = <&vdd_npu>;
+};
+
+&rknn_core_0 {
+ npu-supply = <&vdd_npu>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
--
2.39.5
^ permalink raw reply related
* [RFC PATCH v4 9/9] pmdomain: rockchip: Add a regulator to the RK3568 NPU power domain
From: MidG971 @ 2026-06-13 7:01 UTC (permalink / raw)
To: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson
Cc: dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik,
jonas, Midgy BALON
In-Reply-To: <20260613070116.438906-1-midgy971@gmail.com>
From: Midgy BALON <midgy971@gmail.com>
The RK3568 NPU rail (vdd_npu) needs to be enabled before the domain is
powered on and disabled after it is powered off. Give DOMAIN_RK3568 a
regulator parameter (like DOMAIN_RK3588 already has) so the NPU domain
can set need_regulator, letting genpd manage the rail wired up as the
domain's domain-supply instead of marking it always-on in DT.
Suggested-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Midgy BALON <midgy971@gmail.com>
---
drivers/pmdomain/rockchip/pm-domains.c | 36 ++++++++++++++++++--------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 490bbb1d1d8e8..19db307e3811d 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -138,6 +138,20 @@ struct rockchip_pmu {
.active_wakeup = wakeup, \
}
+#define DOMAIN_M_R(_name, pwr, status, req, idle, ack, wakeup, regulator) \
+{ \
+ .name = _name, \
+ .pwr_w_mask = (pwr) << 16, \
+ .pwr_mask = (pwr), \
+ .status_mask = (status), \
+ .req_w_mask = (req) << 16, \
+ .req_mask = (req), \
+ .idle_mask = (idle), \
+ .ack_mask = (ack), \
+ .active_wakeup = wakeup, \
+ .need_regulator = regulator, \
+}
+
#define DOMAIN_M_G(_name, pwr, status, req, idle, ack, g_mask, wakeup, keepon) \
{ \
.name = _name, \
@@ -241,8 +255,8 @@ struct rockchip_pmu {
#define DOMAIN_RK3562(name, pwr, req, g_mask, mem, wakeup) \
DOMAIN_M_G_SD(name, pwr, pwr, req, req, req, g_mask, mem, wakeup, false)
-#define DOMAIN_RK3568(name, pwr, req, wakeup) \
- DOMAIN_M(name, pwr, pwr, req, req, req, wakeup)
+#define DOMAIN_RK3568(name, pwr, req, wakeup, regulator) \
+ DOMAIN_M_R(name, pwr, pwr, req, req, req, wakeup, regulator)
#define DOMAIN_RK3576(name, p_offset, pwr, status, r_status, r_offset, req, idle, g_mask, wakeup) \
DOMAIN_M_O_R_G(name, p_offset, pwr, status, 0, r_status, r_status, r_offset, req, idle, idle, g_mask, wakeup)
@@ -1274,15 +1288,15 @@ static const struct rockchip_domain_info rk3562_pm_domains[] = {
};
static const struct rockchip_domain_info rk3568_pm_domains[] = {
- [RK3568_PD_NPU] = DOMAIN_RK3568("npu", BIT(1), BIT(2), false),
- [RK3568_PD_GPU] = DOMAIN_RK3568("gpu", BIT(0), BIT(1), false),
- [RK3568_PD_VI] = DOMAIN_RK3568("vi", BIT(6), BIT(3), false),
- [RK3568_PD_VO] = DOMAIN_RK3568("vo", BIT(7), BIT(4), false),
- [RK3568_PD_RGA] = DOMAIN_RK3568("rga", BIT(5), BIT(5), false),
- [RK3568_PD_VPU] = DOMAIN_RK3568("vpu", BIT(2), BIT(6), false),
- [RK3568_PD_RKVDEC] = DOMAIN_RK3568("vdec", BIT(4), BIT(8), false),
- [RK3568_PD_RKVENC] = DOMAIN_RK3568("venc", BIT(3), BIT(7), false),
- [RK3568_PD_PIPE] = DOMAIN_RK3568("pipe", BIT(8), BIT(11), false),
+ [RK3568_PD_NPU] = DOMAIN_RK3568("npu", BIT(1), BIT(2), false, true),
+ [RK3568_PD_GPU] = DOMAIN_RK3568("gpu", BIT(0), BIT(1), false, false),
+ [RK3568_PD_VI] = DOMAIN_RK3568("vi", BIT(6), BIT(3), false, false),
+ [RK3568_PD_VO] = DOMAIN_RK3568("vo", BIT(7), BIT(4), false, false),
+ [RK3568_PD_RGA] = DOMAIN_RK3568("rga", BIT(5), BIT(5), false, false),
+ [RK3568_PD_VPU] = DOMAIN_RK3568("vpu", BIT(2), BIT(6), false, false),
+ [RK3568_PD_RKVDEC] = DOMAIN_RK3568("vdec", BIT(4), BIT(8), false, false),
+ [RK3568_PD_RKVENC] = DOMAIN_RK3568("venc", BIT(3), BIT(7), false, false),
+ [RK3568_PD_PIPE] = DOMAIN_RK3568("pipe", BIT(8), BIT(11), false, false),
};
static const struct rockchip_domain_info rk3576_pm_domains[] = {
--
2.39.5
^ permalink raw reply related
* [RFC PATCH v4 6/9] dt-bindings: npu: rockchip,rk3588-rknn-core: Add RK3568
From: MidG971 @ 2026-06-13 7:01 UTC (permalink / raw)
To: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson
Cc: dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik,
jonas, Midgy BALON
In-Reply-To: <20260613070116.438906-1-midgy971@gmail.com>
From: Midgy BALON <midgy971@gmail.com>
The RK3568 carries a single core of the same NVDLA-derived NPU IP as the
RK3588. Add its compatible.
On RK3568 the NPU NoC bus-idle and power gating are controlled through the
system PMU rather than a dedicated register block, so add a rockchip,pmu
phandle to that syscon. The RK3568 NPU has no dedicated SRAM rail, so
sram-supply is required only on RK3588.
Signed-off-by: Midgy BALON <midgy971@gmail.com>
---
.../npu/rockchip,rk3588-rknn-core.yaml | 27 ++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
index caca2a4903cd1..e0b948ac47d45 100644
--- a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
+++ b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
@@ -21,6 +21,7 @@ properties:
compatible:
enum:
+ - rockchip,rk3568-rknn-core
- rockchip,rk3588-rknn-core
reg:
@@ -50,6 +51,13 @@ properties:
npu-supply: true
+ rockchip,pmu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the PMU syscon. On RK3568 the NPU's NoC bus-idle and
+ power gating are controlled through the PMU; this points to that
+ syscon so those registers can be reached.
+
power-domains:
maxItems: 1
@@ -75,7 +83,24 @@ required:
- resets
- reset-names
- npu-supply
- - sram-supply
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-rknn-core
+ then:
+ required:
+ - sram-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-rknn-core
+ then:
+ required:
+ - rockchip,pmu
additionalProperties: false
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v3 0/2] dt-bindings: mmc: st,sdhci: convert STMicroelectronics SDHCI-ST MMC/SD Controller controller binding to YAML
From: Charan Pedumuru @ 2026-06-13 7:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard, linux-mmc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <CAPx+jO9woUB9VGUx+ebWD9oOhqCwzXL9=41MEesnWS15Nyr66g@mail.gmail.com>
On 29-05-2026 17:40, Ulf Hansson wrote:
> On Fri, May 8, 2026 at 7:23 PM Charan Pedumuru
> <charan.pedumuru@gmail.com> wrote:
>>
>> This patch series converts the legacy text-based Device Tree binding for
>> STMicroelectronics SDHCI-ST MMC/SD controller to DT schema (YAML) format.
>>
>> Note:
>> The patch "dt-bindings: mmc: st,sdhci: convert to DT schema"
>> depends on the patch "arm: dts: st: align node patterns with established
>> convention". If the DT schema patch is applied before the DTS
>> cleanup patch, `dtbs_check` will fail due to the presence of the removed
>> properties in the existing DTS.
>>
>> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
>
> The series looks good to me, but awaiting and ack from some of the dt
> maintainers before applying.
Yeah, but until now they is no response from anyone.
>
> As the change in patch2 for arch/arm/boot/dts/st/stih407-family.dtsi
> doesn't seem to cause any conflict from soc maintainer trees point of
> view, I can pick this up too when applying.
Sure.
>
> Kind regards
> Uffe
>
>
>> ---
>> Changes in v3:
>> - st,sdhci: Edit description of reg property. Modify reg-names. Add
>> "minItems" for clocks and clock-names properties.
>> - Modify the commit message to match with the updated changes.
>> - Link to v2: https://patch.msgid.link/20260503-st-mmc-v2-0-11ae3216d2ce@gmail.com
>>
>> Changes in v2:
>> - Fix node name in DTS for the MMC to match with the estableshed convention.
>> - st,sdhci: drop unnecessary properties, modify "reg", "reg-names" and
>> "clock-names" properties, include an allOf with $ref to mmc-controller.
>> - Link to v1: https://patch.msgid.link/20260409-st-mmc-v1-1-4c54321c3535@gmail.com
>>
>> ---
>> Charan Pedumuru (2):
>> arm: dts: st: align node patterns with established convention
>> dt-bindings: mmc: st,sdhci: convert to DT schema
>>
>> Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
>> .../devicetree/bindings/mmc/st,sdhci.yaml | 91 +++++++++++++++++
>> arch/arm/boot/dts/st/stih407-family.dtsi | 4 +-
>> 3 files changed, 93 insertions(+), 112 deletions(-)
>> ---
>> base-commit: cf2cd8efd046c561191b8541d32a8bfe845bf06b
>> change-id: 20260327-st-mmc-c906ad95ff83
>>
>> Best regards,
>> --
>> Charan Pedumuru <charan.pedumuru@gmail.com>
--
Best Regards,
Charan.
^ permalink raw reply
* Re: [RFC PATCH v4 8/9] arm64: dts: rockchip: rk3568-rock-3b: Enable the NPU
From: Jonas Karlman @ 2026-06-13 7:40 UTC (permalink / raw)
To: MidG971
Cc: tomeu@tomeuvizoso.net, ogabbay@kernel.org, heiko@sntech.de,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
ulf.hansson@linaro.org, dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
xxm@rock-chips.com, chaoyi.chen@rock-chips.com,
finley.xiao@rock-chips.com, diederik@cknow-tech.com
In-Reply-To: <20260613070116.438906-9-midgy971@gmail.com>
Hi Midgy,
On 6/13/2026 9:01 AM, MidG971 wrote:
> From: Midgy BALON <midgy971@gmail.com>
>
> Enable the NPU and its IOMMU on ROCK 3B and wire vdd_npu as the NPU
> power domain's domain-supply, so genpd brings the rail up and down with
> the domain (the domain is marked need_regulator). The PVTPLL compute
> clock is brought up later by the driver.
>
> The rail is no longer kept always-on, so pin it to 1000 mV (the NPU's
> 1 GHz operating voltage; the driver runs a fixed compute rate with no
> devfreq voltage scaling) and mark it boot-on, so it is up before the
> power domain de-idles the NPU NoC at power-on.
>
> Signed-off-by: Midgy BALON <midgy971@gmail.com>
> ---
> .../arm64/boot/dts/rockchip/rk3568-rock-3b.dts | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> index 69001e453732e..d3f9776c2bdc3 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> @@ -330,9 +330,10 @@ regulator-state-mem {
>
> vdd_npu: DCDC_REG4 {
> regulator-name = "vdd_npu";
> + regulator-boot-on;
There is no need for the NPU in the bootloader, do not use DT as a
workaround for software issues.
This series mention the PVTPLL NPU clk and seem to contains some
workarounds related to how the PVTPLL clock is handled in TF-A.
The PVTPLL block typically require the pclk and power domain enabled to
function, and this series seem to add workarounds to try and ensure this,
e.g. with noc_init to activate PVTPLL usage.
I would suggest that you do not involve the PVTPLL clock in this initial
NPU support for RK3568, set CLK_NPU to 400 MHz and use it instead of the
SCMI clock, or keep SCMI clk rate less than or equal to 400 MHz to
disable PVTPLL_NEED mode in TF-A.
In a future series you can extend Linux with a proper PVTPLL clk driver
and OPP support for the rocket driver to correctly ensure pclk and pd is
enabled when a PVTPLL clock is managed.
> regulator-initial-mode = <0x2>;
> - regulator-min-microvolt = <500000>;
> - regulator-max-microvolt = <1350000>;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
Please describe the HW, do not add workarounds for software issues or
shortcomings.
Regards,
Jonas
> regulator-ramp-delay = <6001>;
>
> regulator-state-mem {
> @@ -787,3 +788,16 @@ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
> remote-endpoint = <&hdmi_in_vp0>;
> };
> };
> +
> +&pd_npu {
> + domain-supply = <&vdd_npu>;
> +};
> +
> +&rknn_core_0 {
> + npu-supply = <&vdd_npu>;
> + status = "okay";
> +};
> +
> +&rknn_mmu_0 {
> + status = "okay";
> +};
^ permalink raw reply
* Re: [PATCH] dmaengine: sun6i-dma: Fix use-after-free in error handling paths
From: Jernej Škrabec @ 2026-06-13 7:46 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, samuel, mripard, arnd, Hongling Zeng
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng
In-Reply-To: <20260611063631.96566-1-zenghongling@kylinos.cn>
Dne četrtek, 11. junij 2026 ob 08:36:31 Srednjeevropski poletni čas je Hongling Zeng napisal(a):
> In error handling paths, the for loop frees v_lli in the loop body,
> then accesses v_lli->v_lli_next and v_lli->p_lli_next in the
> increment expression, which is use-after-free.
>
> Fix by saving both the next virtual and physical pointers before
> freeing the current node.
>
> Fixes: 555859308723 ("dmaengine: Add driver for Allwinner sun6i DMA")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---
> drivers/dma/sun6i-dma.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a9a254dbf8cb..eb9c4ae87ac8 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -788,9 +788,15 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> + p_lli = txd->p_lli;
> + v_lli = txd->v_lli;
> + while (v_lli) {
> + struct sun6i_dma_lli *next_v_lli = v_lli->v_lli_next;
> + dma_addr_t next_p_lli = v_lli->p_lli_next;
> dma_pool_free(sdev->pool, v_lli, p_lli);
> + v_lli = next_v_lli;
> + p_lli = next_p_lli;
> + }
> kfree(txd);
> return NULL;
> }
> @@ -869,9 +875,15 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> + p_lli = txd->p_lli;
> + v_lli = txd->v_lli;
> + while (v_lli) {
> + struct sun6i_dma_lli *next_v_lli = v_lli->v_lli_next;
> + dma_addr_t next_p_lli = v_lli->p_lli_next;
> dma_pool_free(sdev->pool, v_lli, p_lli);
> + v_lli = next_v_lli;
> + p_lli = next_p_lli;
> + }
> kfree(txd);
> return NULL;
> }
>
This is certainly a valid fix, but it's replicating what sun6i_dma_free_desc()
is already doing. It would be better to split code to accept struct sun6i_desc
*txd parameter and call that instead from all places.
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH net-next v8 3/6] net: stmmac: eic7700: make RGMII delay properties optional
From: Andrew Lunn @ 2026-06-13 7:48 UTC (permalink / raw)
To: Maxime Chevallier
Cc: lizhi2, devicetree, andrew+netdev, davem, edumazet, kuba, robh,
krzk+dt, conor+dt, netdev, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, pjw, palmer, aou, alex, linux-riscv,
linux-stm32, linux-arm-kernel, linux-kernel, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, lee
In-Reply-To: <eaa645fc-be06-4a15-8c2f-6e82129c4715@bootlin.com>
On Wed, Jun 10, 2026 at 10:26:50AM +0200, Maxime Chevallier wrote:
> Hi,
>
> On 6/10/26 03:29, lizhi2@eswincomputing.com wrote:
> > From: Zhi Li <lizhi2@eswincomputing.com>
> >
> > Make rx-internal-delay-ps and tx-internal-delay-ps optional in the
> > EIC7700 DWMAC driver.
> >
> > The driver previously required both properties to be present and would
> > fail probe when they were missing. This restricts valid hardware
> > configurations where RGMII timing is instead provided by the PHY or
> > board design.
> >
> > Update the driver to treat missing delay properties as zero delay,
> > allowing systems without explicit MAC-side delay tuning to operate
> > correctly.
> >
> > This aligns the driver behavior with the updated device tree binding
> > and provides a safe default configuration when MAC-side delay
> > programming is not required.
> >
> > Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > index 4ac979d874d6..ec99b597aeaf 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > @@ -165,9 +165,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> > dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> > dwc_priv->eth_clk_dly_param |=
> > FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> > - } else {
> > - return dev_err_probe(&pdev->dev, -EINVAL,
> > - "missing required property rx-internal-delay-ps\n");
> > }
> >
> > /* Read tx-internal-delay-ps and update tx_clk delay */
> > @@ -187,9 +184,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> > dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> > dwc_priv->eth_clk_dly_param |=
> > FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> > - } else {
> > - return dev_err_probe(&pdev->dev, -EINVAL,
> > - "missing required property tx-internal-delay-ps\n");
> > }
>
> I think then you need to handle RGMII, RGMII_ID, RGMII_RXID and RGMII_TXID,
> by using default delays for these (usually around 2ns), as here all delays
> will be set to 0, regardless of the RGMII mode in use.
No. By default, the MAC adds 0ns delay, and passes the phy-mode to the
PHY. It will then add the 2ns delay. It is possible to use the
tx-internal-delay-ps and rx-internal-delay-ps in the MAC to add small
tuning delays, but not the full 2ns.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
Andrew
^ permalink raw reply
* Re: [PATCH] drm/sun4i: fix refcount leak in sun4i_backend_init_sat()
From: Jernej Škrabec @ 2026-06-13 7:50 UTC (permalink / raw)
To: wens, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
samuel, Wentao Liang
Cc: dri-devel, linux-arm-kernel, linux-sunxi, linux-kernel,
Wentao Liang, stable
In-Reply-To: <20260607030950.83636-1-vulab@iscas.ac.cn>
Dne nedelja, 7. junij 2026 ob 05:09:50 Srednjeevropski poletni čas je Wentao Liang napisal(a):
> When sun4i_backend_init_sat() calls reset_control_deassert() it
> increments the deassert_count of the reset controller, and must
> pair that with a reset_control_assert() call to decrement it.
> In the error path where clk_prepare_enable() fails, the function
> returns immediately without calling reset_control_assert(), leaking
> the reference count. Other error paths, like the devm_clk_get()
> failure, correctly jump to the err_assert_reset label which performs
> the missing assert.
>
> Fix the leak by using the existing err_assert_reset label in the
> clk_prepare_enable error path instead of returning directly.
>
> Cc: stable@vger.kernel.org
> Fixes: 440d2c7b127a ("drm/sun4i: backend: Handle the SAT")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 02/11] iio: adc: change from %ld to %pe for PTR_ERR() printing
From: Jernej Škrabec @ 2026-06-13 8:06 UTC (permalink / raw)
To: linux-iio, Vojtěch Krátký
Cc: Vojtěch Krátký, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Chen-Yu Tsai, Samuel Holland,
Sakari Ailus, Linus Walleij, Wolfram Sang, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260604120201.116925-3-vo.kratky@seznam.cz>
Dne četrtek, 4. junij 2026 ob 13:59:22 Srednjeevropski poletni čas je Vojtěch Krátký napisal(a):
> Replace numeric PTR_ERR() logging with the %pe format specifier
> so that error values are printed in a more readable form.
>
> This change was identified using a Coccinelle semantic patch.
>
> No functional change intended.
>
> Signed-off-by: Vojtěch Krátký <vo.kratky@seznam.cz>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH] net: correcting section tags for .init and .exit data/functions
From: kernel test robot @ 2026-06-13 8:05 UTC (permalink / raw)
To: xur, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Neal Cardwell, Kuniyuki Iwashima, Willem de Bruijn,
David Ahern, Ido Schimmel, Andreas Färber,
Manivannan Sadhasivam, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Maciej Żenczykowski,
Yue Haibing, Jeff Layton, Kees Cook, Fernando Fernandez Mancera,
Gustavo A. R. Silva, Sabrina Dubroca, Masahiro Yamada,
Nicolas Schier, linux-kernel, linux-arm-kernel, linux-actions
Cc: llvm, oe-kbuild-all, netdev
In-Reply-To: <20260612162257.896792-1-xur@google.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 2b414a95b8f7307d42173ba9e580d6d3e2bcbfce]
url: https://github.com/intel-lab-lkp/linux/commits/xur-google-com/net-correcting-section-tags-for-init-and-exit-data-functions/20260613-002737
base: 2b414a95b8f7307d42173ba9e580d6d3e2bcbfce
patch link: https://lore.kernel.org/r/20260612162257.896792-1-xur%40google.com
patch subject: [PATCH] net: correcting section tags for .init and .exit data/functions
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260613/202606131033.U9FHCI7B-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260613/202606131033.U9FHCI7B-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606131033.U9FHCI7B-lkp@intel.com/
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> WARNING: modpost: vmlinux: section mismatch in reference: tcpv6_init+0x68 (section: .text) -> mptcpv6_init (section: .init.text)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 1/7] arm64: defconfig: Enable Allwinner LRADC input driver
From: Jernej Škrabec @ 2026-06-13 8:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-2-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:15 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Enable Allwinner LRADC input driver as module to support buttons on Baijie
> HelperBoard A133.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej Skrabec
^ permalink raw reply
* Re: [RFC PATCH v4 7/9] arm64: dts: rockchip: rk356x: Add the NPU and its IOMMU
From: Jonas Karlman @ 2026-06-13 8:18 UTC (permalink / raw)
To: MidG971
Cc: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson,
dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik
In-Reply-To: <20260613070116.438906-8-midgy971@gmail.com>
Hi Midgy,
On 6/13/2026 9:01 AM, MidG971 wrote:
> From: Midgy BALON <midgy971@gmail.com>
>
> The RK3568 has an NVDLA-derived NPU at fde40000 with its own IOMMU at
> fde4b000. Add both nodes (disabled by default) and the NPU power-domain
> child under the PMU power-controller, and point rockchip,pmu at the PMU
> syscon that controls the NPU NoC bus-idle.
>
> Besides the SCMI compute clock, assign the CRU CLK_NPU so the NPU AXI
> bus clock comes up at 200 MHz rather than the 12 MHz boot default.
>
> The power-domain deliberately carries no pm_qos: qos_npu sits behind the
> NPU NoC, which is gated until the NPU is brought up, so a genpd power-off
> QoS save would fault reading it.
>
> Signed-off-by: Midgy BALON <midgy971@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> index 64bdd8b7754b5..313db59c1aed8 100644
> --- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> @@ -512,6 +512,13 @@ power-domain@RK3568_PD_GPU {
> #power-domain-cells = <0>;
> };
>
> + pd_npu: power-domain@RK3568_PD_NPU {
> + reg = <RK3568_PD_NPU>;
> + clocks = <&cru ACLK_NPU_PRE>,
> + <&cru HCLK_NPU_PRE>;
> + #power-domain-cells = <0>;
> + };
> +
> /* These power domains are grouped by VD_LOGIC */
> power-domain@RK3568_PD_VI {
> reg = <RK3568_PD_VI>;
> @@ -572,6 +579,37 @@ power-domain@RK3568_PD_RKVENC {
> };
> };
>
> + rknn_core_0: npu@fde40000 {
> + compatible = "rockchip,rk3568-rknn-core";
> + reg = <0x0 0xfde40000 0x0 0x1000>,
> + <0x0 0xfde41000 0x0 0x1000>,
> + <0x0 0xfde43000 0x0 0x1000>;
> + reg-names = "pc", "cna", "core";
> + interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_NPU>, <&cru HCLK_NPU>,
> + <&scmi_clk SCMI_CLK_NPU>, <&cru PCLK_NPU_PRE>;
> + clock-names = "aclk", "hclk", "npu", "pclk";
> + assigned-clocks = <&scmi_clk SCMI_CLK_NPU>, <&cru CLK_NPU>;
> + assigned-clock-rates = <200000000>, <600000000>;
This looks strange, the SCMI clk can be seen as a virtual clock that
changes between normal CRU NPU clk and a PVTPLL NPU clk (depending on
rate). 200 MHz, a typical opp-suspend value (switch to CRU clk instead
of PVTPLL), will set the CLK_NPU rate to 200 MHz, then setting CLK_NPU
to 600 MHz (the lowest rate that activates PVTPLL mode) outside of SCMI
control looks strange.
Suggest you only set SCMI NPU clk rate to 200 or 400 MHz and drop any
special handling, e.g. noc_init, to closer match RK3588 and defer any
use of PVTPLL clk to a future series that also adds OPP support.
> + resets = <&cru SRST_A_NPU>, <&cru SRST_H_NPU>;
> + reset-names = "srst_a", "srst_h";
> + power-domains = <&power RK3568_PD_NPU>;
> + rockchip,pmu = <&pmu>;
This looks wrong, the rockchip,pmu prop is typically used to reference
PMU GRF, see i.e. pinctrl node, not the power-management that is seem to
be correctly abstracted using power-domains above, please drop this prop.
Regards,
Jonas
> + iommus = <&rknn_mmu_0>;
> + status = "disabled";
> + };
> +
> + rknn_mmu_0: iommu@fde4b000 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xfde4b000 0x0 0x40>;
> + interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "aclk", "iface";
> + clocks = <&cru ACLK_NPU>, <&cru HCLK_NPU>;
> + power-domains = <&power RK3568_PD_NPU>;
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> gpu: gpu@fde60000 {
> compatible = "rockchip,rk3568-mali", "arm,mali-bifrost";
> reg = <0x0 0xfde60000 0x0 0x4000>;
^ permalink raw reply
* Re: [PATCH v4 5/7] arm64: dts: allwinner: a100: Add LRADC node
From: Jernej Škrabec @ 2026-06-13 8:20 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-6-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:19 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> A100/A133 SoCs feature a Low Rate ADC (LRADC) for Key application.
>
> Specs:
> - Power supply voltage: 1.8 V
> - Reference voltage: 1.35 V
> - Interrupt support
> - Support Hold Key and General Key
> - Support normal, continue and single work mode
> - 6-bits resolution, sample rate up to 2 kHz
> - Voltage input range between 0 and 1.35 V
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
> Changelog:
> v4:
> - added allwinner,sun50i-a100-lradc compatible
> v3:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index b3fb1e0ee796..7cb06b19b5a5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -466,6 +466,15 @@ ths: thermal-sensor@5070400 {
> #thermal-sensor-cells = <1>;
> };
>
> + lradc: lradc@5070800 {
> + compatible = "allwinner,sun50i-a100-lradc", "allwinner,sun50i-r329-lradc";
Break this into two lines, like usb_otg below. With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej Skrabec
> + reg = <0x05070800 0x400>;
> + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_LRADC>;
> + resets = <&ccu RST_BUS_LRADC>;
> + status = "disabled";
> + };
> +
> usb_otg: usb@5100000 {
> compatible = "allwinner,sun50i-a100-musb",
> "allwinner,sun8i-a33-musb";
>
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 8:22 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-7-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Add reserved-memory node carving out Trusted Firmware-A region spanning
> fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> itself passes the address range in the fdt to U-Boot, U-Boot currently
> only reserves this memory internally, but doesn't carve out the region
> in the fdt passed to Linux.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
NAK. It is job of boot procedure to properly inject TF-A reserved node.
Any issue should be fixed there.
Best regards,
Jernej Skrabec
> ---
> Changelog:
> v4:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index 7cb06b19b5a5..d8391663fd1d 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> #clock-cells = <0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /*
> + * 256 KiB reserved for Trusted Firmware-A (BL31).
> + * This is added by BL31 itself, but some bootloaders fail
> + * to propagate this into the DTB handed to kernels.
> + */
> + secmon@40000000 {
> + reg = <0x0 0x40000000 0x0 0x40000>;
> + no-map;
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <GIC_PPI 13
>
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix non-standard return value in airoha_ppe_get_wdma_info()
From: Lorenzo Bianconi @ 2026-06-13 8:27 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca3d9.ad59c0a6.147df9.2a62@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
> airoha_ppe_get_wdma_info() returns -1 when the last path in the
> forwarding path stack is not of type DEV_PATH_MTK_WDMA. This is not
> a standard kernel error code. Replace it with -EINVAL since the
> input path type is invalid from the caller's perspective.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_ppe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 5c9dff6..7260177 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -264,7 +264,7 @@ static int airoha_ppe_get_wdma_info(struct net_device *dev, const u8 *addr,
>
> path = &stack.path[stack.num_paths - 1];
> if (path->type != DEV_PATH_MTK_WDMA)
> - return -1;
> + return -EINVAL;
>
> info->idx = path->mtk_wdma.wdma_idx;
> info->bss = path->mtk_wdma.bss;
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix typos in comments and Kconfig
From: Lorenzo Bianconi @ 2026-06-13 8:30 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca74a.c5b1db4e.21a698.01e7@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
> Fix several typos found during code review:
> - Kconfig: "Aiorha" -> "Airoha" in NET_AIROHA_FLOW_STATS help text
> - Comment: "CMD1" -> "CDM1" (Central DMA, not Command)
> - Comments: "GMD1/2/3/4" -> "GDM1/2/3/4" (Gigabit DMA, not GMD)
>
> These are pure comment and documentation fixes with no functional impact.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/Kconfig | 2 +-
> drivers/net/ethernet/airoha/airoha_eth.c | 10 +++++-----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/Kconfig b/drivers/net/ethernet/airoha/Kconfig
> index ad3ce50..1f6640a 100644
> --- a/drivers/net/ethernet/airoha/Kconfig
> +++ b/drivers/net/ethernet/airoha/Kconfig
> @@ -29,6 +29,6 @@ config NET_AIROHA_FLOW_STATS
> bool "Airoha flow stats"
> depends on NET_AIROHA && NET_AIROHA_NPU
> help
> - Enable Aiorha flowtable statistic counters.
> + Enable Airoha flowtable statistic counters.
>
> endif #NET_VENDOR_AIROHA
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11..9d9d34a 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -294,18 +294,18 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
> FIELD_PREP(PSE_ALLRSV_MASK, all_rsv));
> }
>
> - /* CMD1 */
> + /* CDM1 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_CDM1]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_CDM1, q,
> PSE_QUEUE_RSV_PAGES);
> - /* GMD1 */
> + /* GDM1 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_GDM1]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM1, q,
> PSE_QUEUE_RSV_PAGES);
> - /* GMD2 */
> + /* GDM2 */
> for (q = 6; q < pse_port_num_queues[FE_PSE_PORT_GDM2]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM2, q, 0);
> - /* GMD3 */
> + /* GDM3 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_GDM3]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM3, q,
> PSE_QUEUE_RSV_PAGES);
> @@ -340,7 +340,7 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
> q, 0);
> }
> }
> - /* GMD4 */
> + /* GDM4 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_GDM4]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM4, q,
> PSE_QUEUE_RSV_PAGES);
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Alexander Sverdlin @ 2026-06-13 8:34 UTC (permalink / raw)
To: Jernej Škrabec, linux-arm-kernel, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <_6NEZ78hR8a_3V2bhBAGoQ@gmail.com>
Hi Jernej,
On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > only reserves this memory internally, but doesn't carve out the region
> > in the fdt passed to Linux.
> >
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
>
> NAK. It is job of boot procedure to properly inject TF-A reserved node.
> Any issue should be fixed there.
like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
? ;-)
> Best regards,
> Jernej Skrabec
>
> > ---
> > Changelog:
> > v4:
> > - new patch
> >
> > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > index 7cb06b19b5a5..d8391663fd1d 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > #clock-cells = <0>;
> > };
> >
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /*
> > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > + * This is added by BL31 itself, but some bootloaders fail
> > + * to propagate this into the DTB handed to kernels.
> > + */
> > + secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x40000>;
> > + no-map;
> > + };
> > + };
> > +
> > timer {
> > compatible = "arm,armv8-timer";
> > interrupts = <GIC_PPI 13
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix always-true condition in PPE1 queue reservation loop
From: Lorenzo Bianconi @ 2026-06-13 8:36 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca3de.ad59c0a6.147df9.2ac1@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
> In airoha_fe_pse_ports_init(), the inner condition for PPE1 queue
> reservation is identical to the for-loop bound, making it always true
> and the else branch dead code:
>
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_PPE1]; q++) {
> if (q < pse_port_num_queues[FE_PSE_PORT_PPE1]) /* always true */
> set RSV_PAGES;
> else
> set 0; /* unreachable */
> }
>
> The intended behavior is to reserve pages only for the first half of
> the queues, matching the PPE2 implementation on line 334 which
> correctly uses the /2 divisor. Fix the PPE1 condition accordingly.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11..999f517 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -311,7 +311,7 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
> PSE_QUEUE_RSV_PAGES);
> /* PPE1 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_PPE1]; q++) {
> - if (q < pse_port_num_queues[FE_PSE_PORT_PPE1])
> + if (q < pse_port_num_queues[FE_PSE_PORT_PPE1] / 2)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_PPE1, q,
> PSE_QUEUE_RSV_PAGES);
> else
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v2 1/1] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Lothar Rubusch @ 2026-06-13 8:52 UTC (permalink / raw)
To: Herbert Xu
Cc: thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, krzk+dt, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <aipAf_uZnX_gwZnl@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 6:59 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Jun 09, 2026 at 09:47:23AM +0000, Lothar Rubusch wrote:
> >
> > diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> > index 4c9af737b33a..20cd915ea8a3 100644
> > --- a/drivers/crypto/atmel-sha204a.c
> > +++ b/drivers/crypto/atmel-sha204a.c
> > @@ -31,10 +31,15 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
> > struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
> > struct hwrng *rng = areq;
> >
> > - if (status)
> > + if (status) {
> > dev_warn_ratelimited(&i2c_priv->client->dev,
> > "i2c transaction failed (%d)\n",
> > status);
> > + kfree(work_data);
> > + rng->priv = 0;
>
> Why is this necessary? It appears that rng_read_nonblocking already
> zeroes rng->priv.
>
IMHO this is not the same. The patch targets the error path. If the
`status` in `atmel_sha204a_rng_done()` is failed, then failed `work_data` is
still assigned and `rng->priv` is not zeroed at the moment. Only a
subsequent call to `rng_read_nonblocking()` will set `rng->priv = 0;`
The call order is something like this:
1. atmel_sha204a_init // module setup
2. atmel_sha204a_rng_read_nonblocking // call 1
3. atmel_sha204a_rng_done // if fail, still copies
work_data <-- patch clears here
...
4. atmel_sha204a_rng_read_nonblocking // call 2, clears rng->priv = 0
Originally this was a sashiko finding, when I move the RNG part into the
common driver. Reason: Actually all Atmel ECC and Atmel SHA204a devices
support the same RNG mech. Thus part of my refactoring is moving it to the
common core driver atmel_i2c. I was advised by the maintainer to use also
sashiko's feedback. So, I went on identifying sashiko issues and have a
look into it, if I can provide a fix for it. This is one of them.
Sashiko asked:
"If the I2C transaction fails here, we still assign the work_data to
rng->priv. Since kmalloc_obj() uses GFP_ATOMIC and does not zero memory,
does this risk leaking uninitialized slab memory or stale data from
previous reads when the next non-blocking read copies from
work_data->cmd.data?"
ref: https://sashiko.dev/#/patchset/20260512224349.64621-1-l.rubusch%40gmail.com
[search for `atmel_i2c_rng_done` on that link]
I'm not sure about the risk or the (real) severity sashiko mentiones
here. But it seems to
be correct, when atmel_sha204a_rng_done() fails in the status, it
continues assigning the
failed result in the work_data:
static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
void *areq, int status)
{
struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
struct hwrng *rng = areq;
if (status)
dev_warn_ratelimited(&i2c_priv->client->dev,
"i2c transaction failed (%d)\n",
status);
rng->priv = (unsigned long)work_data;
atomic_dec(&i2c_priv->tfm_count);
}
Hence, my proposed patch will stop it passing work_data, if status is
failed. It will not
assign rng->priv anymore then containing old data, but clear it. It
will free the `work_data`
to provoke a new allocation happening in `atmel_sha204a_rng_read_nonblocking()`.
The patch is sashiko and maintainer reviewed and solves sashikos complaints.
ref: https://sashiko.dev/#/patchset/20260609094723.47237-1-l.rubusch%40gmail.com
Setting `rng->priv = 0;` is rather safety here.
Thank you for asking. Accept, drop or modification needed - please,
leave me a note,
I'd highly appreciate.
Best,
L
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v8 next 04/10 Resend v2] arm_mpam: Refactor rmid to reqPARTID/PMG mapping
From: Zeng Heng @ 2026-06-13 8:59 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, Kefeng Wang, sunnanyong
In-Reply-To: <924fbfbc-995f-e291-8849-efcb8e01ef98@huawei.com>
Hi James,
>> @@ -478,6 +518,7 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
>> enum resctrl_conf_type cdp_type, u32 closid, u32 rmid, u64 *val)
>> {
>> struct mon_cfg cfg;
>> + u32 reqpartid = rmid2reqpartid(rmid);
>>
>> if (!mpam_is_enabled())
>> return -EINVAL;
>> @@ -493,8 +534,8 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
>> cfg = (struct mon_cfg) {
>> .mon = mon_idx,
>> .match_pmg = true,
>> - .partid = closid,
>> - .pmg = rmid,
>> + .partid = (cdp_type == CDP_CODE) ? reqpartid + 1 : reqpartid,
>> + .pmg = rmid2pmg(rmid),
>
> Not using the CLOSID here breaks multiple control groups.
>
After carefully reviewing your comments and Martin's patch series,
I tried to understand why there's insistence that CLOSID information
is necessary to support multiple control groups, but that's actually
not the case.
Before proceeding, allow me to introduce CPARTID (control partition ID,
no longer borrowing the intPARTID concept). All partids_per_closid
PARTIDs associated with it share the same control scheme under this
CPARTID.
Each PARTID within the partids_per_closid associated with a CPARTID is
called MPARTID (monitor partition ID, no longer borrowing the reqPARTID
concept). It refers to the PARTID used to represent different monitoring
groups under the same control scheme.
I've summarized the ID conversion diagrams from you and Martin as
follows:
+-------------------------+-----+------------------+
| CLOSID |{CDP}| RMID |
+-------------------------+-----+------------+-----+
| MPARTID | PMG |
+-------------------------------+------------+ |
| MPARTID_hi (base_partid) : MPARTID_lo | |
+-------------------------------+------------+-----+
Where (closid|cdp) = base_partid,
rmid = mpartid_lo * pmg_num + pmg,
and mpartid = base_partid * partids_per_closid + mpartid_lo,
with mpartid_lo in the range [0, partids_per_closid).
In this scheme, CLOSID and RMID are coupled together to form MPARTID,
which represents the monitor group PARTID.
In current patchset design, decoupling CLOSID and RMID, letting them
represent CPARTID and (MPARTID,PMG) pair respectively, rather than
having RMID depend on CLOSID to derive MPARTID. This decoupling is
essential for future dynamic allocation, because the relationship
between MPARTID and CPARTID must rely on table lookup rather than linear
mapping. If don't decouple in the static allocation design, we would
need another refactor when considering dynamic allocation extensibility.
+-------------------------------------------+-----+
| CLOSID |{CDP}|
+-------------------------------------------+-----+
| CPARTID (base_partid) |
+-------------------------------------------------+
+-----------------------------------+-----+-------+
| RMID_hi |{CDP}|RMID_lo|
+-----------------------------------+-----+-------+
| MPARTID | PMG |
+--------------+--------------------------+ |
| MPARTID_hi : MPARTID_lo (base_partid) | |
+--------------+--------------------------+-------+
Where (closid|cdp) = base_partid,
rmid_lo = pmg,
and (rmid_hi|cdp) = mpartid = mpartid_hi * (partid_num /
partids_per_closid) + base_partid,
with mpartid_hi in the range [0, partids_per_closid).
The reason of using base_partid as MPARTID_lo is to keep base_partid
contiguous and CLOSIDs are allocated contiguously. This does mean
MPARTIDs under the same CPARTID won't be contiguous, but that's
inherently difficult to guarantee with dynamic allocation anyway.
The control path uses CLOSID alone (CPARTID), and the monitor path uses
RMID alone (the (MPARTID, PMG) pair). This definition also aligns
closely with the native resctrl concepts: CLOSID (Class of Service ID,
corresponding to CPARTID) and RMID (Resource Monitor ID, corresponding
to the (MPARTID, PMG) pair).
In the end, the number of control groups is determined by the number of
CPARTIDs. Both of these ID translation schemes support multiple control
groups.
Could you please help outline the pros and cons of each approach?
This will determine which direction I take for subsequent iterations.
Thanks in advance.
Best Regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH net-next v5 1/3] net: airoha: use int instead of atomic_t for qdma users counter
From: Lorenzo Bianconi @ 2026-06-13 9:06 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-1-c11de08486d1@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3901 bytes --]
> QDMA users counter is always accessed holding RTNL lock so we do not
> require atomic_t for it.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 504247c8bae9..9eb9b6a139b3 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1812,7 +1812,7 @@ static int airoha_dev_open(struct net_device *netdev)
> airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
> - atomic_inc(&qdma->users);
> + qdma->users++;
>
> if (!airoha_is_lan_gdm_dev(dev) &&
> airoha_ppe_is_enabled(qdma->eth, 1))
> @@ -1866,7 +1866,7 @@ static int airoha_dev_stop(struct net_device *netdev)
> REG_GDM_FWD_CFG(port->id),
> FE_PSE_PORT_DROP);
>
> - if (atomic_dec_and_test(&qdma->users)) {
> + if (!--qdma->users) {
> airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
commenting on sashiko's report:
https://sashiko.dev/#/patchset/20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1%40kernel.org
- This is a pre-existing issue, but by not cleaning the TX queues when
qdma->users > 0, does this leave the stopped device's packets in flight?
When airoha_dev_stop() is called, it resets the device's BQL counters via
netdev_tx_reset_subqueue(). By skipping the cleanup when other devices are
still sharing this QDMA ring, any pending skbs originating from the stopped
device are left to linger in the hardware TX ring.
Because the hardware continues to process the shared ring on behalf of the
remaining interfaces, the active NAPI poll will process their completions in
airoha_qdma_tx_napi_poll():
if (skb) {
struct netdev_queue *txq;
txq = skb_get_tx_queue(skb->dev, skb);
netdev_tx_completed_queue(txq, 1, skb->len);
dev_kfree_skb_any(skb);
}
Can this cause an unsigned underflow in dql->num_queued since the BQL
state was already reset to 0 by ndo_stop?
- This issue is valid, but as pointed out by sashiko, this problem has not
been introduced by this patch. In particular, I think we should remove
netdev_tx_reset_subqueue() in airoha_dev_stop() and run
netdev_tx_completed_queue() in airoha_qdma_cleanup_tx_queue(). We need to
pay attention to not loop over already unregistered net_devices in
airoha_qdma_cleanup_tx_queue() run from airoha_remove().
I will post a dedicated patch for this issue.
- Also, if the device was being unregistered, unregister_netdev() frees the
netdev memory without waiting for TX skbs (which do not hold a reference to
dev). Could this lead to a use-after-free when dereferencing skb->dev here?
Should the driver selectively purge skbs belonging to the stopping netdev
from the shared TX ring before ndo_stop returns?
- I do not think this is a problem in the current codebase since the
net_devices are unregistered just during module unload running
airoha_remove() where we run airoha_qdma_stop_napi() to stop TX/RX NAPIs.
Regards,
Lorenzo
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 8f42973f9cf5..24fd8dcf7fca 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -526,7 +526,7 @@ struct airoha_qdma {
> struct airoha_eth *eth;
> void __iomem *regs;
>
> - atomic_t users;
> + int users;
>
> struct airoha_irq_bank irq_banks[AIROHA_MAX_NUM_IRQ_BANKS];
>
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] drivers: staging: media: sunxi: cedrus: add H616 variant
From: Jernej Škrabec @ 2026-06-13 9:33 UTC (permalink / raw)
To: wens
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, linux-media, linux-staging,
devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <CAGb2v64wDvLMFn9DYs-kH1S2PpHJat-imxR5eJSQAUYjOp=Xdg@mail.gmail.com>
Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > > The Allwinner H616 SoC has a video engine hardware block like the one
> > > found on previous generations such as the H6. In addition to the
> > > currently supported features of the H6, it is also supposed to include
> >
> > Remove "supposed".
>
> I can't actually verify that, so "supposed" is accurate from my point of
> view.
Isn't info from manual good enough?
In the interest of unblocking this, I would be fine with "supposed" too,
but manual and all my experiments show VP9 is supported.
Best regards,
Jernej
>
> ChenYu
>
> > > a VP9 decoder. However software support for this is currently missing
> > > and still needs to be reverse engineered from the vendor BSP.
> > >
> > > Add the compatible for the H616 variant, using the H6 variant data.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> >
> > With that:
> > Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> >
> > Best regards,
> > Jernej
> >
> >
>
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <b428d57ba5464f1226daf099877f4c25fa4fc191.camel@gmail.com>
Dne sobota, 13. junij 2026 ob 10:34:42 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Hi Jernej,
>
> On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> > Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > > only reserves this memory internally, but doesn't carve out the region
> > > in the fdt passed to Linux.
> > >
> > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> >
> > NAK. It is job of boot procedure to properly inject TF-A reserved node.
> > Any issue should be fixed there.
>
>
> like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
> ("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> ? ;-)
I was against that too.
It's time to be fixed in bootloader.
Best regards,
Jernej
>
> > Best regards,
> > Jernej Skrabec
> >
> > > ---
> > > Changelog:
> > > v4:
> > > - new patch
> > >
> > > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > index 7cb06b19b5a5..d8391663fd1d 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > > #clock-cells = <0>;
> > > };
> > >
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /*
> > > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > > + * This is added by BL31 itself, but some bootloaders fail
> > > + * to propagate this into the DTB handed to kernels.
> > > + */
> > > + secmon@40000000 {
> > > + reg = <0x0 0x40000000 0x0 0x40000>;
> > > + no-map;
> > > + };
> > > + };
> > > +
> > > timer {
> > > compatible = "arm,armv8-timer";
> > > interrupts = <GIC_PPI 13
>
>
^ permalink raw reply
* [PATCH v4 0/2] dt-bindings: mmc: st,sdhci: convert STMicroelectronics SDHCI-ST MMC/SD Controller controller binding to YAML
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
This patch series converts the legacy text-based Device Tree binding for
STMicroelectronics SDHCI-ST MMC/SD controller to DT schema (YAML) format.
Note:
The patch "dt-bindings: mmc: st,sdhci: convert to DT schema"
depends on the patch "arm: dts: st: align node patterns with established
convention". If the DT schema patch is applied before the DTS
cleanup patch, `dtbs_check` will fail due to the presence of the removed
properties in the existing DTS.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v4:
- st,sdhci: Add minItems: 1 to clock-names and reg-names to allow single-entry
configurations, fixing dtbs_check failures on nodes that omit the
optional 'icn' clock or 'top-mmc-delay' register region.
- st,sdhci: Modify the commit message to explain the changes.
- Link to v3: https://patch.msgid.link/20260508-st-mmc-v3-0-81c329ed28e8@gmail.com
Changes in v3:
- st,sdhci: Edit description of reg property. Modify reg-names. Add
"minItems" for clocks and clock-names properties.
- Modify the commit message to match with the updated changes.
- Link to v2: https://patch.msgid.link/20260503-st-mmc-v2-0-11ae3216d2ce@gmail.com
Changes in v2:
- Fix node name in DTS for the MMC to match with the estableshed convention.
- st,sdhci: drop unnecessary properties, modify "reg", "reg-names" and
"clock-names" properties, include an allOf with $ref to mmc-controller.
- Link to v1: https://patch.msgid.link/20260409-st-mmc-v1-1-4c54321c3535@gmail.com
---
Charan Pedumuru (2):
arm: dts: st: align node patterns with established convention
dt-bindings: mmc: st,sdhci: Convert to DT schema
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 92 +++++++++++++++++
arch/arm/boot/dts/st/stih407-family.dtsi | 4 +-
3 files changed, 94 insertions(+), 112 deletions(-)
---
base-commit: cf2cd8efd046c561191b8541d32a8bfe845bf06b
change-id: 20260327-st-mmc-c906ad95ff83
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ 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