* Re: [PATCH v2 01/30] KVM: arm64: Extract VMA size resolution in user_mem_abort()
From: Anshuman Khandual @ 2026-03-30 4:08 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-2-maz@kernel.org>
On 27/03/26 5:05 PM, Marc Zyngier wrote:
> From: Fuad Tabba <tabba@google.com>
>
> As part of an effort to refactor user_mem_abort() into smaller, more
> focused helper functions, extract the logic responsible for determining
> the VMA shift and page size into a new static helper,
> kvm_s2_resolve_vma_size().
>
> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 130 ++++++++++++++++++++++++-------------------
> 1 file changed, 73 insertions(+), 57 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 17d64a1e11e5c..f8064b2d32045 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1639,6 +1639,77 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> return ret != -EAGAIN ? ret : 0;
> }
>
> +static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
> + unsigned long hva,
> + struct kvm_memory_slot *memslot,
> + struct kvm_s2_trans *nested,
> + bool *force_pte, phys_addr_t *ipa)
> +{
> + short vma_shift;
> + long vma_pagesize;
> +
> + if (*force_pte)
> + vma_shift = PAGE_SHIFT;
> + else
> + vma_shift = get_vma_page_shift(vma, hva);
> +
> + switch (vma_shift) {
> +#ifndef __PAGETABLE_PMD_FOLDED
> + case PUD_SHIFT:
> + if (fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
> + break;
> + fallthrough;
> +#endif
> + case CONT_PMD_SHIFT:
> + vma_shift = PMD_SHIFT;
> + fallthrough;
> + case PMD_SHIFT:
> + if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE))
> + break;
> + fallthrough;
> + case CONT_PTE_SHIFT:
> + vma_shift = PAGE_SHIFT;
> + *force_pte = true;
> + fallthrough;
> + case PAGE_SHIFT:
> + break;
> + default:
> + WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
> + }
> +
> + vma_pagesize = 1UL << vma_shift;
> +
> + if (nested) {
> + unsigned long max_map_size;
> +
> + max_map_size = *force_pte ? PAGE_SIZE : PUD_SIZE;
> +
> + *ipa = kvm_s2_trans_output(nested);
> +
> + /*
> + * If we're about to create a shadow stage 2 entry, then we
> + * can only create a block mapping if the guest stage 2 page
> + * table uses at least as big a mapping.
> + */
> + max_map_size = min(kvm_s2_trans_size(nested), max_map_size);
> +
> + /*
> + * Be careful that if the mapping size falls between
> + * two host sizes, take the smallest of the two.
> + */
> + if (max_map_size >= PMD_SIZE && max_map_size < PUD_SIZE)
> + max_map_size = PMD_SIZE;
> + else if (max_map_size >= PAGE_SIZE && max_map_size < PMD_SIZE)
> + max_map_size = PAGE_SIZE;
> +
> + *force_pte = (max_map_size == PAGE_SIZE);
> + vma_pagesize = min_t(long, vma_pagesize, max_map_size);
> + vma_shift = __ffs(vma_pagesize);
> + }
> +
> + return vma_shift;
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_s2_trans *nested,
> struct kvm_memory_slot *memslot, unsigned long hva,
> @@ -1695,65 +1766,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> return -EFAULT;
> }
>
> - if (force_pte)
> - vma_shift = PAGE_SHIFT;
> - else
> - vma_shift = get_vma_page_shift(vma, hva);
> -
> - switch (vma_shift) {
> -#ifndef __PAGETABLE_PMD_FOLDED
> - case PUD_SHIFT:
> - if (fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
> - break;
> - fallthrough;
> -#endif
> - case CONT_PMD_SHIFT:
> - vma_shift = PMD_SHIFT;
> - fallthrough;
> - case PMD_SHIFT:
> - if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE))
> - break;
> - fallthrough;
> - case CONT_PTE_SHIFT:
> - vma_shift = PAGE_SHIFT;
> - force_pte = true;
> - fallthrough;
> - case PAGE_SHIFT:
> - break;
> - default:
> - WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
> - }
> -
> + vma_shift = kvm_s2_resolve_vma_size(vma, hva, memslot, nested,
> + &force_pte, &ipa);
> vma_pagesize = 1UL << vma_shift;
>
> - if (nested) {
> - unsigned long max_map_size;
> -
> - max_map_size = force_pte ? PAGE_SIZE : PUD_SIZE;
> -
> - ipa = kvm_s2_trans_output(nested);
> -
> - /*
> - * If we're about to create a shadow stage 2 entry, then we
> - * can only create a block mapping if the guest stage 2 page
> - * table uses at least as big a mapping.
> - */
> - max_map_size = min(kvm_s2_trans_size(nested), max_map_size);
> -
> - /*
> - * Be careful that if the mapping size falls between
> - * two host sizes, take the smallest of the two.
> - */
> - if (max_map_size >= PMD_SIZE && max_map_size < PUD_SIZE)
> - max_map_size = PMD_SIZE;
> - else if (max_map_size >= PAGE_SIZE && max_map_size < PMD_SIZE)
> - max_map_size = PAGE_SIZE;
> -
> - force_pte = (max_map_size == PAGE_SIZE);
> - vma_pagesize = min_t(long, vma_pagesize, max_map_size);
> - vma_shift = __ffs(vma_pagesize);
> - }
> -
> /*
> * Both the canonical IPA and fault IPA must be aligned to the
> * mapping size to ensure we find the right PFN and lay down the
^ permalink raw reply
* Re: [PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes
From: Kevin Tung @ 2026-03-30 3:15 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Amithash Prasasd, Kevin Tung, Ken Chen, Leo Yang, Jackson Liu,
Daniel Hsu
In-Reply-To: <d7794f74b26bbc1ee0a70e39c5671acc018f80eb.camel@codeconstruct.com.au>
On Thu, Mar 26, 2026 at 2:07 PM Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> Hi Kevin,
>
> Sorry for the delay.
>
> On Mon, 2026-03-09 at 11:41 -0700, Kevin Tung wrote:
> > On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery
> > <andrew@codeconstruct.com.au> wrote:
> > >
> > > Hi Kevin,
> > >
> > > Sorry for the patchy replies so far, but this series bothers me and
> > > other priorities keep bumping it down the list.
> > >
> > > On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote:
> > > > Two different power monitor devices, using different drivers, reuse
> > > > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants.
> > > > Defining these devices statically in the DTS can lead to incorrect
> > > > driver binding on newer boards when the wrong device is instantiated.
> > >
> > > There are effective methods of maintaining devicetrees for variants.
> > > Why are we choosing to remove information about the platform rather
> > > than use existing techniques to properly describe them?
> > >
> > Hi Andrew,
> >
> > This is due to hardware design changes during earlier development
> > stages, and the fix is expected to remain stable as the design has
> > matured.
> > Could you guide me on the best way to maintain devicetrees for
> > variants? Thank you :)
>
> My expectation is your platforms move through several design phases
> prior to (mass?) production. My suspicion is that you have sent a
> devicetree for the pre-production design phases, and you're trying to
> evolve that one devicetree to match the design for whatever current
> phase you're in.
>
> So, ideally: Send a devicetree only for the finalised design. Don't
> send devicetrees for pre-production designs.
>
> If you feel you can't do that for some reason, an alternative is to
> have a separate .dts file for each phase in the design process.
>
> This may sound tedious but it doesn't have to be a burden to maintain.
>
> For instance, you can use one or more .dtsi files to describe the
> common components and relationships for your platform. These .dtsi
> files are then #included into .dts files as usual. Often .dtsi files
> are used to isolate different hardware scopes (SoC vs board, for
> instance), but we're not limited to that, we can use them for the
> purpose outlined above too.
>
> If there are only (very) minor differences, there's also the option of
> #including another .dts file. From there you can adjust properties or
> even delete nodes where it makes sense. For example, we maintain a .dts
> file for the latest revision of the AST2600-EVB, but we also have a
> separate .dts for the A1 revision with a different regulator setup:
>
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts?h=v7.0-rc5
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb-a1.dts?h=v7.0-rc5
>
> Any of these are better options than this current approach of trying to
> justify incompatible changes against unclear design boundaries.
>
> Andrew
Hi Andrew,
Thank you for the guidance.
We will submit devicetree changes for the finalized design and ensure
they align with the hardware to maintain stability and avoid
incompatible changes.
Kevin
^ permalink raw reply
* RE: [PATCH v5 08/10] clk: realtek: Add support for MMC-tuned PLL clocks
From: Yu-Chun Lin [林祐君] @ 2026-03-30 3:00 UTC (permalink / raw)
To: Stephen Boyd, afaerber@suse.com, conor+dt@kernel.org,
Edgar Lee [李承諭],
Jyan Chou [周芷安], krzk+dt@kernel.org,
mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <177440366488.5403.14385693004290004608@localhost.localdomain>
> Quoting Yu-Chun Lin (2026-03-23 19:53:29)
> > diff --git a/drivers/clk/realtek/clk-pll-mmc.c
> > b/drivers/clk/realtek/clk-pll-mmc.c
> > new file mode 100644
> > index 000000000000..017663738c1f
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-pll-mmc.c
> > @@ -0,0 +1,399 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2021 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include "clk-pll.h"
>
> Include what you use in this C file, not just this header file. That makes it
> simpler to see what is used without following include trails.
Got it. I will explicitly include the required headers directly in this .c file.
> > +
> > +#define PLL_EMMC1_OFFSET 0x0
> > +#define PLL_EMMC2_OFFSET 0x4
> > +#define PLL_EMMC3_OFFSET 0x8
> > +#define PLL_EMMC4_OFFSET 0xc
> > +#define PLL_SSC_DIG_EMMC1_OFFSET 0x0
> > +#define PLL_SSC_DIG_EMMC3_OFFSET 0xc
> > +#define PLL_SSC_DIG_EMMC4_OFFSET 0x10
> > +
> > +#define PLL_MMC_SSC_DIV_N_VAL 0x1b
> > +
> > +#define PLL_PHRT0_MASK BIT(1)
> > +#define PLL_PHSEL_MASK GENMASK(4, 0)
> > +#define PLL_SSCPLL_RS_MASK GENMASK(12, 10)
> > +#define PLL_SSCPLL_ICP_MASK GENMASK(9, 5)
> > +#define PLL_SSC_DIV_EXT_F_MASK GENMASK(25, 13)
> > +#define PLL_PI_IBSELH_MASK GENMASK(28, 27)
> > +#define PLL_SSC_DIV_N_MASK GENMASK(23, 16)
> > +#define PLL_NCODE_SSC_EMMC_MASK GENMASK(20, 13)
> > +#define PLL_FCODE_SSC_EMMC_MASK GENMASK(12, 0)
> > +#define PLL_GRAN_EST_EM_MC_MASK GENMASK(20, 0)
> > +#define PLL_EN_SSC_EMMC_MASK BIT(0)
> > +#define PLL_FLAG_INITAL_EMMC_MASK BIT(1)
> [...]
> > diff --git a/drivers/clk/realtek/clk-pll.h
> > b/drivers/clk/realtek/clk-pll.h index 2d27a44a270c..9cf219871218
> > 100644
> > --- a/drivers/clk/realtek/clk-pll.h
> > +++ b/drivers/clk/realtek/clk-pll.h
> > @@ -44,4 +44,25 @@ static inline struct clk_pll *to_clk_pll(struct
> > clk_hw *hw) extern const struct clk_ops rtk_clk_pll_ops; extern
> > const struct clk_ops rtk_clk_pll_ro_ops;
> >
> > +struct clk_pll_mmc {
> > + struct clk_regmap clkr;
> > + int pll_ofs;
> > + int ssc_dig_ofs;
>
> These offsets should be unsigned?
>
Yes, I will fix it.
> > + struct clk_hw phase0_hw;
> > + struct clk_hw phase1_hw;
> > + u32 set_rate_val_53_97_set_ipc: 1;
>
> bool? Doubt we care about this unless we're packing structs (which we
> shouldn't be).
>
This member is actually redundant, so I will just remove it.
> > +};
> > +
> > +#define __clk_pll_mmc_hw(_ptr) __clk_regmap_hw(&(_ptr)->clkr)
> > +
> > +static inline struct clk_pll_mmc *to_clk_pll_mmc(struct clk_hw *hw) {
> > + struct clk_regmap *clkr = to_clk_regmap(hw);
> > +
> > + return container_of(clkr, struct clk_pll_mmc, clkr); }
Best regards,
Yu-Chun
^ permalink raw reply
* RE: [PATCH v5 01/10] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller
From: Yu-Chun Lin [林祐君] @ 2026-03-30 2:48 UTC (permalink / raw)
To: Stephen Boyd, afaerber@suse.com, conor+dt@kernel.org,
Edgar Lee [李承諭],
Jyan Chou [周芷安], krzk+dt@kernel.org,
mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <177440394165.5403.17868576455504268400@localhost.localdomain>
> Quoting Yu-Chun Lin (2026-03-23 19:53:22)
> > diff --git
> > a/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > new file mode 100644
> > index 000000000000..6fabc2da3975
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/realtek,rtd1625-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Realtek RTD1625 Clock & Reset Controller
> > +
> > +maintainers:
> > + - Yu-Chun Lin <eleanor.lin@realtek.com>
> > +
> > +description: |
> > + The Realtek RTD1625 Clock Controller manages and distributes clock
> > + signals to various controllers and implements a Reset Controller
> > +for the
> > + SoC peripherals.
> > +
> > + Clocks and resets are referenced by unique identifiers, which are
> > + defined as preprocessor macros in
> > + include/dt-bindings/clock/realtek,rtd1625-clk.h and
> include/dt-bindings/reset/realtek,rtd1625.h.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - realtek,rtd1625-crt-clk
> > + - realtek,rtd1625-iso-clk
> > + - realtek,rtd1625-iso-s-clk
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + "#clock-cells":
> > + const: 1
> > +
> > + "#reset-cells":
> > + const: 1
>
> Are there any input clks for the clk tree?
>
We don't dynamically calculate frequencies based on an input clock.
Since all of our current SoCs use a fixed 27MHz oscillator, we use
predefined lookup tables in the driver for the target frequencies instead.
Nevertheless, to properly describe the hardware layout, I will add the clock
properties in the bindings and DTS in v6.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#clock-cells"
> > + - "#reset-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + clock-controller@98000000 {
> > + compatible = "realtek,rtd1625-crt-clk";
> > + reg = <98000000 0x1000>;
>
> Should be 0x98000000 to match the unit address.
>
Ack.
Best Regards,
Yu-Chun
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
^ permalink raw reply
* Re: [PATCH v2 3/3] mailbox: mtk-cmdq: Remove unsued cmdq_get_shift_pa()
From: Jason-JH Lin (林睿祥) @ 2026-03-30 2:49 UTC (permalink / raw)
To: jassisinghbrar@gmail.com, AngeloGioacchino Del Regno
Cc: linux-media@vger.kernel.org,
Sirius Wang (王皓昱),
Moudy Ho (何宗原), mchehab@kernel.org,
Xiandong Wang (王先冬), nicolas@ndufresne.ca,
linux-kernel@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
linux-mediatek@lists.infradead.org, chunkuang.hu@kernel.org,
Paul-pl Chen (陳柏霖),
dri-devel@lists.freedesktop.org,
Singo Chang (張興國),
Nancy Lin (林欣螢), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <CABb+yY2cjMskJeXsn8+hZj2DcFs05yabHbSaGT5XSi0fn45zCQ@mail.gmail.com>
On Sun, 2026-03-29 at 11:03 -0500, Jassi Brar wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On Tue, Mar 24, 2026 at 11:05 PM Jason-JH Lin
> <jason-jh.lin@mediatek.com> wrote:
> >
> > Since the mailbox driver data can be obtained using
> > cmdq_get_mbox_priv()
> > and all CMDQ users have transitioned to cmdq_get_mbox_priv(),
> > cmdq_get_shift_pa() can be removed.
> >
> > Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
> > Reviewed-by: AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com>
> > ---
[snip]
> I think the simplest would be to take this with the other two
> predecessor patches.
> Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
>
Thank you Jassi!
Hi Angelo,
Could you please take this with this series?
[Series V2 3/4] Remove shift_pa from CMDQ jump functions
https://lore.kernel.org/all/20260325040239.2112517-1-jason-jh.lin@mediatek.com/
Thanks!
Regards,
Jason-JH Lin
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Add RK3562 serial aliases
From: 谢致邦 (XIE Zhibang) @ 2026-03-30 2:46 UTC (permalink / raw)
To: krzk
Cc: Yeking, conor+dt, devicetree, finley.xiao, heiko, kever.yang,
krzk+dt, linux-arm-kernel, linux-kernel, linux-rockchip, robh
In-Reply-To: <9b3ee9e9-d44d-49b1-81ac-9c3806dc0efb@kernel.org>
On Sat, Mar 28, 2026 at 04:08:57PM +0100, Krzysztof Kozlowski wrote:
> On 28/03/2026 14:05, 谢致邦 (XIE Zhibang) wrote:
> > This fixes the stdout-path in rk3562-evb2-v10.dts.
> >
> > Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree")
> > Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3562.dtsi | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3562.dtsi b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > index e4816aa3dae0..14e74e8ac7df 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > @@ -26,6 +26,16 @@ aliases {
> > gpio2 = &gpio2;
> > gpio3 = &gpio3;
> > gpio4 = &gpio4;
> > + serial0 = &uart0;
> > + serial1 = &uart1;
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + serial4 = &uart4;
> > + serial5 = &uart5;
> > + serial6 = &uart6;
> > + serial7 = &uart7;
> > + serial8 = &uart8;
> > + serial9 = &uart9;
>
> UART aliases are properties of the boards, not SoC.
>
> Best regards,
> Krzysztof
So are you saying that we need to remove the serial aliases from files
like rk3308.dtsi, rk3328.dtsi, rk3368.dtsi, rk3399-base.dtsi,
rk356x-base.dtsi, rk3576.dtsi, rk3588-base.dtsi, and so on?
Kind regards,
XIE Zhibang
^ permalink raw reply
* [PATCH] media: mediatek: vcodec: free working buf in vdec_vp9_slice_setup_single()
From: Haoxiang Li @ 2026-03-30 2:11 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno, hverkuil+cisco, laurent.pinchart,
p.zabel, benjamin.gaignard, xiaoyong.lu, mingjia.zhang
Cc: linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li, stable
Add an error path label in vdec_vp9_slice_setup_single()
and call vdec_vp9_slice_free_working_buffer() to free
working buffer.
Fixes: b0f407c19648 ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index cd1935014d76..b3ecb94bebb3 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1811,14 +1811,16 @@ static int vdec_vp9_slice_setup_single(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_prob_buffer(instance, vsi);
if (ret)
- goto err;
+ goto alloc_err;
ret = vdec_vp9_slice_setup_tile_buffer(instance, vsi, bs);
if (ret)
- goto err;
+ goto alloc_err;
return 0;
+alloc_err:
+ vdec_vp9_slice_free_working_buffer(instance);
err:
return ret;
}
--
2.25.1
^ permalink raw reply related
* [PATCH] media: mediatek: vcodec: free working buf on error path in vdec_vp9_slice_setup_lat()
From: Haoxiang Li @ 2026-03-30 2:02 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno, laurent.pinchart, hverkuil+cisco,
benjamin.gaignard, p.zabel, george.sun
Cc: linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li, stable
Add an error path label in vdec_vp9_slice_setup_lat()
and call vdec_vp9_slice_free_working_buffer() to free
working buffer to prevent potential memory leak.
Fixes: 5d418351ca8f ("media: mediatek: vcodec: support stateless VP9 decoding")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index cd1935014d76..3dadb5cc8876 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1168,7 +1168,7 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_lat_buffer(instance, vsi, bs, lat_buf);
if (ret)
- goto err;
+ goto alloc_err;
vdec_vp9_slice_setup_seg_buffer(instance, vsi, &instance->seg[0]);
@@ -1176,14 +1176,16 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_prob_buffer(instance, vsi);
if (ret)
- goto err;
+ goto alloc_err;
ret = vdec_vp9_slice_setup_tile_buffer(instance, vsi, bs);
if (ret)
- goto err;
+ goto alloc_err;
return 0;
+alloc_err:
+ vdec_vp9_slice_free_working_buffer(instance);
err:
return ret;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: Eric Biggers @ 2026-03-29 22:18 UTC (permalink / raw)
To: David Laight
Cc: Demian Shulhan, linux-crypto, linux-kernel, linux-arm-kernel,
ardb
In-Reply-To: <20260329225704.0eb82966@pumpkin>
On Sun, Mar 29, 2026 at 10:57:04PM +0100, David Laight wrote:
> Final thought:
> Is that allowing for the cost of kernel_fpu_begin()? - which I think only
> affects the first call.
> And the cost of the data-cache misses for the lookup table reads? - again
> worse for the first call.
I assume you mean kernel_neon_begin(). This is an arm64 patch. (I
encourage you to actually read the code. You seem to send a lot of
speculation-heavy comments without actually reading the code.)
Currently, the benchmark in crc_kunit just measures the throughput in a
loop (as has been discussed before). So no, it doesn't currently
capture the overhead of pulling code and data into cache. For NEON
register use it captures only the amortized overhead.
Note that using PMULL saves having to pull the table into memory, while
using the table is a bit less code and saves having to use kernel-mode
NEON. So both have their advantages and disadvantages.
This patch does fall back to the table for the last 'len & ~15' bytes,
which means the table may be needed anyway. That is not the optimal way
to do it, and it's something to address later when this is replaced with
something similar to x86's crc-pclmul-template.S.
- Eric
^ permalink raw reply
* [PATCH net-next] net: airoha: Fix typo in airoha_set_gdm2_loopback routine name
From: Lorenzo Bianconi @ 2026-03-29 22:03 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Rename airhoha_set_gdm2_loopback() in airoha_set_gdm2_loopback()
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..2beba017e791d20f142e754edafcd402d8cc496f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1709,7 +1709,7 @@ static int airoha_dev_set_macaddr(struct net_device *dev, void *p)
return 0;
}
-static int airhoha_set_gdm2_loopback(struct airoha_gdm_port *port)
+static int airoha_set_gdm2_loopback(struct airoha_gdm_port *port)
{
struct airoha_eth *eth = port->qdma->eth;
u32 val, pse_port, chan, nbq;
@@ -1785,7 +1785,7 @@ static int airoha_dev_init(struct net_device *dev)
if (!eth->ports[1]) {
int err;
- err = airhoha_set_gdm2_loopback(port);
+ err = airoha_set_gdm2_loopback(port);
if (err)
return err;
}
---
base-commit: cf0d9080c6f795bc6be08babbffa29b62c06e9b0
change-id: 20260329-airoha_set_gdm2_loopback-fix-typo-ce5131054f56
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: David Laight @ 2026-03-29 21:57 UTC (permalink / raw)
To: Eric Biggers
Cc: Demian Shulhan, linux-crypto, linux-kernel, linux-arm-kernel,
ardb
In-Reply-To: <20260329203829.GA2746@quark>
On Sun, 29 Mar 2026 13:38:29 -0700
Eric Biggers <ebiggers@kernel.org> wrote:
> On Sun, Mar 29, 2026 at 07:43:38AM +0000, Demian Shulhan wrote:
> > Implement an optimized CRC64 (NVMe) algorithm for ARM64 using NEON
> > Polynomial Multiply Long (PMULL) instructions. The generic shift-and-XOR
> > software implementation is slow, which creates a bottleneck in NVMe and
> > other storage subsystems.
> >
> > The acceleration is implemented using C intrinsics (<arm_neon.h>) rather
> > than raw assembly for better readability and maintainability.
> >
> > Key highlights of this implementation:
> > - Uses 4KB chunking inside scoped_ksimd() to avoid preemption latency
> > spikes on large buffers.
> > - Pre-calculates and loads fold constants via vld1q_u64() to minimize
> > register spilling.
> > - Benchmarks show the break-even point against the generic implementation
> > is around 128 bytes. The PMULL path is enabled only for len >= 128.
Final thought:
Is that allowing for the cost of kernel_fpu_begin()? - which I think only
affects the first call.
And the cost of the data-cache misses for the lookup table reads? - again
worse for the first call.
David
> >
> > Performance results (kunit crc_benchmark on Cortex-A72):
> > - Generic (len=4096): ~268 MB/s
> > - PMULL (len=4096): ~1556 MB/s (nearly 6x improvement)
> >
> > Signed-off-by: Demian Shulhan <demyansh@gmail.com>
>
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next
>
> Thanks!
>
> - Eric
>
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: gemini: Rename power controller node to gemini-poweroff
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260329205151.15161-1-khushalchitturi@gmail.com>
Update the node name for the Cortina Gemini power controller from
power-controller to gemini-poweroff since node "power controller" is
reserved for power domain controller.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
index befe322bd7de..c524adadcf81 100644
--- a/arch/arm/boot/dts/gemini/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini/gemini.dtsi
@@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
#interrupt-cells = <2>;
};
- power-controller@4b000000 {
+ gemini-poweroff@4b000000 {
compatible = "cortina,gemini-power-controller";
reg = <0x4b000000 0x100>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260329205151.15161-1-khushalchitturi@gmail.com>
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v1 -> v2:
- Renamed the node from power-controller to gemini-poweroff to resolve dtschema warnings.
Note:
* This patch series is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..8fbe7e952b25
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gemini-poweroff@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] dt-bindings: power: reset: cortina: Convert to DT schema and rename node
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema and update corresponding dtsi file with new node name
---
Khushal Chitturi (2):
dt-bindings: power: reset: cortina,gemini-power-controller: convert to
DT schema
ARM: dts: gemini: Rename power controller node to gemini-poweroff
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
3 files changed, 43 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
--
2.53.0
^ permalink raw reply
* Re: [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: Eric Biggers @ 2026-03-29 20:38 UTC (permalink / raw)
To: Demian Shulhan; +Cc: linux-crypto, linux-kernel, linux-arm-kernel, ardb
In-Reply-To: <20260329074338.1053550-1-demyansh@gmail.com>
On Sun, Mar 29, 2026 at 07:43:38AM +0000, Demian Shulhan wrote:
> Implement an optimized CRC64 (NVMe) algorithm for ARM64 using NEON
> Polynomial Multiply Long (PMULL) instructions. The generic shift-and-XOR
> software implementation is slow, which creates a bottleneck in NVMe and
> other storage subsystems.
>
> The acceleration is implemented using C intrinsics (<arm_neon.h>) rather
> than raw assembly for better readability and maintainability.
>
> Key highlights of this implementation:
> - Uses 4KB chunking inside scoped_ksimd() to avoid preemption latency
> spikes on large buffers.
> - Pre-calculates and loads fold constants via vld1q_u64() to minimize
> register spilling.
> - Benchmarks show the break-even point against the generic implementation
> is around 128 bytes. The PMULL path is enabled only for len >= 128.
>
> Performance results (kunit crc_benchmark on Cortex-A72):
> - Generic (len=4096): ~268 MB/s
> - PMULL (len=4096): ~1556 MB/s (nearly 6x improvement)
>
> Signed-off-by: Demian Shulhan <demyansh@gmail.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next
Thanks!
- Eric
^ permalink raw reply
* AW: [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Andreas Haarmann-Thiemann @ 2026-03-29 20:01 UTC (permalink / raw)
To: 'Linus Walleij'; +Cc: ulli.kroll, netdev, linux-arm-kernel
In-Reply-To: <CAD++jLmVPCL6p3jcdg1y_w=Zij6oVdWTvSmQFjWLn4yRJL4g=w@mail.gmail.com>
Hello Linus,
thank you for the confirmation!
Here is my Signed-off-by:
Signed-off-by: Andreas Haarmann-Thiemann <eitschman@nebelreich.de>
Please feel free to create the patch from the inline code.
Best regards,
Andreas Haarmann-Thiemann
-----Ursprüngliche Nachricht-----
Von: Linus Walleij <linusw@kernel.org>
Gesendet: Sonntag, 29. März 2026 20:54
An: Andreas Haarmann-Thiemann <eitschman@nebelreich.de>
Cc: ulli.kroll@googlemail.com; netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Betreff: Re: [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
Hi Andreas,
thanks for digging into this, I have wondered why this happens for a long time but I'm not the best net developer myself.
On Sun, Mar 29, 2026 at 12:05 PM Andreas Haarmann-Thiemann <eitschman@nebelreich.de> wrote:
> diff --git a/drivers/net/ethernet/cortina/gemini.c
> b/drivers/net/ethernet/cortina/gemini.c
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
>
> @@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int budget)
> gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
> if (!gpage) {
> dev_err(geth->dev,
> "could not find mapping\n");
> + if (skb) {
> + napi_free_frags(&port->napi);
> + skb = NULL;
> + }
> port->stats.rx_dropped++;
> continue;
> }
This looks right to me, can you send a proper patch, or provide your Signed-off-by in this thread so I can create a patch from this inline code?
The kernel process requires a "certificate of origin" i.e. Signed-off-by, described a bit down in this document:
https://docs.kernel.org/process/submitting-patches.html
Yours,
Linus Walleij
^ permalink raw reply
* Re: [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Linus Walleij @ 2026-03-29 18:54 UTC (permalink / raw)
To: Andreas Haarmann-Thiemann; +Cc: ulli.kroll, netdev, linux-arm-kernel
In-Reply-To: <006201dcbf63$84593aa0$8d0bafe0$@nebelreich.de>
Hi Andreas,
thanks for digging into this, I have wondered why this happens for a long
time but I'm not the best net developer myself.
On Sun, Mar 29, 2026 at 12:05 PM Andreas Haarmann-Thiemann
<eitschman@nebelreich.de> wrote:
> diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
>
> @@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int budget)
> gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
> if (!gpage) {
> dev_err(geth->dev, "could not find mapping\n");
> + if (skb) {
> + napi_free_frags(&port->napi);
> + skb = NULL;
> + }
> port->stats.rx_dropped++;
> continue;
> }
This looks right to me, can you send a proper patch, or provide your
Signed-off-by in this thread so I can create a patch from this inline code?
The kernel process requires a "certificate of origin" i.e. Signed-off-by,
described a bit down in this document:
https://docs.kernel.org/process/submitting-patches.html
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
From: Russell King (Oracle) @ 2026-03-29 18:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <20260329111123.740bada9@kernel.org>
On Sun, Mar 29, 2026 at 11:11:23AM -0700, Jakub Kicinski wrote:
> On Sat, 28 Mar 2026 21:36:21 +0000 Russell King (Oracle) wrote:
> > Hot off the press from reading various sources of dwmac information,
> > this series attempts to fix the buggy hacks that were previously
> > merged, and clean up the code handling this.
>
> We have a limit of 15 outstanding patches per tree.
> Please follow the community guidelines.
I see that restriction was newly introduced back in January.
> While I have you - you have a significantly negative "reviewer score".
> You post much more than you review. Which should earn you extra 24h
> of delay in our system. I've been trying to ignore that and prioritize
> applying your patches but it'd be great if you could review a bit more.
Sorry, but given the effort that stmmac is taking, I don't have much
capacity to extend mental cycles elsewhere.
This two patch series wouldn't have exploded into ten (or maybe even
more) patches had someone not pointed out the problem with
suspend/resume interacting with disabling TSO... which prompted me to
look deeper and discover a multitude of other problems. Should I
instead ignore these bugs and not bother trying to fix this stuff?
Honestly, I'm getting tired of stmmac with it sucking lots of my time,
and I suspect you're getting tired of the constant stream of patches
for it - but the reason there's a constant stream is because there's
so much that's wrong or broken in this driver.
So either we let the driver rot, or... what?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] net: stmmac: dwmac-rk: Fix typo in comment
From: patchwork-bot+netdevbpf @ 2026-03-29 18:50 UTC (permalink / raw)
To: =?utf-8?b?6LCi6Ie06YKmIChYSUUgWmhpYmFuZykgPFlla2luZ0ByZWQ1NC5jb20+?=
Cc: linux-rockchip, Yeking, heiko, andrew+netdev, davem, edumazet,
kuba, pabeni, mcoquelin.stm32, alexandre.torgue, rmk+kernel,
linux-arm-kernel, netdev, linux-stm32, linux-kernel
In-Reply-To: <tencent_833D2AD6577F21CF38ED1C3FE8814EB4B308@qq.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 28 Mar 2026 13:43:31 +0000 you wrote:
> Correct the typo "rk3520" to "rk3528" in comment.
>
> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with links:
- net: stmmac: dwmac-rk: Fix typo in comment
https://git.kernel.org/netdev/net-next/c/30fcf28d83ee
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
From: Julian Braha @ 2026-03-29 18:30 UTC (permalink / raw)
To: tony, d-gerlach
Cc: daniel.lezcano, tglx, linux, arnd, linux-kernel, linux-omap,
linux-arm-kernel, Julian Braha
The same kconfig 'select OMAP_INTERCONNECT' appears twice for ARCH_OMAP4.
I propose removing the second instance, as it is effectively dead code.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
arch/arm/mach-omap2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 821727eefd5a..f3f19bcfca2c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -42,7 +42,6 @@ config ARCH_OMAP4
select PM if CPU_IDLE
select ARM_ERRATA_754322
select ARM_ERRATA_775420
- select OMAP_INTERCONNECT
config SOC_OMAP5
bool "TI OMAP5"
--
2.51.2
^ permalink raw reply related
* Re: [PATCH net-next 01/10] net: stmmac: fix TSO support when some channels have TBS available
From: Russell King (Oracle) @ 2026-03-29 18:23 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <20260329104223.358351ee@kernel.org>
On Sun, Mar 29, 2026 at 10:42:23AM -0700, Jakub Kicinski wrote:
> On Sun, 29 Mar 2026 10:40:43 +0100 Russell King (Oracle) wrote:
> > On Sat, Mar 28, 2026 at 09:36:41PM +0000, Russell King (Oracle) wrote:
> > > According to the STM32MP25xx manual, which is dwmac v5.3, TBS (time
> > > based scheduling) is not permitted for channels which have hardware
> > > TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and
> > > TBS feature enabling during driver open") concurs with this, but it
> > > is incomplete.
> > >
> > > This commit avoids enabling TSO support on the channels which have
> > > TBS available, which, as far as the hardware is concerned, means we
> > > do not set the TSE bit in the DMA channel's transmit control register.
> > >
> > > However, the net device's features apply to all queues(channels), which
> > > means these channels may still be handed TSO skbs to transmit, and the
> > > driver will pass them to stmmac_tso_xmit(). This will generate the
> > > descriptors for TSO, even though the channel has the TSE bit clear.
> > >
> > > Fix this by checking whether the queue(channel) has TBS available,
> > > and if it does, fall back to software GSO support.
> >
> > This is sufficient for the immediate issue of fixing the patch below,
> > but I think there's another issue that also needs fixing here.
> >
> > TSO requires the hardware to support checksum offload, and there is
> > a comment in the driver:
> >
> > /* DWMAC IPs can be synthesized to support tx coe only for a few tx
> > * queues. In that case, checksum offloading for those queues that don't
> > * support tx coe needs to fallback to software checksum calculation.
> > *
> > * Packets that won't trigger the COE e.g. most DSA-tagged packets will
> > * also have to be checksummed in software.
> > */
> >
> > So, it seems at the very least we need to add a check (in a subsequent
> > patch) for priv->plat->tx_queues_cfg[queue].coe_unsupported to
> > stmmac_channel_tso_permitted().
> >
> > I'm also wondering about the stmmac_has_ip_ethertype() thing, which
> > checks whether the skb can be checksummed by the hardware, and how that
> > interacts with TSO, and whether that's yet another hole that needs
> > plugging.
>
> If the driver "un-advertises" checksum offload accordingly the core
> should automatically clear TSO feature.
Ah, yes, it's in harmonize_features().
However, I think that stmmac_has_ip_ethertype() is tighter than the
checks that harmonize_features() does.
stmmac_has_ip_ethertype():
int depth = 0;
__be16 proto;
proto = __vlan_get_protocol(skb, eth_header_parse_protocol(skb),
&depth);
return (depth <= ETH_HLEN) &&
(proto == htons(ETH_P_IP) || proto == htons(ETH_P_IPV6));
If I'm reading this correctly, then eth_header_parse_protocol(skb)
will return the contents of the ethernet header protocol field.
__vlan_get_protocol() will then return:
- that protocol if it is not a vlan (0x8100 or 0x88A8)
with depth set to skb->mac_len, which should be ETH_HLEN here.
- the protocol below the vlan headers, in which case depth
will be > ETH_HLEN
Unless I've missed something, that basically means that the
__vlan_get_protocol() is pointless there, and the entire function
could just be checking that eth_header_parse_protocol(skb) returns
IP or IPv6.
Isn't it the case that skb->protocol should be the same as
eth_header_parse_protocol(skb) for a packet being transmitted at the
point that .ndo_features_check() or .ndo_start_xmit() is called?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
From: Jakub Kicinski @ 2026-03-29 18:11 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <achJ1dfeT6Q8rBuX@shell.armlinux.org.uk>
On Sat, 28 Mar 2026 21:36:21 +0000 Russell King (Oracle) wrote:
> Hot off the press from reading various sources of dwmac information,
> this series attempts to fix the buggy hacks that were previously
> merged, and clean up the code handling this.
We have a limit of 15 outstanding patches per tree.
Please follow the community guidelines.
While I have you - you have a significantly negative "reviewer score".
You post much more than you review. Which should earn you extra 24h
of delay in our system. I've been trying to ignore that and prioritize
applying your patches but it'd be great if you could review a bit more.
^ permalink raw reply
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Cristian Marussi @ 2026-03-29 18:00 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Cristian Marussi, etienne.carriere, Krzysztof Kozlowski, d-gole,
linux-fsdevel, Conor Dooley, linux-doc, f.fainelli,
vincent.guittot, philip.radford, souvik.chakravarty, peng.fan,
dan.carpenter, lukasz.luba, arm-scmi, sudeep.holla, michal.simek,
linux-kernel, jonathan.cameron, elif.topuz, linux-arm-kernel,
james.quinlan, devicetree, brauner
In-Reply-To: <177480549380.3925363.5137815678176793743.robh@kernel.org>
On Sun, Mar 29, 2026 at 12:31:33PM -0500, Rob Herring (Arm) wrote:
>
> On Sun, 29 Mar 2026 17:33:17 +0100, Cristian Marussi wrote:
> > Add new SCMI v4.0 Telemetry protocol bindings definitions.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > ---
> > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/arm,scmi.example.dtb: scmi (arm,scmi): protocol@19: Unevaluated properties are not allowed ('i2c2-pins', 'keys-pins', 'mdio-pins' were unexpected)
> from schema $id: http://devicetree.org/schemas/firmware/arm,scmi.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260329163337.637393-7-cristian.marussi@arm.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
Yes...the new protocol block definition ended up intermixed with the
previous protocol block...totally wrong.
My bad.
I will fix in V4.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH net-next 01/10] net: stmmac: fix TSO support when some channels have TBS available
From: Jakub Kicinski @ 2026-03-29 17:42 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <acjzmxY9xmBInSwm@shell.armlinux.org.uk>
On Sun, 29 Mar 2026 10:40:43 +0100 Russell King (Oracle) wrote:
> On Sat, Mar 28, 2026 at 09:36:41PM +0000, Russell King (Oracle) wrote:
> > According to the STM32MP25xx manual, which is dwmac v5.3, TBS (time
> > based scheduling) is not permitted for channels which have hardware
> > TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and
> > TBS feature enabling during driver open") concurs with this, but it
> > is incomplete.
> >
> > This commit avoids enabling TSO support on the channels which have
> > TBS available, which, as far as the hardware is concerned, means we
> > do not set the TSE bit in the DMA channel's transmit control register.
> >
> > However, the net device's features apply to all queues(channels), which
> > means these channels may still be handed TSO skbs to transmit, and the
> > driver will pass them to stmmac_tso_xmit(). This will generate the
> > descriptors for TSO, even though the channel has the TSE bit clear.
> >
> > Fix this by checking whether the queue(channel) has TBS available,
> > and if it does, fall back to software GSO support.
>
> This is sufficient for the immediate issue of fixing the patch below,
> but I think there's another issue that also needs fixing here.
>
> TSO requires the hardware to support checksum offload, and there is
> a comment in the driver:
>
> /* DWMAC IPs can be synthesized to support tx coe only for a few tx
> * queues. In that case, checksum offloading for those queues that don't
> * support tx coe needs to fallback to software checksum calculation.
> *
> * Packets that won't trigger the COE e.g. most DSA-tagged packets will
> * also have to be checksummed in software.
> */
>
> So, it seems at the very least we need to add a check (in a subsequent
> patch) for priv->plat->tx_queues_cfg[queue].coe_unsupported to
> stmmac_channel_tso_permitted().
>
> I'm also wondering about the stmmac_has_ip_ethertype() thing, which
> checks whether the skb can be checksummed by the hardware, and how that
> interacts with TSO, and whether that's yet another hole that needs
> plugging.
If the driver "un-advertises" checksum offload accordingly the core
should automatically clear TSO feature.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-03-29 17:36 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
linux-arm-kernel, linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260329-airoha-eth-multi-serdes-v1-0-00f52dc360ca@kernel.org>
On Sun, 29 Mar 2026 15:07:50 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw multiplexer that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Does not apply.
^ 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