* [PATCH 0/7] media: rkvdec: Enable multi-core support
From: Detlev Casanova @ 2026-04-09 13:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Ezequiel Garcia, Heiko Stuebner,
Nicolas Dufresne, Hans Verkuil, Jonas Karlman
Cc: kernel, linux-media, linux-kernel, linux-rockchip,
linux-arm-kernel, Detlev Casanova
Since the driver is used for decoding on rk3588 and that the SoC has
2 identical decoding cores, enable support for it.
Instead of exposing 2 v4l2 devices to userspace, the driver will only
expose one and handle the 2 cores transparently.
The 2 cores are able to work in parallel, but only contexts are
parallelized: 1 stream, that uses 1 context, will only be able to use
1 core as it usually needs previous frames already decoded to use as
reference frames.
To avoid complex scheduling, only different streams can use cores at the
same time.
To achieve this, the v4l2_m2m_buf_done_and_job_finish() had to be split
in a done and a finish part (still keeping the unsplit function for other
drivers). That allows the driver to get new jobs to run while the previous
one is still running.
The job_ready() callback is used to avoid scheduling multiple jobs from
the same context.
The IOMMU support is in a different commit, as it needed a bit more
thought to work correctly, but I'm wondering if it should be merged with
the multicore support commit.
A fix for the RCB (Row and Cols Buffer) size computation is also provided
as it was causing issues with some fluster tests.
Performance-wise, fluster doesn't seem to run much faster, but I tested
with an HEVC test video from Jellyfin and observed that frames start
dropping with 6 concurrent gstreamer instances, instead of 4 without
multi-core enabled.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
Detlev Casanova (7):
media: v4l2-mem2mem: Add v4l2_m2m_buf_done_manual()
media: v4l2-mem2mem: Remove WARN_ON() in v4l2_m2m_job_finish()
media: rkvdec: Keep RCB to the correct size
media: rkvdec: Remove unused need_reset
media: rkvdec: Add multicore support
media: rkvdec: Wait for all buffers before stop_streaming
media: rkvdec: Add multicore IOMMU support
.../media/platform/rockchip/rkvdec/rkvdec-h264.c | 17 +-
.../media/platform/rockchip/rkvdec/rkvdec-hevc.c | 16 +-
.../media/platform/rockchip/rkvdec/rkvdec-rcb.c | 77 ++--
.../media/platform/rockchip/rkvdec/rkvdec-rcb.h | 8 +-
.../platform/rockchip/rkvdec/rkvdec-vdpu381-h264.c | 24 +-
.../platform/rockchip/rkvdec/rkvdec-vdpu381-hevc.c | 24 +-
.../platform/rockchip/rkvdec/rkvdec-vdpu383-h264.c | 24 +-
.../platform/rockchip/rkvdec/rkvdec-vdpu383-hevc.c | 26 +-
.../media/platform/rockchip/rkvdec/rkvdec-vp9.c | 27 +-
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 482 +++++++++++++--------
drivers/media/platform/rockchip/rkvdec/rkvdec.h | 31 +-
drivers/media/v4l2-core/v4l2-mem2mem.c | 34 +-
include/media/v4l2-mem2mem.h | 20 +
13 files changed, 500 insertions(+), 310 deletions(-)
---
base-commit: 3036cd0d3328220a1858b1ab390be8b562774e8a
change-id: 20260408-rkvdec-multicore-98831da51072
Best regards,
--
Detlev Casanova <detlev.casanova@collabora.com>
^ permalink raw reply
* Re: [PATCH 2/3] KVM: arm64: vgic: Allow userspace to set IIDR revision 1
From: Marc Zyngier @ 2026-04-09 13:45 UTC (permalink / raw)
To: Woodhouse, David
Cc: kvm@vger.kernel.org, shuah@kernel.org, yuzenghui@huawei.com,
joey.gouly@arm.com, linux-kernel@vger.kernel.org,
catalin.marinas@arm.com, nathan@kernel.org, pbonzini@redhat.com,
kvmarm@lists.linux.dev, arnd@arndb.de, kees@kernel.org,
will@kernel.org, suzuki.poulose@arm.com, oupton@kernel.org,
rananta@google.com, linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org, eric.auger@redhat.com
In-Reply-To: <ffe9de5106d999365389c3ab17f357409dac1047.camel@amazon.co.uk>
On Wed, 08 Apr 2026 09:39:15 +0100,
"Woodhouse, David" <dwmw@amazon.co.uk> wrote:
>
> [1 <multipart/signed (en-US) (7bit)>]
> [1.1 <text/plain; UTF-8 (quoted-printable)>]
> On Wed, 2026-04-08 at 08:54 +0100, Marc Zyngier wrote:
> > On Tue, 07 Apr 2026 21:27:03 +0100,
> > David Woodhouse <dwmw2@infradead.org> wrote:
> > >
> > > From: David Woodhouse <dwmw@amazon.co.uk>
> > >
> > > Allow userspace to select GICD_IIDR revision 1, which restores the
> > > original pre-d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration
> > > of interrupt groups") behaviour where interrupt groups are not
> > > guest-configurable.
> >
> > I'm a bit surprised by this.
> >
> > Either your guest knows that the group registers are not writable and
> > already deals with the buggy behaviour by not configuring the groups
> > (or configuring them in a way that matches what the implementation
> > does). Or it configures them differently and totally fails to handle
> > the interrupts as they are delivered using the wrong exception type,
> > if at all.
> >
> > I'd expect that your guests fall in the former category and not the
> > latter, as we'd be discussing a very different problem. And my vague
> > recollection of this issue is that we had established that as long as
> > the reset values were unchanged, there was no harm in letting things
> > rip.
>
> What if the guest boots under a new host kernel and finds the group
> registers are writable, and then is live migrated to an old host kernel
> on which they are not?
That's your problem. KVM/arm64 never supported downgrading.
Not to mention that there is no valid GIC implementation that has RO
group registers. All you are doing is to inflict a hypervisor bug on
unsuspecting guests, for no good reason.
> What about hibernation, if the *boot* kernel in the guest configures
> the groups, but then transfers control back to the resumed guest kernel
> which had not?
A guest that doesn't configures the groups cannot expect anything to
work. You'd have the exact same problem on bare-metal.
>
> > So what is this *really* fixing?
>
> I look at that question the other way round.
>
> KVM has an established procedure for allowing userspace to control
> guest-visible changes, using the IIDR. First the host kernel which
> *supports* the change is rolled out, and only then does the VMM start
> to enable it for new launches.
>
> Even if we can address the questions above, and even if we can convince
> ourselves that those are the *only* questions to ask... why not follow
> the normal, safe, procedure? Especially given that there is already an
> IIDR value which corresponds to it.
>
> We don't *have* to YOLO it... and I don't want to :)
That's hardly an argument, is it?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v7 7/7] KVM: arm64: Normalize cache configuration
From: Marc Zyngier @ 2026-04-09 13:36 UTC (permalink / raw)
To: David Woodhouse
Cc: akihiko.odaki, Gutierrez Cantu, Bernardo, alexandru.elisei,
alyssa, asahi, broonie, catalin.marinas, james.morse, kvmarm,
kvmarm, linux-arm-kernel, linux-kernel, marcan, mathieu.poirier,
oliver.upton, suzuki.poulose, sven, will
In-Reply-To: <b71910e202ac4a56a87c0e34df13cce058d46a76.camel@infradead.org>
On Thu, 09 Apr 2026 13:25:24 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 12 Jan 2023 at 11:38:52 +0900, Akihiko Odaki wrote:
> > Before this change, the cache configuration of the physical CPU was
> > exposed to vcpus. This is problematic because the cache configuration a
> > vcpu sees varies when it migrates between vcpus with different cache
> > configurations.
> >
> > Fabricate cache configuration from the sanitized value, which holds the
> > CTR_EL0 value the userspace sees regardless of which physical CPU it
> > resides on.
> >
> > CLIDR_EL1 and CCSIDR_EL1 are now writable from the userspace so that
> > the VMM can restore the values saved with the old kernel.
>
> (commit 7af0c2534f4c5)
>
> How does the VMM set the values that the old kernel would have set?
By reading them at the source?
> Let's say we're deploying a kernel with this change for the first time,
> and we need to ensure that we provide a consistent environment to
> guests, which can be live migrated back to an older host.
We have never guaranteed host downgrade. It almost never works.
> So for new launches, we need to provide the values that the old kernel
> *would* have provided to the guest. A new launch isn't a migration;
> there are no "values saved with the old kernel".
And you can provide these values.
>
> Userspace can't read the CLIDR_EL1 and CCSIDR_EL1 registers directly,
> and AFAICT not everything we need to reconstitute them is in sysfs. How
> is this supposed to work?
>
> Shouldn't this change have been made as a capability that the VMM can
> explicitly opt in or out of? Environments that don't do cross-CPU
> migration absolutely don't care about, and actively don't *want*, the
> sanitisation that this commit inflicted on us, surely?
I don't think a capability buys you anything. You want to expose
something to the guest? Make it so. You are in the favourable
situation to completely own the HW and the VMM.
The stuff we are allowing the VMM to change are not directly relevant
to the guest anyway (set/way per cache levels...), and were only
actively breaking things.
> Am I missing something?
That you had over 3 years to voice your concern, and did nothing?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
From: Daniel Golle @ 2026-04-09 13:35 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Wunderlich, linux-kernel,
linux-arm-kernel, linux-mediatek, devicetree, Andrew LaMarche
In-Reply-To: <20260409131754.121737-3-linux@fw-web.de>
On Thu, Apr 09, 2026 at 03:17:50PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
>
> On the official case the red LED is named ERR, the blue LED is named ACT.
> Reflect these labels in function and set them default off.
>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> .../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> index 759f608d1081..7f770a76775a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> @@ -61,14 +61,16 @@ gpio-leds {
>
> led_red: sys-led-red {
> color = <LED_COLOR_ID_RED>;
> + function = LED_FUNCTION_FAULT;
> gpios = <&pca9555 15 GPIO_ACTIVE_HIGH>;
> - default-state = "on";
> + default-state = "off";
Just drop 'default-state' entirely from both nodes.
> };
>
> led_blue: sys-led-blue {
> color = <LED_COLOR_ID_BLUE>;
> + function = LED_FUNCTION_ACTIVITY;
> gpios = <&pca9555 14 GPIO_ACTIVE_HIGH>;
> - default-state = "on";
> + default-state = "off";
> };
> };
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-04-09 13:35 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <75d22f54-eb55-4e55-9582-5b407f41ee81@quicinc.com>
On Thu, Apr 09, 2026 at 11:14:10AM +0530, Ayushi Makhija wrote:
> On 3/26/2026 9:28 PM, Bjorn Andersson wrote:
> > On Thu, Mar 26, 2026 at 03:06:52PM +0530, Ayushi Makhija wrote:
> >> On 3/24/2026 7:34 AM, Bjorn Andersson wrote:
> >>> On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
> >>>> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> >>>> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
> >>>>
> >>>
> >>> Please add Fixes: tag.
> >>>
> >>
> >> Hi Bjorn,
> >>
> >> Sure, will add in new patchset.
> >>
> >>>> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
> >>>
> >>> Please start using your oss.qualcomm.com address.
> >>>
> >>>> ---
> >>>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >>>> index 3837f6785320..6ba4e69bf377 100644
> >>>> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >>>> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >>>> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
> >>>>
> >>>> vreg_l12b_1p8: ldo12 {
> >>>> regulator-name = "vreg_l12b_1p8";
> >>>> - regulator-min-microvolt = <1200000>;
> >>>> + regulator-min-microvolt = <1650000>;
> >>>
> >>> Are you sure it's not supposed to be 1.8V, given the name of the rail?
> >>>
> >>> Regards,
> >>> Bjorn
> >>
> >> There was already discussion regarding the minimum voltage for this regulator on sm8550 target
> >> on other upstream patch.
> >>
> >> Link: https://lore.kernel.org/all/aQQdQoCLeKhYtY7W@yuanjiey.ap.qualcomm.com/
> >>
> >> This values is according to the NT37801 panel sec
> >> "The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> >> VDDI=1.65V~1.95V."
> >>
> >
> > Yes, so the panel requires 1.65V, so regulator-min-microvolt needs to be
> > at least that. But regulator-min-microvolt should account for all the
> > consumers of the rail, are there any others?
> >
> > Which leads me to my question, the people designing the board named the
> > rail VREG_L12B_1P8 in the schematics, why didn't they name it
> > VREG_L12B_1P65?
> >
> > Please check all the consumers and make the regulator-min-microvolt work
> > for all of them - if that's 1.65V, then your change is good.
> >
> > Regards,
> > Bjorn
>
> Hi Bjorn,
>
> There is only one consumer of VREG_L12B_1P8 rail, i.e. NT37801 panel.
> So regulator-min-microvolt as 1.65V should be fine for VREG_L12B_1P8 rail.
>
Had to look it up myself. MTP power grid says it should be 1.8V.
Thank you,
Bjorn
> Thanks,
> Ayushi
>
^ permalink raw reply
* [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Frank Wunderlich @ 2026-04-09 13:33 UTC (permalink / raw)
To: Alexander Couzens, Daniel Golle, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthias Brugger, AngeloGioacchino Del Regno,
Vladimir Oltean
Cc: Frank Wunderlich, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
From: Frank Wunderlich <frank-w@public-files.de>
Commit 8871389da151 introduces common pcs dts properties which writes
rx=normal,tx=normal polarity to register SGMSYS_QPHY_WRAP_CTRL of switch.
This is initialized with tx-bit set and so change inverts polarity
compared to before.
It looks like mt7531 has tx polarity inverted in hardware and set tx-bit
by default to restore the normal polarity.
Till this patch the register write was only called when mediatek,pnswap
property was set which cannot be done for switch because the fw-node param
was always NULL from switch driver in the mtk_pcs_lynxi_create call.
Do not configure switch side like it's done before.
Fixes: 8871389da151 ("net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
drivers/net/pcs/pcs-mtk-lynxi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/pcs/pcs-mtk-lynxi.c b/drivers/net/pcs/pcs-mtk-lynxi.c
index c12f8087af9b..a753bd88cbc2 100644
--- a/drivers/net/pcs/pcs-mtk-lynxi.c
+++ b/drivers/net/pcs/pcs-mtk-lynxi.c
@@ -129,6 +129,9 @@ static int mtk_pcs_config_polarity(struct mtk_pcs_lynxi *mpcs,
unsigned int val = 0;
int ret;
+ if (!fwnode)
+ return 0;
+
if (fwnode_property_read_bool(fwnode, "mediatek,pnswap"))
default_pol = PHY_POL_INVERT;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] media: cedrus: skip invalid H.264 reference list entries
From: Paul Kocialkowski @ 2026-04-09 13:33 UTC (permalink / raw)
To: Pengpeng Hou
Cc: mripard, mchehab, gregkh, wens, jernej.skrabec, samuel,
nicolas.dufresne, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260324080856.56787-1-pengpeng@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]
Hi,
On Tue 24 Mar 26, 16:08, Pengpeng Hou wrote:
> 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.
Could you explain why it is legitimate that userspace would pass indices that
are not in the dpb list? As far as I remember from the H.264 spec, the L0/L1
lists are constructed from active references only and the number of items there
should be given by num_ref_idx_l0_active_minus1/num_ref_idx_l1_active_minus1.
We can tolerate invalid data beyond these indices, but certainly not as part
of the indices that should be valid.
However I agree that cedrus_try_ctrl is maybe not the right place to check it
since I'm not sure we are guaranteed that the slice params control will be
checked before the new DPB (from the same request) is applied, so we might end
up checking against the dpb from the previous decode request.
But I think we should error out and not just skip the invalid reference.
All the best,
Paul
>
> 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>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> @@ -210,6 +210,9 @@ static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> u8 dpb_idx;
>
> dpb_idx = ref_list[i].index;
> + if (dpb_idx >= V4L2_H264_NUM_DPB_ENTRIES)
> + continue;
> +
> dpb = &decode->dpb[dpb_idx];
>
> if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
> --
> 2.50.1
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1] phy: rockchip-snps-pcie3:phy: Configure clkreq_n and PowerDown for all lanes
From: Anand Moon @ 2026-04-09 13:30 UTC (permalink / raw)
To: Niklas Cassel
Cc: Shawn Lin, Vinod Koul, Neil Armstrong, Heiko Stuebner,
open list:GENERIC PHY FRAMEWORK,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list
In-Reply-To: <add2QFfHd5Jv9XU7@fedora>
Hi Niklas,
Thanks for your review comments.
On Thu, 9 Apr 2026 at 15:19, Niklas Cassel <cassel@kernel.org> wrote:
>
> +Shawn
>
> Hello Anand,
>
> On Thu, Apr 09, 2026 at 10:19:30AM +0530, Anand Moon wrote:
> > During the rk3588_p3phy_init sequence, the driver now explicitly
>
> Please use imperative mood, active voice.
>
>
> > configures each lane's CON0 register to ensure
> > - PIPE 4.3 Compliance: clkreq_n (bit 6) is forced low (asserted) to meet
> > sideband signal requirements.
> > - Active Power State: PowerDown[3:0] (bits 11:8) is set to P0
> > (Normal Operational State) to ensure the PHY is fully powered and ready
> > for link training.
> >
> > These changes ensure that all lanes are consistently transitioned from
> > reset into a known-good operational state, preventing undefined behavior
> > and ensuring the PHY is ready for high-speed data transmission.
>
Ok, I will update this.I f
> First describe the problem, then describe how you fix it.
I was investigating the PCIE30X4_CLKREQn issue highlighted by Shawn Lin,
analyzing the RK3588 TRM clock request configurations (page 878)
[1] https://lore.kernel.org/all/77f0d3c2-649f-770d-1636-6fd52f3b5f5e@rock-chips.com/
Looking into the power management state on Intel’s PCI Express Power Management
documentation, which defines states such as P0, P0s, P1, P1.1, P1.2, and P2
Understanding this mapping is for interpreting the behavior of lane-specific
clock requests, so initialize this to the P0 state..
[2] https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/phy-interface-pci-express-sata-usb30-architectures-3.1.pdf
>
>
> Kind regards,
> Niklas
Thanks
-Anand
^ permalink raw reply
* [PATCH v1 2/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260409131754.121737-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
On the official case the red LED is named ERR, the blue LED is named ACT.
Reflect these labels in function and set them default off.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 759f608d1081..7f770a76775a 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -61,14 +61,16 @@ gpio-leds {
led_red: sys-led-red {
color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_FAULT;
gpios = <&pca9555 15 GPIO_ACTIVE_HIGH>;
- default-state = "on";
+ default-state = "off";
};
led_blue: sys-led-blue {
color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_ACTIVITY;
gpios = <&pca9555 14 GPIO_ACTIVE_HIGH>;
- default-state = "on";
+ default-state = "off";
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/3] some BPI-R4Pro dts updates
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
From: Frank Wunderlich <frank-w@public-files.de>
There are some parts of BPI-R4Pro DTS that need to be changed. Currently
there should be not much users of the mainline-dts and we noticed some
things while openwrt integration.
Frank Wunderlich (3):
arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
arch/arm64/boot/dts/mediatek/Makefile | 8 ++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn13.dtso | 20 +++++++++++++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn14.dtso | 20 +++++++++++++++++++
.../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 15 ++++----------
4 files changed, 52 insertions(+), 11 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
--
2.43.0
^ permalink raw reply
* [PATCH v1 3/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260409131754.121737-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
The active-high property in base-dt cannot be overwritten and must be
set in separate overlay.
Fixes: f397471a6a8c ("arm64: dts: mediatek: mt7988: Add devicetree for BananaPi R4 Pro")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
arch/arm64/boot/dts/mediatek/Makefile | 8 ++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn13.dtso | 20 +++++++++++++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn14.dtso | 20 +++++++++++++++++++
.../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 2 --
4 files changed, 48 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 387faa9c2a09..a86fb313b1a9 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -47,6 +47,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-emmc.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-4e.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn13.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn14.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
@@ -70,18 +72,24 @@ mt7988a-bananapi-bpi-r4-2g5-sd-dtbs := \
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5-sd.dtb
mt7988a-bananapi-bpi-r4-pro-8x-emmc-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-emmc.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-sd.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8167-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
new file mode 100644
index 000000000000..973b76ba0cbf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN13 on pcie2(11280000 1L0) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-2-hog} {
+ output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
new file mode 100644
index 000000000000..90b2a64459c3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN14 on pcie3(11290000 1L1) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-3-hog} {
+ output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 7f770a76775a..5c5d4e26aa56 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -432,14 +432,12 @@ mux {
pcie-2-hog {
gpio-hog;
gpios = <79 GPIO_ACTIVE_HIGH>;
- output-high;
};
/* 1L1 0=key-b (CN18), 1=key-m (CN14) */
pcie-3-hog {
gpio-hog;
gpios = <63 GPIO_ACTIVE_HIGH>;
- output-high;
};
pwm0_pins: pwm0-pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260409131754.121737-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
These properties are already set in the original node and do not need
to be defined again.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 1175ee156cb3..759f608d1081 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -185,13 +185,6 @@ ð {
status = "okay";
};
-&fan {
- pinctrl-0 = <&pwm0_pins>;
- pinctrl-names = "default";
- pwms = <&pwm 0 50000>;
- status = "okay";
-};
-
&gmac0 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device
From: Suzuki K Poulose @ 2026-04-09 13:14 UTC (permalink / raw)
To: James Clark, Leo Yan
Cc: coresight, linux-arm-kernel, Yeoreum Yun, Mark Rutland,
Will Deacon, Yabin Cui, Keita Morisaki, Yuanfang Zhang,
Greg Kroah-Hartman, Alexander Shishkin, Tamas Petz,
Thomas Gleixner, Peter Zijlstra, Mike Leach
In-Reply-To: <e7c6f497-f8f0-409b-b80a-a064b222c08d@linaro.org>
On 09/04/2026 11:52, James Clark wrote:
>
>
> On 05/04/2026 4:02 pm, Leo Yan wrote:
>> Unlike system level sinks, per-CPU sinks may lose power during CPU idle
>> states. Currently, this applies specifically to TRBE. This commit
>> invokes save and restore callbacks for the sink in the CPU PM notifier.
>>
>> If the sink provides PM callbacks but the source does not, this is
>> unsafe because the sink cannot be disabled safely unless the source
>> can also be controlled, so veto low power entry to avoid lockups.
>>
>> Tested-by: James Clark <james.clark@linaro.org>
>> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> Reviewed-by: James Clark <james.clark@linaro.org>
>> Signed-off-by: Leo Yan <leo.yan@arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 46 ++++++++++++++++++
>> ++++++++--
>> 1 file changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/
>> hwtracing/coresight/coresight-core.c
>> index
>> c1e8debc76aba7eb5ecf7efe2a3b9b8b3e11b10c..a918bf6398a932de30fe9b4947020cc4c1cfb2f7 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -1736,14 +1736,15 @@ static void coresight_release_device_list(void)
>> /* Return: 1 if PM is required, 0 if skip, <0 on error */
>> static int coresight_pm_check(struct coresight_path *path)
>> {
>> - struct coresight_device *source;
>> - bool source_has_cb;
>> + struct coresight_device *source, *sink;
>> + bool source_has_cb, sink_has_cb;
>> if (!path)
>> return 0;
>> source = coresight_get_source(path);
>> - if (!source)
>> + sink = coresight_get_sink(path);
>> + if (!source || !sink)
>> return 0;
>> /* Don't save and restore if the source is inactive */
>> @@ -1759,16 +1760,36 @@ static int coresight_pm_check(struct
>> coresight_path *path)
>> if (source_has_cb)
>> return 1;
>> + sink_has_cb = coresight_ops(sink)->pm_save_disable &&
>> + coresight_ops(sink)->pm_restore_enable;
>> + /*
>> + * It is not permitted that the source has no callbacks while the
>> sink
>> + * does, as the sink cannot be disabled without disabling the
>> source,
>> + * which may lead to lockups. Alternatively, the ETM driver should
>> + * enable self-hosted PM mode at probe (see etm4_probe()).
>> + */
>> + if (sink_has_cb) {
>> + pr_warn_once("coresight PM failed: source has no PM callbacks; "
>> + "cannot safely control sink\n");
>
> This prints out on my Orion board on a fresh boot because of how
> pm_save_enable is setup there. Do we really need the configuration of
> pm_save_enable for ETE/TRBE if we know that it always needs saving?
>
> It also stops warning if I rmmod and modprobe the module after booting.
> Seems like pm_save_enable is different depending on how the module is
> loaded which doesn't seem right.
Thats because the warning is pr_warn_*once*()
Suzuki
>
>> + return -EINVAL;
>> + }
>> +
>> return 0;
>> }
>> static int coresight_pm_device_save(struct coresight_device *csdev)
>> {
>> + if (!csdev || !coresight_ops(csdev)->pm_save_disable)
>> + return 0;
>> +
>> return coresight_ops(csdev)->pm_save_disable(csdev);
>> }
>> static void coresight_pm_device_restore(struct coresight_device *csdev)
>> {
>> + if (!csdev || !coresight_ops(csdev)->pm_restore_enable)
>> + return;
>> +
>> coresight_ops(csdev)->pm_restore_enable(csdev);
>> }
>> @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct
>> coresight_path *path)
>> to = list_prev_entry(coresight_path_last_node(path), link);
>> coresight_disable_path_from_to(path, from, to);
>> + ret = coresight_pm_device_save(coresight_get_sink(path));
>> + if (ret)
>> + goto sink_failed;
>> +
>
> The comment directly above this says "Up to the node before sink to
> avoid latency". But then this line goes and saves the sink anyway. So
> I'm not sure what's meant by the comment?
>
>> return 0;
>> +
>> +sink_failed:
>> + if (!coresight_enable_path_from_to(path, coresight_get_mode(source),
>> + from, to))
>> + coresight_pm_device_restore(source);
>> +
>> + pr_err("Failed in coresight PM save on CPU%d: %d\n",
>> + smp_processor_id(), ret);
>> + this_cpu_write(percpu_pm_failed, true);
>
> Why does only a failing sink set percpu_pm_failed when failing to save
> the source exits early. Sashiko has a similar comment that this could
> result in restoring uninitialised source save data later, but a comment
> in this function about why the flow is like this would be helpful.
>
> We have coresight_disable_path_from_to() which always succeeds and
> doesn't return an error. TRBE is the only sink with a pm_save_disable()
> callback, but it always succeeds anyway.
>
> Would it not be much simpler to require that sink save/restore callbacks
> always succeed and don't return anything? Seems like this
> percpu_pm_failed stuff is extra complexity for a scenario that doesn't
> exist? The only thing that can fail is saving the source but it doesn't
> goto sink_failed when that happens.
>
> Ideally etm4_cpu_save() wouldn't have a return value either. It would be
> good if we could find away to skip or ignore the timeouts in there
> somehow because that's the only reason it can fail.
>
>> + return ret;
>> }
>> static void coresight_pm_restore(struct coresight_path *path)
>> {
>> struct coresight_device *source = coresight_get_source(path);
>> + struct coresight_device *sink = coresight_get_sink(path);
>> struct coresight_node *from, *to;
>> int ret;
>> + coresight_pm_device_restore(sink);
>> +
>> from = coresight_path_first_node(path);
>> /* Up to the node before sink to avoid latency */
>> to = list_prev_entry(coresight_path_last_node(path), link);
>> @@ -1808,6 +1846,8 @@ static void coresight_pm_restore(struct
>> coresight_path *path)
>> return;
>> path_failed:
>> + coresight_pm_device_save(sink);
>> +
>> pr_err("Failed in coresight PM restore on CPU%d: %d\n",
>> smp_processor_id(), ret);
>>
>
^ permalink raw reply
* Re: [PATCH v2] media: cedrus: Fix missing cleanup in error path
From: Paul Kocialkowski @ 2026-04-09 13:15 UTC (permalink / raw)
To: Andrey Skvortsov
Cc: Dan Carpenter, Maxime Ripard, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260406221402.3721777-1-andrej.skvortzov@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
Hi,
On Tue 07 Apr 26, 01:14, Andrey Skvortsov wrote:
> From: Samuel Holland <samuel@sholland.org>
>
> According to the documentation struct v4l2_fh has to be cleaned up with
> v4l2_fh_exit() before being freed. [1]
> Currently there is no actual bug here, when v4l2_fh_exit() isn't called.
> v4l2_fh_exit() in this case only destroys internal mutex. But it may
> change in the future, when v4l2_fh_init/v4l2_fh_exit will be enhanced.
>
> 1. https://docs.kernel.org/driver-api/media/v4l2-fh.html
Good catch too, thanks!
Acked-by: Paul Kocialkowski <paulk@sys-base.io>
All the best,
Paul
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
> ---
>
> Changes in v2:
> - remove duplicate 'in-body' From: record
> - add details to commit message
>
> drivers/staging/media/sunxi/cedrus/cedrus.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index 6600245dff0e2..1d2130f35fffc 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -391,6 +391,7 @@ static int cedrus_open(struct file *file)
> err_m2m_release:
> v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
> err_free:
> + v4l2_fh_exit(&ctx->fh);
> kfree(ctx);
> mutex_unlock(&dev->dev_mutex);
>
> --
> 2.51.0
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] media: cedrus: Fix failure to clean up hardware on probe failure
From: Paul Kocialkowski @ 2026-04-09 13:10 UTC (permalink / raw)
To: Andrey Skvortsov
Cc: Dan Carpenter, Maxime Ripard, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Hans Verkuil, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260406221440.3721863-1-andrej.skvortzov@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
Hi,
On Tue 07 Apr 26, 01:14, Andrey Skvortsov wrote:
> From: Samuel Holland <samuel@sholland.org>
>
> If V4L2 device fails to register, then SRAM still be claimed and as a
> result driver will not be able to probe again.
>
> cedrus 1c0e000.video-codec: Failed to claim SRAM
> cedrus 1c0e000.video-codec: Failed to probe hardware
> cedrus 1c0e000.video-codec: probe with driver cedrus failed with error -16
>
> cedrus_hw_remove undoes everything that was previously done by
> cedrus_hw_probe, such as disabling runtime power management and
> releasing the claimed SRAM and reserved memory region.
Good catch, thanks for the patch!
Acked-by: Paul Kocialkowski <paulk@sys-base.io>
Note that I (still) plan to rework the architecture of this driver in the
future but such fixes are definitely welcome in the meantime.
All the best,
Paul
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
> ---
>
> Changes in v2:
> - remove duplicate 'in-body' From: record
> - add more technical details to commit message
>
> drivers/staging/media/sunxi/cedrus/cedrus.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index 1d2130f35fffc..ee0e286add67d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -477,7 +477,7 @@ static int cedrus_probe(struct platform_device *pdev)
> ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
> if (ret) {
> dev_err(&pdev->dev, "Failed to register V4L2 device\n");
> - return ret;
> + goto err_hw;
> }
>
> vfd = &dev->vfd;
> @@ -538,6 +538,8 @@ static int cedrus_probe(struct platform_device *pdev)
> v4l2_m2m_release(dev->m2m_dev);
> err_v4l2:
> v4l2_device_unregister(&dev->v4l2_dev);
> +err_hw:
> + cedrus_hw_remove(dev);
>
> return ret;
> }
> --
> 2.51.0
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt7988a-bpi-r4pro: rename mgmt port to lan5
From: Frank Wunderlich @ 2026-04-09 13:09 UTC (permalink / raw)
To: Frank Wunderlich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: devicetree, Daniel Golle, linux-kernel, linux-mediatek,
Andrew LaMarche, linux-arm-kernel
In-Reply-To: <20260303202006.37515-1-linux@fw-web.de>
Hi,
just a friendly ping....
Am 3. März 2026 um 21:20 schrieb "Frank Wunderlich" <linux@fw-web.de mailto:linux@fw-web.de?to=%22Frank%20Wunderlich%22%20%3Clinux%40fw-web.de%3E >:
>
> From: Frank Wunderlich <frank-w@public-files.de>
>
> It turns out that the label mgmt confuses users and now official case is
> released where the port is labeled with number 5. So just rename it to
> lan5 to follow naming convension (lan1-4 from mxl switch and lan6 for lan-
> combo).
>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> index a48132f09411..1175ee156cb3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> @@ -207,7 +207,7 @@ &gsw_phy0_led0 {
> };
>
> &gsw_port0 {
> - label = "mgmt";
> + label = "lan5";
> };
>
> /* R4Pro has only port 0 connected, so disable the others */
> --
> 2.43.0
>
regards Frank
^ permalink raw reply
* [PATCH RFC net-next 4/4] net: ethernet: mtk_eth_soc: report INGRESS_L2 byte_type in flow stats
From: Daniel Golle @ 2026-04-09 13:07 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, netfilter-devel,
coreteam
In-Reply-To: <cover.1775739840.git.daniel@makrotopia.org>
The MediaTek PPE MIB counters report ingress L2 frame bytes
including Ethernet, VLAN and PPPoE headers. Tell the flow offload
framework so it can derive correct L3 byte counts for conntrack
and update sub-interface counters.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/net/ethernet/mediatek/mtk_ppe_offload.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
index cc8c4ef8038f3..68cb03a193f3f 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
@@ -557,6 +557,7 @@ mtk_flow_offload_stats(struct mtk_eth *eth, struct flow_cls_offload *f)
&diff)) {
f->stats.pkts += diff.packets;
f->stats.bytes += diff.bytes;
+ f->stats.byte_type = FLOW_STATS_BYTES_INGRESS_L2;
}
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 3/4] nf_flow_table: convert hw byte counts and update sub-interface stats
From: Daniel Golle @ 2026-04-09 13:07 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, netfilter-devel,
coreteam
In-Reply-To: <cover.1775739840.git.daniel@makrotopia.org>
Hardware flow offload counters may report L2 frame bytes while
conntrack expects L3 (IP) bytes. When a driver sets byte_type
to INGRESS_L2 or EGRESS_L2, subtract the appropriate per-direction
encap and tunnel overhead to derive L3 byte counts for conntrack.
Additionally, propagate per-flow stats to bridge, VLAN and PPPoE
sub-interfaces that are bypassed by hardware offloading. Each
sub-interface gets the L3 byte count plus the overhead of any
inner encap layers below it, matching what the software path
would count. Both RX and TX directions are updated.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
net/netfilter/nf_flow_table_offload.c | 174 +++++++++++++++++++++++++-
1 file changed, 172 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 002ec15d988bd..67452da487c94 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -5,6 +5,8 @@
#include <linux/netfilter.h>
#include <linux/rhashtable.h>
#include <linux/netdevice.h>
+#include <linux/if_vlan.h>
+#include <linux/if_pppox.h>
#include <linux/tc_act/tc_csum.h>
#include <net/flow_offload.h>
#include <net/ip_tunnels.h>
@@ -1008,10 +1010,135 @@ static void flow_offload_tuple_stats(struct flow_offload_work *offload,
&offload->flowtable->flow_block.cb_list);
}
+static int flow_offload_encap_hlen(const struct flow_offload_tuple *tuple,
+ int idx)
+{
+ switch (tuple->encap[idx].proto) {
+ case htons(ETH_P_8021Q):
+ case htons(ETH_P_8021AD):
+ return VLAN_HLEN;
+ case htons(ETH_P_PPP_SES):
+ return PPPOE_SES_HLEN;
+ }
+ return 0;
+}
+
+static void flow_offload_encap_netstats(struct net_device *dev,
+ __be16 encap_proto,
+ bool rx, u64 pkts, u64 bytes)
+{
+ struct pcpu_sw_netstats *tstats;
+ struct vlan_pcpu_stats *vstats;
+
+ if (encap_proto == htons(ETH_P_8021Q) ||
+ encap_proto == htons(ETH_P_8021AD)) {
+ vstats = this_cpu_ptr(vlan_dev_priv(dev)->vlan_pcpu_stats);
+ u64_stats_update_begin(&vstats->syncp);
+ if (rx) {
+ u64_stats_add(&vstats->rx_packets, pkts);
+ u64_stats_add(&vstats->rx_bytes, bytes);
+ } else {
+ u64_stats_add(&vstats->tx_packets, pkts);
+ u64_stats_add(&vstats->tx_bytes, bytes);
+ }
+ u64_stats_update_end(&vstats->syncp);
+ } else if (dev->tstats) {
+ tstats = this_cpu_ptr(dev->tstats);
+ u64_stats_update_begin(&tstats->syncp);
+ if (rx) {
+ u64_stats_add(&tstats->rx_packets, pkts);
+ u64_stats_add(&tstats->rx_bytes, bytes);
+ } else {
+ u64_stats_add(&tstats->tx_packets, pkts);
+ u64_stats_add(&tstats->tx_bytes, bytes);
+ }
+ u64_stats_update_end(&tstats->syncp);
+ }
+}
+
+/* Update sub-interface (VLAN, PPPoE) stats for hw-offloaded flows.
+ *
+ * The driver reports L3 (IP) bytes. Each sub-interface in the
+ * software path sees the frame with the headers of all layers
+ * BELOW it still present, so we add back inner-layer overhead.
+ *
+ * encap[] is ordered outermost to innermost, so walk from the
+ * innermost layer outward, accumulating overhead as we go.
+ */
+static void flow_offload_update_encap_stats(struct flow_offload *flow,
+ struct flow_offload_tuple *tuple,
+ bool rx, u64 pkts, u64 bytes)
+{
+ struct net_device *dev;
+ int inner_hlen = 0;
+ int i;
+
+ for (i = tuple->encap_num - 1; i >= 0; i--) {
+ if (tuple->in_vlan_ingress & BIT(i))
+ continue;
+
+ dev = dev_get_by_index_rcu(dev_net(flow->ct->ct_net),
+ tuple->encap_ifidx[i]);
+ if (dev)
+ flow_offload_encap_netstats(dev,
+ tuple->encap[i].proto, rx,
+ pkts,
+ bytes + inner_hlen * pkts);
+
+ inner_hlen += flow_offload_encap_hlen(tuple, i);
+ }
+
+ /* Bridge device sits outside all encap layers -- it sees
+ * L3 bytes plus the full encap overhead.
+ */
+ if (tuple->bridge_ifidx) {
+ dev = dev_get_by_index_rcu(dev_net(flow->ct->ct_net),
+ tuple->bridge_ifidx);
+ if (dev && dev->tstats)
+ flow_offload_encap_netstats(dev, 0, rx, pkts,
+ bytes + inner_hlen * pkts);
+ }
+}
+
+/* Compute per-direction input overhead from the encap and tunnel
+ * chains. Hardware flow counters report L2 frame bytes but
+ * conntrack expects L3 (inner IP) bytes -- matching what the
+ * software path sees after stripping all encap and tunnel headers.
+ */
+static int flow_offload_input_l2_overhead(struct flow_offload_tuple *tuple)
+{
+ int overhead = ETH_HLEN;
+ int i;
+
+ for (i = 0; i < tuple->encap_num; i++) {
+ if (tuple->in_vlan_ingress & BIT(i))
+ continue;
+
+ overhead += flow_offload_encap_hlen(tuple, i);
+ }
+
+ if (tuple->tun_num) {
+ switch (tuple->tun.l3_proto) {
+ case IPPROTO_IPIP:
+ overhead += sizeof(struct iphdr);
+ break;
+ case IPPROTO_IPV6:
+ overhead += sizeof(struct ipv6hdr);
+ break;
+ }
+ }
+
+ return overhead;
+}
+
static void flow_offload_work_stats(struct flow_offload_work *offload)
{
+ struct flow_offload_tuple *tuple;
struct flow_stats stats[FLOW_OFFLOAD_DIR_MAX] = {};
+ u64 l3_bytes[FLOW_OFFLOAD_DIR_MAX];
+ int l2_overhead;
u64 lastused;
+ int i;
flow_offload_tuple_stats(offload, FLOW_OFFLOAD_DIR_ORIGINAL, &stats[0]);
if (test_bit(NF_FLOW_HW_BIDIRECTIONAL, &offload->flow->flags))
@@ -1022,16 +1149,59 @@ static void flow_offload_work_stats(struct flow_offload_work *offload)
offload->flow->timeout = max_t(u64, offload->flow->timeout,
lastused + flow_offload_get_timeout(offload->flow));
+ /* Convert hardware byte counts to L3 based on what the driver
+ * reports. Drivers that already report L3 (or do not set
+ * byte_type) need no conversion.
+ */
+ for (i = 0; i < FLOW_OFFLOAD_DIR_MAX; i++) {
+ l2_overhead = 0;
+
+ switch (stats[i].byte_type) {
+ case FLOW_STATS_BYTES_INGRESS_L2:
+ tuple = &offload->flow->tuplehash[i].tuple;
+ l2_overhead = flow_offload_input_l2_overhead(tuple);
+ break;
+ case FLOW_STATS_BYTES_EGRESS_L2:
+ tuple = &offload->flow->tuplehash[!i].tuple;
+ l2_overhead = flow_offload_input_l2_overhead(tuple);
+ break;
+ default:
+ break;
+ }
+ l3_bytes[i] = stats[i].bytes - stats[i].pkts * l2_overhead;
+ }
+
if (offload->flowtable->flags & NF_FLOWTABLE_COUNTER) {
if (stats[0].pkts)
nf_ct_acct_add(offload->flow->ct,
FLOW_OFFLOAD_DIR_ORIGINAL,
- stats[0].pkts, stats[0].bytes);
+ stats[0].pkts, l3_bytes[0]);
if (stats[1].pkts)
nf_ct_acct_add(offload->flow->ct,
FLOW_OFFLOAD_DIR_REPLY,
- stats[1].pkts, stats[1].bytes);
+ stats[1].pkts, l3_bytes[1]);
+ }
+
+ rcu_read_lock();
+ for (i = 0; i < FLOW_OFFLOAD_DIR_MAX; i++) {
+ tuple = &offload->flow->tuplehash[i].tuple;
+ if (!tuple->encap_num)
+ continue;
+
+ /* Input-side encap devices get RX stats */
+ if (stats[i].pkts)
+ flow_offload_update_encap_stats(offload->flow,
+ tuple, true,
+ stats[i].pkts,
+ l3_bytes[i]);
+ /* Same devices get TX stats from the other direction */
+ if (stats[!i].pkts)
+ flow_offload_update_encap_stats(offload->flow,
+ tuple, false,
+ stats[!i].pkts,
+ l3_bytes[!i]);
}
+ rcu_read_unlock();
}
static void flow_offload_work_handler(struct work_struct *work)
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 2/4] nf_flow_table: track sub-interface and bridge ifindex in flow tuple
From: Daniel Golle @ 2026-04-09 13:07 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, netfilter-devel,
coreteam
In-Reply-To: <cover.1775739840.git.daniel@makrotopia.org>
Store the net_device ifindex alongside each encap entry and for
bridge devices during path discovery so the flow offload stats
path can later update sub-interface (VLAN, PPPoE, bridge)
counters for hw-offloaded flows.
The indices are placed below __hash so they do not affect flow
tuple lookups.
No functional change -- the indices are stored but not yet used.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
include/net/netfilter/nf_flow_table.h | 5 +++++
net/netfilter/nf_flow_table_core.c | 2 ++
net/netfilter/nf_flow_table_path.c | 8 ++++++++
3 files changed, 15 insertions(+)
diff --git a/include/net/netfilter/nf_flow_table.h b/include/net/netfilter/nf_flow_table.h
index b09c11c048d51..ec1a18cfd9621 100644
--- a/include/net/netfilter/nf_flow_table.h
+++ b/include/net/netfilter/nf_flow_table.h
@@ -148,6 +148,9 @@ struct flow_offload_tuple {
/* All members above are keys for lookups, see flow_offload_hash(). */
struct { } __hash;
+ int encap_ifidx[NF_FLOW_TABLE_ENCAP_MAX];
+ int bridge_ifidx;
+
u8 dir:2,
xmit_type:3,
encap_num:2,
@@ -221,11 +224,13 @@ struct nf_flow_route {
struct {
u16 id;
__be16 proto;
+ int ifindex;
} encap[NF_FLOW_TABLE_ENCAP_MAX];
struct flow_offload_tunnel tun;
u8 num_encaps:2,
num_tuns:2,
ingress_vlans:2;
+ int bridge_ifindex;
} in;
struct {
u32 ifindex;
diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
index 2c4140e6f53c5..9bc8be177b392 100644
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -115,6 +115,7 @@ static int flow_offload_fill_route(struct flow_offload *flow,
for (i = route->tuple[dir].in.num_encaps - 1; i >= 0; i--) {
flow_tuple->encap[j].id = route->tuple[dir].in.encap[i].id;
flow_tuple->encap[j].proto = route->tuple[dir].in.encap[i].proto;
+ flow_tuple->encap_ifidx[j] = route->tuple[dir].in.encap[i].ifindex;
if (route->tuple[dir].in.ingress_vlans & BIT(i))
flow_tuple->in_vlan_ingress |= BIT(j);
j++;
@@ -123,6 +124,7 @@ static int flow_offload_fill_route(struct flow_offload *flow,
flow_tuple->tun = route->tuple[dir].in.tun;
flow_tuple->encap_num = route->tuple[dir].in.num_encaps;
flow_tuple->tun_num = route->tuple[dir].in.num_tuns;
+ flow_tuple->bridge_ifidx = route->tuple[dir].in.bridge_ifindex;
switch (route->tuple[dir].xmit_type) {
case FLOW_OFFLOAD_XMIT_DIRECT:
diff --git a/net/netfilter/nf_flow_table_path.c b/net/netfilter/nf_flow_table_path.c
index 6bb9579dcc2ab..c5817cb96a9f6 100644
--- a/net/netfilter/nf_flow_table_path.c
+++ b/net/netfilter/nf_flow_table_path.c
@@ -79,8 +79,10 @@ struct nft_forward_info {
struct id {
__u16 id;
__be16 proto;
+ int ifindex;
} encap[NF_FLOW_TABLE_ENCAP_MAX];
u8 num_encaps;
+ int bridge_ifindex;
struct flow_offload_tunnel tun;
u8 num_tuns;
u8 ingress_vlans;
@@ -136,12 +138,15 @@ static void nft_dev_path_info(const struct net_device_path_stack *stack,
path->encap.id;
info->encap[info->num_encaps].proto =
path->encap.proto;
+ info->encap[info->num_encaps].ifindex =
+ path->dev->ifindex;
info->num_encaps++;
}
if (path->type == DEV_PATH_PPPOE)
memcpy(info->h_dest, path->encap.h_dest, ETH_ALEN);
break;
case DEV_PATH_BRIDGE:
+ info->bridge_ifindex = path->dev->ifindex;
if (is_zero_ether_addr(info->h_source))
memcpy(info->h_source, path->dev->dev_addr, ETH_ALEN);
@@ -156,6 +161,7 @@ static void nft_dev_path_info(const struct net_device_path_stack *stack,
}
info->encap[info->num_encaps].id = path->bridge.vlan_id;
info->encap[info->num_encaps].proto = path->bridge.vlan_proto;
+ info->encap[info->num_encaps].ifindex = path->dev->ifindex;
info->num_encaps++;
break;
case DEV_PATH_BR_VLAN_UNTAG:
@@ -261,6 +267,7 @@ static void nft_dev_forward_path(const struct nft_pktinfo *pkt,
for (i = 0; i < info.num_encaps; i++) {
route->tuple[!dir].in.encap[i].id = info.encap[i].id;
route->tuple[!dir].in.encap[i].proto = info.encap[i].proto;
+ route->tuple[!dir].in.encap[i].ifindex = info.encap[i].ifindex;
}
if (info.num_tuns &&
@@ -273,6 +280,7 @@ static void nft_dev_forward_path(const struct nft_pktinfo *pkt,
route->tuple[!dir].in.num_encaps = info.num_encaps;
route->tuple[!dir].in.ingress_vlans = info.ingress_vlans;
+ route->tuple[!dir].in.bridge_ifindex = info.bridge_ifindex;
if (info.xmit_type == FLOW_OFFLOAD_XMIT_DIRECT) {
memcpy(route->tuple[dir].out.h_source, info.h_source, ETH_ALEN);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 1/4] net: flow_offload: let drivers report byte counter semantics
From: Daniel Golle @ 2026-04-09 13:07 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, netfilter-devel,
coreteam
In-Reply-To: <cover.1775739840.git.daniel@makrotopia.org>
Hardware flow offload engines count bytes at different points --
some report ingress L2 frame bytes, others egress L2, others L3.
Add an enum so drivers can declare what their counters represent.
The framework can then convert to L3 as needed for conntrack.
Default is FLOW_STATS_BYTES_L3 (zero), preserving existing
behaviour for all current drivers.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
include/net/flow_offload.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index 70a02ee143080..7f5ef29b3abce 100644
--- a/include/net/flow_offload.h
+++ b/include/net/flow_offload.h
@@ -541,12 +541,19 @@ static inline bool flow_rule_match_has_control_flags(const struct flow_rule *rul
return flow_rule_has_control_flags(match.mask->flags, extack);
}
+enum flow_stats_byte_type {
+ FLOW_STATS_BYTES_L3 = 0, /* L3 (inner IP) bytes */
+ FLOW_STATS_BYTES_INGRESS_L2, /* full ingress L2 frame bytes */
+ FLOW_STATS_BYTES_EGRESS_L2, /* full egress L2 frame bytes */
+};
+
struct flow_stats {
u64 pkts;
u64 bytes;
u64 drops;
u64 lastused;
enum flow_action_hw_stats used_hw_stats;
+ enum flow_stats_byte_type byte_type;
bool used_hw_stats_valid;
};
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 0/4] improve hw flow offload byte accounting
From: Daniel Golle @ 2026-04-09 13:07 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, netfilter-devel,
coreteam
Hardware flow counters report raw byte counts whose semantics
vary by vendor -- some count ingress L2 frames, others egress
L2, others L3. The nf_flow_table framework currently passes
these bytes straight to conntrack without conversion, and
sub-interfaces (VLAN, PPPoE) that are bypassed by hw offload
never see any counter updates at all.
This series lets drivers declare what their counters represent,
so the framework can normalize to L3 for conntrack and
propagate per-layer stats to encap sub-interfaces.
Questions:
- Sub-interface stats accesses vlan_dev_priv() directly --
should there be a generic netdev callback instead?
- Are there hw offload drivers whose counters do not fit the
ingress-L2 / egress-L2 / L3 model?
Daniel Golle (4):
net: flow_offload: let drivers report byte counter semantics
nf_flow_table: track sub-interface and bridge ifindex in flow tuple
nf_flow_table: convert hw byte counts and update sub-interface stats
net: ethernet: mtk_eth_soc: report INGRESS_L2 byte_type in flow stats
.../net/ethernet/mediatek/mtk_ppe_offload.c | 1 +
include/net/flow_offload.h | 7 +
include/net/netfilter/nf_flow_table.h | 5 +
net/netfilter/nf_flow_table_core.c | 2 +
net/netfilter/nf_flow_table_offload.c | 174 +++++++++++++++++-
net/netfilter/nf_flow_table_path.c | 8 +
6 files changed, 195 insertions(+), 2 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Krzysztof Kozlowski @ 2026-04-09 13:05 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <adejoCVSpOW5wygD@gregor-framework>
On 09/04/2026 15:03, Gregor Herburger wrote:
>>>
>>> If I drop the binding patch how to distinguish the variants? Should I
>>> add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
>>> use it in the firmware/raspberrypi driver to add the second otp region?
>>
>> So you have different devices/variants? What is the "variant" here?
>
> Seems so. I suppose there is at least a bcm2712 variant and a non-bcm2712
> variant (which is currently confusingly named 'raspberrypi,bcm2835-firmware').
>>
>> Writing-bindings asks you to have per device compatible. Why standard
>> rules do not apply here? (see also DTS101)
>
> I am not arguing that the rules do not apply here. I want to find out
> what is the correct way to do it.
>
> Should there then be a 'raspberrypi,bcm2712-firmware' compatible with
> 'raspberrypi,bcm2835-firmware' fallback?
Yes, most likely. Let's wait a bit - maybe someone from Raspberry or
Broadcom will clarify things here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Gregor Herburger @ 2026-04-09 13:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <2aa66897-12ce-47c5-993d-e9e1d01a0cdd@kernel.org>
On Thu, Apr 09, 2026 at 02:15:32PM +0200, Krzysztof Kozlowski wrote:
> On 09/04/2026 14:02, Gregor Herburger wrote:
> > Hi Krzysztof,
> >
> > thanks for reviewing.
> >
> > On Thu, Apr 09, 2026 at 10:15:12AM +0200, Krzysztof Kozlowski wrote:
> >> On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> >>> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> >>> to the devicetree.
> >>
> >> So this sentence confirms my question on bindings - your device
> >> raspberrypi,bcm2835-firmware has these, thus you do not need these child
> >> nodes at all. Neither compatibles.
> >
> > I dont't think so. In my understanding the bcm2835-firmware does not
> > provide the otp registers but only provides the interface to the
> > registers. Though I don't know the details how this is done but [1] says
> > that only BCM2712 has 512bits and the others (like bcm2711) have
>
> Still the same. s/otp/interface/ so your device provides interface.
>
Ok understood.
> > 256bits. So both devicetrees have the raspberrypi,bcm2835-firmware node
> > but only the bcm2712 has the raspberrypi,firmware-otp-private node while the
>
> Why does bcm2712 use bcm2835 compatible?
I have no idea. But it is like this.
>
> Nodes and properties are not a solution. See DTS101 question - "...
> because my new device, which is compatible with an older one, does not
> support ..." and answer: No.
>
>
>
> > raspberrypi,firmware-otp-customer is available in all raspberrys.
> >
> >> Drop entire DTS and binding patches.
> >
> > If I drop the binding patch how to distinguish the variants? Should I
> > add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
> > use it in the firmware/raspberrypi driver to add the second otp region?
>
> So you have different devices/variants? What is the "variant" here?
Seems so. I suppose there is at least a bcm2712 variant and a non-bcm2712
variant (which is currently confusingly named 'raspberrypi,bcm2835-firmware').
>
> Writing-bindings asks you to have per device compatible. Why standard
> rules do not apply here? (see also DTS101)
I am not arguing that the rules do not apply here. I want to find out
what is the correct way to do it.
Should there then be a 'raspberrypi,bcm2712-firmware' compatible with
'raspberrypi,bcm2835-firmware' fallback?
>
> >
> > Also what I don't understand why we have all the bindings for
>
> Neither do I.
Ok good. That is what confused me.
Best regards,
Gregor
^ permalink raw reply
* [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user
From: Brian Ruley @ 2026-04-09 12:54 UTC (permalink / raw)
To: Russell King, Steve Capper, Will Deacon
Cc: Brian Ruley, Russell King, linux-arm-kernel, linux-kernel
Fixes cache desync, which can cause undefined instruction,
translation and permission faults under heavy memory use.
This is an old bug introduced in commit 1971188aa196 ("ARM: 7985/1: mm:
implement pte_accessible for faulting mappings"), which included a check
for the young bit of a PTE. The underlying assumption was that old pages
are not cached, therefore, `__sync_icache_dcache' could be skipped
entirely.
However, under extreme memory pressure, page migrations happen
frequently and the assumption of uncached "old" pages does not hold.
Especially for systems that do not have swap, the migrated pages are
unequivocally marked old. This presents a problem, as it is possible
for the original page to be immediately mapped to another VA that
happens to share the same cache index in VIPT I-cache (we found this
bug on Cortex-A9). Without cache invalidation, the CPU will see the
old mapping whose physical page can now be used for a different
purpose, as illustrated below:
Core Physical Memory
+-------------------------------+ +------------------+
| TLB | | |
| VA_A 0xb6e6f -> pfn_q | | pfn_q: code |
+-------------------------------+ +------------------+
| I-cache |
| set[VA_A bits] | tag=pfn_q |
+-------------------------------+
migrate (kcompactd):
1. copy pfn_q --> pfn_r
2. free pfn_q
3. pte: VA_a -> pfn_r
4. pte_mkold(pte) --> !young
5. ICIALLUIS skipped (because !young)
pfn_src reused (OOM pressure):
pte: VA_B -> pfn_q (different code)
bug:
Core Physical Memory
+-------------------------------+ +------------------+
| TLB (empty) | | pfn_r: old code |
+-------------------------------+ | pfn_q: new code |
| I-cache | +------------------+
| set[VA_A bits] | tag=pfn_q |<--- wrong instructions
+-------------------------------+
This was verified on ba16-based board (i.MX6Quad/Dual, Cortex-A9) by
instrumenting the migration code to track recently migrated pages in a
ring buffer and then dumping them in the undefined instruction fault
handler. The bug can be triggered with `stress-ng':
stress-ng --vm 4 --vm-bytes 2G --vm-method zero-one --verify
Note that the system we tested on has only 2G of memory, so the test
triggered the OOM-killer in our case.
Fixes: 1971188aa196 ("ARM: 7985/1: mm: implement pte_accessible for faulting mappings")
Signed-off-by: Brian Ruley <brian.ruley@gehealthcare.com>
---
arch/arm/include/asm/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 6fa9acd6a7f5..e3a5b4a9a65f 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -185,7 +185,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
#define pte_exec(pte) (pte_isclear((pte), L_PTE_XN))
#define pte_valid_user(pte) \
- (pte_valid(pte) && pte_isset((pte), L_PTE_USER) && pte_young(pte))
+ (pte_valid(pte) && pte_isset((pte), L_PTE_USER))
static inline bool pte_access_permitted(pte_t pte, bool write)
{
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device
From: James Clark @ 2026-04-09 12:54 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, Yeoreum Yun, Mark Rutland,
Will Deacon, Yabin Cui, Keita Morisaki, Yuanfang Zhang,
Greg Kroah-Hartman, Alexander Shishkin, Tamas Petz,
Thomas Gleixner, Peter Zijlstra, Suzuki K Poulose, Mike Leach
In-Reply-To: <e7c6f497-f8f0-409b-b80a-a064b222c08d@linaro.org>
On 09/04/2026 11:52 am, James Clark wrote:
>
>
> On 05/04/2026 4:02 pm, Leo Yan wrote:
>> Unlike system level sinks, per-CPU sinks may lose power during CPU idle
>> states. Currently, this applies specifically to TRBE. This commit
>> invokes save and restore callbacks for the sink in the CPU PM notifier.
>>
>> If the sink provides PM callbacks but the source does not, this is
>> unsafe because the sink cannot be disabled safely unless the source
>> can also be controlled, so veto low power entry to avoid lockups.
>>
>> Tested-by: James Clark <james.clark@linaro.org>
>> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> Reviewed-by: James Clark <james.clark@linaro.org>
>> Signed-off-by: Leo Yan <leo.yan@arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 46 ++++++++++++++++++
>> ++++++++--
>> 1 file changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/
>> hwtracing/coresight/coresight-core.c
>> index
>> c1e8debc76aba7eb5ecf7efe2a3b9b8b3e11b10c..a918bf6398a932de30fe9b4947020cc4c1cfb2f7 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -1736,14 +1736,15 @@ static void coresight_release_device_list(void)
>> /* Return: 1 if PM is required, 0 if skip, <0 on error */
>> static int coresight_pm_check(struct coresight_path *path)
>> {
>> - struct coresight_device *source;
>> - bool source_has_cb;
>> + struct coresight_device *source, *sink;
>> + bool source_has_cb, sink_has_cb;
>> if (!path)
>> return 0;
>> source = coresight_get_source(path);
>> - if (!source)
>> + sink = coresight_get_sink(path);
>> + if (!source || !sink)
>> return 0;
>> /* Don't save and restore if the source is inactive */
>> @@ -1759,16 +1760,36 @@ static int coresight_pm_check(struct
>> coresight_path *path)
>> if (source_has_cb)
>> return 1;
>> + sink_has_cb = coresight_ops(sink)->pm_save_disable &&
>> + coresight_ops(sink)->pm_restore_enable;
>> + /*
>> + * It is not permitted that the source has no callbacks while the
>> sink
>> + * does, as the sink cannot be disabled without disabling the
>> source,
>> + * which may lead to lockups. Alternatively, the ETM driver should
>> + * enable self-hosted PM mode at probe (see etm4_probe()).
>> + */
>> + if (sink_has_cb) {
>> + pr_warn_once("coresight PM failed: source has no PM callbacks; "
>> + "cannot safely control sink\n");
>
> This prints out on my Orion board on a fresh boot because of how
> pm_save_enable is setup there. Do we really need the configuration of
> pm_save_enable for ETE/TRBE if we know that it always needs saving?
>
> It also stops warning if I rmmod and modprobe the module after booting.
> Seems like pm_save_enable is different depending on how the module is
> loaded which doesn't seem right.
>
>> + return -EINVAL;
>> + }
>> +
>> return 0;
>> }
>> static int coresight_pm_device_save(struct coresight_device *csdev)
>> {
>> + if (!csdev || !coresight_ops(csdev)->pm_save_disable)
>> + return 0;
>> +
>> return coresight_ops(csdev)->pm_save_disable(csdev);
>> }
>> static void coresight_pm_device_restore(struct coresight_device *csdev)
>> {
>> + if (!csdev || !coresight_ops(csdev)->pm_restore_enable)
>> + return;
>> +
>> coresight_ops(csdev)->pm_restore_enable(csdev);
>> }
>> @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct
>> coresight_path *path)
>> to = list_prev_entry(coresight_path_last_node(path), link);
>> coresight_disable_path_from_to(path, from, to);
>> + ret = coresight_pm_device_save(coresight_get_sink(path));
>> + if (ret)
>> + goto sink_failed;
>> +
>
> The comment directly above this says "Up to the node before sink to
> avoid latency". But then this line goes and saves the sink anyway. So
> I'm not sure what's meant by the comment?
>
>> return 0;
>> +
>> +sink_failed:
>> + if (!coresight_enable_path_from_to(path, coresight_get_mode(source),
>> + from, to))
>> + coresight_pm_device_restore(source);
>> +
>> + pr_err("Failed in coresight PM save on CPU%d: %d\n",
>> + smp_processor_id(), ret);
>> + this_cpu_write(percpu_pm_failed, true);
>
> Why does only a failing sink set percpu_pm_failed when failing to save
> the source exits early. Sashiko has a similar comment that this could
> result in restoring uninitialised source save data later, but a comment
> in this function about why the flow is like this would be helpful.
>
> We have coresight_disable_path_from_to() which always succeeds and
> doesn't return an error. TRBE is the only sink with a pm_save_disable()
> callback, but it always succeeds anyway.
>
> Would it not be much simpler to require that sink save/restore callbacks
> always succeed and don't return anything? Seems like this
> percpu_pm_failed stuff is extra complexity for a scenario that doesn't
> exist? The only thing that can fail is saving the source but it doesn't
> goto sink_failed when that happens.
>
> Ideally etm4_cpu_save() wouldn't have a return value either. It would be
> good if we could find away to skip or ignore the timeouts in there
> somehow because that's the only reason it can fail.
>
etm4_disable_trace_unit() and etm4_enable_hw() also have timeouts but
the timeouts only print warnings, they don't cause early exits or return
error values.
Can we do the same for etm4_cpu_save()? It would be better to read and
restore potentially 'unstable' register values than to early exit and
restore known uninitialised values as it is here.
>> + return ret;
>> }
>> static void coresight_pm_restore(struct coresight_path *path)
>> {
>> struct coresight_device *source = coresight_get_source(path);
>> + struct coresight_device *sink = coresight_get_sink(path);
>> struct coresight_node *from, *to;
>> int ret;
>> + coresight_pm_device_restore(sink);
>> +
>> from = coresight_path_first_node(path);
>> /* Up to the node before sink to avoid latency */
>> to = list_prev_entry(coresight_path_last_node(path), link);
>> @@ -1808,6 +1846,8 @@ static void coresight_pm_restore(struct
>> coresight_path *path)
>> return;
>> path_failed:
>> + coresight_pm_device_save(sink);
>> +
>> pr_err("Failed in coresight PM restore on CPU%d: %d\n",
>> smp_processor_id(), ret);
>>
>
^ 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