* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Suzuki K Poulose @ 2026-06-26 8:47 UTC (permalink / raw)
To: Gavin Shan, Lorenzo Pieralisi
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Marc Zyngier,
Will Deacon, James Morse, Oliver Upton, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <8da87878-2a5d-478a-a280-60dbed7ad1b9@redhat.com>
On 26/06/2026 08:43, Gavin Shan wrote:
> On 6/26/26 1:58 AM, Suzuki K Poulose wrote:
>> On 25/06/2026 14:53, Gavin Shan wrote:
>>> On 6/6/26 12:35 AM, Lorenzo Pieralisi wrote:
>>>> On Fri, Jun 05, 2026 at 06:11:11PM +1000, Gavin Shan wrote:
>>>>> On 6/5/26 5:28 PM, Lorenzo Pieralisi wrote:
>>>>>> On Fri, Jun 05, 2026 at 04:23:15PM +1000, Gavin Shan wrote:
>
> [...]
>
>>>>>
>>>>> I tried to rebase Jean's latest QEMU series [1] to upstream QEMU,
>>>>> and found
>>>>> that memory slots backed by THP are broken. With THP disabled on
>>>>> the host and
>>>>> other fixes (mentioned in my prevous replies) applied on the top of
>>>>> this (v14)
>>>>> series, I'm able to boot a realm guest with rebased QEMU series
>>>>> [2], plus more
>>>>> fxies on the top.
>>>>>
>>>>> [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/
>>>>> latest)
>>>>> [2] https://git.qemu.org/git/qemu.git (branch: cca/
>>>>> gavin)
>>>>>
>>>>> Lorenzo, You may be saying there is someone making QEMU to support
>>>>> ARM/CCA?
>>>>
>>>> Mathieu and I are working on that yes and with Steven/Suzuki to fix
>>>> the THP
>>>> issues you pointed out above.
>>>>
>>>>> If so, I'm not sure if there is a QEMU repository for me to try?
>>>>
>>>> We should be able to submit patches by end of June - we shall let
>>>> you know
>>>> whether we can make something available earlier.
>>>>
>>>
>>> Not sure if there are other known issues in this series. It seems the
>>> stage2
>>> page fault handling on the shared space isn't working well. In my
>>> test, the
>>> vring (struct vring_desc) of virtio-net-pci is updated by the guest,
>>> and the
>>> data isn't seen by QEMU, I'm suspecting if the host-page-frame-number
>>> is properly
>>> resolved in the s2 page fault handler for shared (unprotected) space.
>>>
>>> - I rebased Jean's latest qemu branch to the upstream qemu;
>>>
>>> - On the host, which is emulated by qemu/tcg, the THP (transparent
>>> huge page) is
>>> disabled.
>>>
>>> - On the guest, I can see the virtio vring (struct vring_desc) is
>>> updated. The
>>> S1 page-table entry looks correct because the corresponding
>>> physical address
>>> 0x10046880000 is a sane shared (unprotected) space address.
>>>
>>> [ 52.094143] software IO TLB: Memory encryption is active and
>>> system is using DMA bounce buffers
>>> [ 52.289746] virtqueue_add_desc_split:
>>> desc[0]@0xffff000006880000, [00000100b983f000 00000640 0002 0001]
>>> [ 52.432150] PTE 0x00e8010046880707 at address 0xffff000006880000
>>>
>>> - On the host, the s2 page-table-entry is unmapped due to attribute
>>> transition (private -> shared).
>>> A subsequent S2 page fault is raised against the adress and the s2
>>> page-table-entry is built.
>>>
>>> [ 109.259077] ====> realm_unmap_shared_range:
>>> tracked_unprot_addr=0x10046880000
>>> [ 109.260249] realm_unmap_shared_range: unmapped shared range at
>>> 0x10046880000
>>> [ 109.317786] realm_unmap_shared_range: unmapped shared range at
>>> 0x10046880000
>>> [ 109.629939] ====> kvm_handle_guest_abort:
>>> fault_ipa=0x10046880000, esr=0x92000007
>>> [ 109.630245] realm_map_non_secure: ipa=0x10046880000,
>>> pfn=0xb8b59, size=0x1000, prot=0xf
>>> [ 109.630331] realm_map_non_secure: ipa=0x10046880000,
>>> ipa_top=0x10046881000, flags=0x1e0001, range_desc=0xb8b59004
>>
>> Are you able to correlate the order of the transitions and the Guest
>> access with RMM log ? We haven't seen this from our end. We are aware
>> of permission fault issues with Unprotected IPA when backing the memslot
>> with MAP_PRIVATE areas. But this looks different.
>>
>> Lorenzo, have you run into this ?
>>
>
> It's hard to correlate the order since the logs are collected from two
> separate
> consoles. For the write permission, I add code to the host where the
> permission
> is always added for all s2 page faults in the shared space. Otherwise,
> qemu can
> be killed by -EFAULT or similar error.
This is the problem. We can't add WRITE permission by default. I believe
you may have MAP_PRIVATE mapping and it has to be mapped as READ only
and on a permission fault, we replace it with a writable page. By
overriding the WRITE permission, you let the guest write to a page
that may not be seen by the VMM.
We identified this as a bug in the KVM driver in this series (reported
by Lorenzo) and there is a corresponding tf-RMM change that is required
to get this working. So, please could you wait until the next series
when this will be addressed ? Or you could switch to using MAP_SHARED
for the "shared" memory in the memslot.
Suzuki
>
> There are more findings after more experiments: this virtio-net-pci
> device has 3
> queues or vrings (Rx/Tx/Ctrl). The Rx/Tx/Ctrl queue are populated in
> order one after
> one. In the guest kernel, I intentionally write fixed data
> (0x0123456789abcdef) to
> the first 8 bytes of the queue when it gets populated, and stop the
> guest at random
> points to see if the data is gone. I found that the data written to Rx/
> Tx queue are
> lost after Ctrl queue is allocated.
>
> The data written to Rx/Tx queue is lost if the guest stops (B). The data
> written to
> Rx/Tx queue isn't lost if the guest stops at (A). I can see the pattern
> (0x0123...cdef)
> by dumping the physcial memory through 'pmemsave' command in qemu.
>
> DMA allocation
> ==============
> dma_alloc_coherent
> dma_alloc_attrs
> dma_direct_alloc
> __dma_direct_alloc_pages
> dma_set_decrypted // (A) No data lost if being
> stopped here for the Ctrl queue
> memset(ret, 0, size) // (B) Data lost after being
> stopped after memset() for the Ctrl queue
>
> The memset() on the Ctrl queue should trigger a stage2 page fault. It
> seems the page
> fault enforces the shared pages for Rx/Tx queue to be dropped? I need to
> add more
> debugging code and track it down.
>
>> Suzuki
>>
>>
>>>
>>> - On QEMU, the updated vring (struct vring_desc) at GPA 0x46880000
>>> isn't seen. All the
>>> data in that adress are zeros.
>>>
>>> ====> virtqueue_split_pop: vdev=<virtio-net>, sz=0x38,
>>> queue_index=0x0, vq->vring.num=0x100
>>> virtqueue_split_pop: last_avail_idx=0x0, head=0x0
>>> address_space_read_cached_slow: cache@0xffff1c036440, addr=0x0,
>>> buf=0xffffeee34880, len=0x10
>>> address_space_read_cached_slow: cache: ptr=0x0,
>>> xlat=0x10046880000, len=0x1000, mrs=<realm-dma-region>, is_write=no
>>> address_space_read_cached_slow: translated to mr=<mach-virt.ram>,
>>> mr_addr=0x6880000, l=0x10
>>> flatview_read_continue_step: mr=<mach-virt.ram>,
>>> host=0xffff23e00000, mr_addr=0x6880000, ram_ptr=0xffff2a680000
>>> virtqueue_split_pop: desc: 0000000000000000 - 00000000 - 00000000
>>> - 00000000
>>> qemu-system-aarch64: virtio: zero sized buffers are not allowed
>>>
>>>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Sebastian Andrzej Siewior @ 2026-06-26 8:34 UTC (permalink / raw)
To: Peng Fan
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <aj43FQ7f6juXQ/tP@shlinux89>
On 2026-06-26 16:23:49 [+0800], Peng Fan wrote:
> On Wed, Jun 24, 2026 at 09:44:09AM +0200, Sebastian Andrzej Siewior wrote:
> >On 2026-06-22 19:24:00 [+0800], Peng Fan wrote:
> >> We may need to use atomic API for TXDB_V2. For the patchset itself, it
> >> looks good to me.
> >>
> >> Reviewed-by: Peng Fan <peng.fan@nxp.com>
> >
> >Thank you. Is there anything you want me to do or is this series good
> >as-is?
>
> If you would like to address the AI reported issue further, you may
> update readl_poll_timeout to readl_poll_timeout_atomic.
What about the timeout value? Keep it as-is or reduce to?
> From the fix on error return, this patch is ok to me, and the series is good.
Thanks.
> Thanks,
> Peng
> >
Sebastian
^ permalink raw reply
* Re: [PATCH] ARM: enable interrupts when arm_notify_die() is handling user mode errors
From: Xie Yuanbin @ 2026-06-26 8:29 UTC (permalink / raw)
To: linux, bigeasy, rmk+kernel
Cc: clrkwllms, rostedt, linusw, arnd, linux-arm-kernel, linux-kernel,
linux-rt-devel, liaohua4, lilinjie8, Xie Yuanbin
In-Reply-To: <20260625152159.WtO_S3i7@linutronix.de>
On Thu, 25 Jun 2026 17:21:59 +0200,Sebastian Andrzej Siewior wrote:
> Why would the latter be not appropriate?.
> Anyway, in the kernel case you do die() which disables interrupts as of
> oops_begin(). It does later restore the state in oops_end() and invokes
> make_task_dead(). This one will complain if either preemption or
> interrupts are disabled and reset both.
>
> Should you get that far and not panic() earlier (due to in_interrupt()
> for instance) then interrupts will be later enabled before that kernel
> thread is killed. So it could be done earlier or not, at this point the
> system is pretty much done.
My personal view is as follows: First, an Unhandled kernel fault indicates
that the kernel has encountered an error, which is different from an
Unhandled user fault. An Unhandled user fault can be artificially
constructed by user programs, whereas a healthy kernel, in theory, should
not trigger an Unhandled kernel fault.
When a kernel has already encountered a fault, I think that printing fault
information is more meaningful than improving the kernel's real-time
performance. Imagine this: The interrupts enable here, and at the same
time an interrupt arrives, and then another kernel error is triggered
within the interrupt context. The log would be a disaster.
But no matter what, the above are merely my personal views,
and I respect the maintainer's opinions.
^ permalink raw reply
* RE: [PATCH v3 1/2] i2c: imx: Clear slave pointer on registration error
From: liem @ 2026-06-26 8:30 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa
In-Reply-To: <AM0PR04MB6802B863CD9B9AE1609C1785E8EB2@AM0PR04MB6802.eurprd04.prod.outlook.com>
Hi, carlos!
Thanks for the review.
This is a good idea; this is a better way to fix it.
I'll fix Patch 1 as suggested and send a v4.
Regards,
Liem
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: YinFengwei @ 2026-06-26 8:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Doug Anderson, Petr Mladek, Thomas Gleixner,
Andrew Morton, Baoquan He, Puranjay Mohan, Usama Arif,
Breno Leitao, Julien Thierry, Lecopzer Chen, Sumit Garg,
kernel-team, kexec, linux-arm-kernel, linux-kernel
In-Reply-To: <ajk-Vge2qhaY-TwJ@thinkstation>
Hi Kirill
On Mon, Jun 22, 2026 at 02:56:16PM +0100, Kiryl Shutsemau wrote:
> On Fri, Jun 19, 2026 at 03:26:21PM +0100, Marc Zyngier wrote:
> > > Does your firmware set ICC_CTLR_EL1.PMHE? I'd be curious to see the
> > > numbers if the DSB was omitted on the enable path.
> >
> > I certainly don't observe this sort of overhead on the HW I have
> > access to, and would like to understand where this is coming from with
> > actual profiling data.
>
> Full disclosure: the ~66% figures come from internal testing about a year ago.
> I no longer have the details of the machine it ran on and can't confirm whether
> ICC_CTLR_EL1.PMHE was set there -- it may well have been. I shouldn't have
> carried those numbers forward without being able to stand behind them, so
> please disregard them.
>
> Here are fresh numbers from NVIDIA Grace (Neoverse V2). Importantly, this
> box reports:
>
> GICv3: Pseudo-NMIs enabled using relaxed ICC_PMR_EL1 synchronisation
>
> i.e. PMHE == 0, so the synchronising DSB on the unmask path is already
> patched to a NOP (ARM64_HAS_GIC_PRIO_RELAXED_SYNC). What's left is the
> floor cost of PMR-based masking itself plus the PMR save/restore on
> exception entry/exit -- not the DSB. So this is the case Catalin asked
> about (DSB omitted), and there is still a measurable cost.
>
> A trivial single-threaded gettid() loop (1e6 calls, median of 5,
> performance governor, ASLR off):
>
> pseudo_nmi=0 (DAIF): 178.4 ns/call
> pseudo_nmi=1 (PMR): 252.5 ns/call
> delta: +74.1 ns/call (~230-250 cycles)
> +41.5% wall time / 0.706 throughput
I tested the u-bench.c on a Neoverse N2 based arm64 server. The result
is as following:
pseudo_nmi=0 (DAIF): 96.3 ns/call
pseudo_nmi=1 (PMR): 169.8 ns/call
delta: +73.5 ns/call
>
> --- u-bench.c ---
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <time.h>
> #include <stdio.h>
> int main(void) {
> struct timespec a, b;
> clock_gettime(CLOCK_MONOTONIC, &a);
> for (long i = 0; i < 1000000; i++)
> syscall(SYS_gettid);
> clock_gettime(CLOCK_MONOTONIC, &b);
> printf("%f ns\n", (b.tv_sec-a.tv_sec)*1e9 + (b.tv_nsec-a.tv_nsec));
> return 0;
> }
>
> will-it-scale agrees independently. sched_yield (ops/s, median of 5):
>
> 1 task 72 tasks
> pseudo_nmi=0 3,195,656 230,824,534
> pseudo_nmi=1 2,253,753 163,914,837
> ratio 0.705 0.710
>
> The ratio is flat across the whole 1-to-72 sweep, so -- relevant to the
> scalability question -- it's a constant per-syscall tax, not a contention
> effect. The impact tracks syscall/exception density: page_fault1, a more
> realistic workload, stays within ~5%.
>
> > The direction of travel is to deprecate SDEI. I wouldn't add more stuff
> > on top of this interface.
>
> I understand FEAT_NMI is the long-term answer, and I'm not arguing against
> deprecating SDEI. My concern is the gap in between. By our estimate it's
> 10+ years before the last non-FEAT_NMI machine retires from the fleet --
> for scale, we're still running Skylake today. So there's roughly a
> decade where a large installed base has neither FEAT_NMI nor affordable
> pseudo-NMI, and no way to reach a DAIF-masked CPU for an all-CPU
> backtrace or to capture a wedged CPU in a crash dump. That's the
> functional gap this series tries to cover.
>
> Given the deprecation direction, I deliberately kept the SDEI footprint as
> small as I could. The series adds no new firmware interface and no vendor
> SMC -- it uses only the standard software-signalled event (event 0) via
> SDEI_EVENT_SIGNAL, which is already present on these systems for
> firmware-first RAS (APEI/GHES). And SDEI is only ever invoked in a "bad
> state": to deliver a backtrace signal to a CPU that a normal IPI can't
> reach, or to stop a CPU that ignored the stop IPIs. Nothing on any hot or
> steady-state path touches it.
>
> If even that minimal use is unacceptable on a deprecated interface, I'd
> rather know now and redirect the effort -- but I'd appreciate a pointer to
> what should cover this gap for existing silicon in the meantime.
I couldn't agree more: We need a solution for existing system. And
like to see this patchset merged. Thanks.
Regards
Yin, Fengwei
>
> --
> Kiryl Shutsemau / Kirill A. Shutemov
>
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Lorenzo Bianconi @ 2026-06-26 8:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 12499 bytes --]
> Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> during hardware initialization instead of updating it according to the
> configured MTU. This avoids dropping incoming frames that exceed the
> current MTU but could still be processed by the networking stack, which
> is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> Move the per-port MTU configuration to the PPE egress path where it
> belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> to dynamically track the maximum MTU across running interfaces sharing
> the same PPE instance.
> Fix the PPE MTU register addressing to pack two port entries per
> register word and add WAN_MTU0 configuration for non-LAN GDM devices.
>
> Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
commenting on sashiko's report:
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d%40kernel.org
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 68 ++++++++++---------------------
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +
> drivers/net/ethernet/airoha/airoha_ppe.c | 39 +++++++++++++-----
> drivers/net/ethernet/airoha/airoha_regs.h | 9 ++--
> 4 files changed, 58 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 932b3a3df2e5..3f451c2d4c24 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -178,10 +178,15 @@ static void airoha_fe_maccr_init(struct airoha_eth *eth)
> {
> int p;
>
> - for (p = 1; p <= ARRAY_SIZE(eth->ports); p++)
> + for (p = 1; p <= ARRAY_SIZE(eth->ports); p++) {
> airoha_fe_set(eth, REG_GDM_FWD_CFG(p),
> GDM_TCP_CKSUM_MASK | GDM_UDP_CKSUM_MASK |
> GDM_IP4_CKSUM_MASK | GDM_DROP_CRC_ERR_MASK);
> + airoha_fe_rmw(eth, REG_GDM_LEN_CFG(p),
> + GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> + FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> + FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_RX_SIZE));
> + }
>
> airoha_fe_rmw(eth, REG_CDM_VLAN_CTRL(1), CDM_VLAN_MASK,
> FIELD_PREP(CDM_VLAN_MASK, 0x8100));
> @@ -1831,13 +1836,24 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> spin_unlock(&port->stats_lock);
> }
>
> +static void airoha_dev_set_xmit_frame_size(struct net_device *netdev)
> +{
> + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> +
> + airoha_ppe_set_xmit_frame_size(dev);
> + if (!airoha_is_lan_gdm_dev(dev))
> + airoha_fe_rmw(dev->eth, REG_WAN_MTU0, WAN_MTU0_MASK,
> + FIELD_PREP(WAN_MTU0_MASK,
> + VLAN_ETH_HLEN + netdev->mtu));
> +}
- Could the WAN_MTU0 update here use the same max-across-siblings
aggregation as airoha_ppe_set_xmit_frame_size()?
- This is same issue reported by sashiko-gemini. There is just one WAN device
in the system so we do not need calculate the max MTU here.
> +
> static int airoha_dev_open(struct net_device *netdev)
> {
> - int err, len = ETH_HLEN + netdev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> - u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
> + u32 pse_port = FE_PSE_PORT_PPE1;
> + int err;
>
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
> @@ -1851,19 +1867,7 @@ static int airoha_dev_open(struct net_device *netdev)
> airoha_fe_clear(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
> GDM_STAG_EN_MASK);
>
> - cur_len = airoha_fe_get(qdma->eth, REG_GDM_LEN_CFG(port->id),
> - GDM_LONG_LEN_MASK);
> - if (!port->users || len > cur_len) {
> - /* Opening a sibling net_device with a larger MTU updates the
> - * MTU of already running devices. This is required to allow
> - * multiple net_devices with different MTUs to share the same
> - * GDM port.
> - */
> - airoha_fe_rmw(qdma->eth, REG_GDM_LEN_CFG(port->id),
> - GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> - FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> - FIELD_PREP(GDM_LONG_LEN_MASK, len));
> - }
> + airoha_dev_set_xmit_frame_size(netdev);
> port->users++;
>
> if (!airoha_is_lan_gdm_dev(dev) &&
> @@ -1875,30 +1879,6 @@ static int airoha_dev_open(struct net_device *netdev)
> return 0;
> }
>
> -static void airoha_set_port_mtu(struct airoha_eth *eth,
> - struct airoha_gdm_port *port)
> -{
> - u32 len = 0;
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
> - struct airoha_gdm_dev *dev = port->devs[i];
> - struct net_device *netdev;
> -
> - if (!dev)
> - continue;
> -
> - netdev = netdev_from_priv(dev);
> - if (netif_running(netdev))
> - len = max_t(u32, len, netdev->mtu);
> - }
> - len += ETH_HLEN + ETH_FCS_LEN;
> -
> - airoha_fe_rmw(eth, REG_GDM_LEN_CFG(port->id),
> - GDM_LONG_LEN_MASK,
> - FIELD_PREP(GDM_LONG_LEN_MASK, len));
> -}
> -
> static int airoha_dev_stop(struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> @@ -1909,7 +1889,7 @@ static int airoha_dev_stop(struct net_device *netdev)
> airoha_set_vip_for_gdm_port(dev, false);
>
> if (--port->users)
> - airoha_set_port_mtu(dev->eth, port);
> + airoha_ppe_set_xmit_frame_size(dev);
- On the close path, the call is to airoha_ppe_set_xmit_frame_size()
directly rather than the airoha_dev_set_xmit_frame_size() wrapper.
Does this mean WAN_MTU0 is never refreshed when a WAN dev is closed?
For example, if a small-MTU sibling is closed while a larger-MTU dev
remains running, the PPE MTU register gets recomputed to the larger
value but WAN_MTU0 retains the smaller value written at the last open
or change_mtu.
The commit message states:
set the tx frame size running airoha_ppe_set_xmit_frame_size()
to dynamically track the maximum MTU across running interfaces sharing
the same PPE instance.
Is the asymmetry between PPE MTU (max across siblings) and WAN_MTU0
(per-netdev write) intentional?
- This is same issue reported by sashiko-gemini. There is just one WAN device
in the system so there is no point to update WAN_MTU0 if the WAN device is
stopped.
Regards,
Lorenzo
> else
> airoha_set_gdm_port_fwd_cfg(qdma->eth,
> REG_GDM_FWD_CFG(port->id),
> @@ -1962,10 +1942,6 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
> FIELD_PREP(LPBK_CHAN_MASK, chan) |
> LBK_GAP_MODE_MASK | LBK_LEN_MODE_MASK |
> LBK_CHAN_MODE_MASK | LPBK_EN_MASK);
> - airoha_fe_rmw(eth, REG_GDM_LEN_CFG(AIROHA_GDM2_IDX),
> - GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> - FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> - FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_MTU));
> /* Forward the traffic to the proper GDM port */
> pse_port = port->id == AIROHA_GDM3_IDX ? FE_PSE_PORT_GDM3
> : FE_PSE_PORT_GDM4;
> @@ -2098,7 +2074,7 @@ static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
>
> WRITE_ONCE(netdev->mtu, mtu);
> if (port->users)
> - airoha_set_port_mtu(dev->eth, port);
> + airoha_dev_set_xmit_frame_size(netdev);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index d7ff8c5200e2..0c3fb6e5d7f1 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -23,6 +23,7 @@
> #define AIROHA_MAX_DSA_PORTS 7
> #define AIROHA_MAX_NUM_RSTS 3
> #define AIROHA_MAX_MTU 9220
> +#define AIROHA_MAX_RX_SIZE 16128
> #define AIROHA_MAX_PACKET_SIZE 2048
> #define AIROHA_NUM_QOS_CHANNELS 4
> #define AIROHA_NUM_QOS_QUEUES 8
> @@ -676,6 +677,7 @@ int airoha_get_fe_port(struct airoha_gdm_dev *dev);
> bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> struct airoha_gdm_dev *dev);
>
> +void airoha_ppe_set_xmit_frame_size(struct airoha_gdm_dev *dev);
> void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport);
> bool airoha_ppe_is_enabled(struct airoha_eth *eth, int index);
> void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 42f4b0f21d17..e7c78293002a 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -97,6 +97,33 @@ void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport)
> __field_prep(DFT_CPORT_MASK(fport), fe_cpu_port));
> }
>
> +void airoha_ppe_set_xmit_frame_size(struct airoha_gdm_dev *dev)
> +{
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + int i, ppe_id, index;
> + u32 len = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
> + struct airoha_gdm_dev *d = port->devs[i];
> + struct net_device *netdev;
> +
> + if (!d)
> + continue;
> +
> + netdev = netdev_from_priv(d);
> + if (netif_running(netdev))
> + len = max_t(u32, len, netdev->mtu);
> + }
> + len += VLAN_ETH_HLEN;
> +
> + ppe_id = !airoha_is_lan_gdm_dev(dev) && airoha_ppe_is_enabled(eth, 1);
> + index = port->id == AIROHA_GDM4_IDX ? 7 : port->id;
> + airoha_fe_rmw(eth, REG_PPE_MTU(ppe_id, index),
> + FP_EGRESS_MTU_MASK(index),
> + __field_prep(FP_EGRESS_MTU_MASK(index), len));
> +}
> +
> static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> {
> u32 sram_ppe_num_data_entries = PPE_SRAM_NUM_ENTRIES, sram_num_entries;
> @@ -115,8 +142,6 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> PPE_RAM_NUM_ENTRIES_SHIFT(sram_ppe_num_data_entries);
>
> for (i = 0; i < eth->soc->num_ppe; i++) {
> - int p;
> -
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
>
> @@ -166,15 +191,6 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_fe_wr(eth, REG_PPE_HASH_SEED(i), PPE_HASH_SEED);
> airoha_fe_clear(eth, REG_PPE_PPE_FLOW_CFG(i),
> PPE_FLOW_CFG_IP6_6RD_MASK);
> -
> - for (p = 0; p < ARRAY_SIZE(eth->ports); p++)
> - airoha_fe_rmw(eth, REG_PPE_MTU(i, p),
> - FP0_EGRESS_MTU_MASK |
> - FP1_EGRESS_MTU_MASK,
> - FIELD_PREP(FP0_EGRESS_MTU_MASK,
> - AIROHA_MAX_MTU) |
> - FIELD_PREP(FP1_EGRESS_MTU_MASK,
> - AIROHA_MAX_MTU));
> }
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> @@ -196,6 +212,7 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_ppe_is_enabled(eth, 1);
> fport = airoha_get_fe_port(dev);
> airoha_ppe_set_cpu_port(dev, ppe_id, fport);
> + airoha_ppe_set_xmit_frame_size(dev);
> }
> }
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
> index 436f3c8779c1..6fed63d013b4 100644
> --- a/drivers/net/ethernet/airoha/airoha_regs.h
> +++ b/drivers/net/ethernet/airoha/airoha_regs.h
> @@ -327,9 +327,8 @@
> #define PPE_SRAM_TABLE_EN_MASK BIT(0)
>
> #define REG_PPE_MTU_BASE(_n) (((_n) ? PPE2_BASE : PPE1_BASE) + 0x304)
> -#define REG_PPE_MTU(_m, _n) (REG_PPE_MTU_BASE(_m) + ((_n) << 2))
> -#define FP1_EGRESS_MTU_MASK GENMASK(29, 16)
> -#define FP0_EGRESS_MTU_MASK GENMASK(13, 0)
> +#define REG_PPE_MTU(_m, _n) (REG_PPE_MTU_BASE(_m) + (((_n) / 2) << 2))
> +#define FP_EGRESS_MTU_MASK(_n) GENMASK(13 + (((_n) % 2) << 4), ((_n) % 2) << 4)
>
> #define REG_PPE_RAM_CTRL(_n) (((_n) ? PPE2_BASE : PPE1_BASE) + 0x31c)
> #define PPE_SRAM_CTRL_ACK_MASK BIT(31)
> @@ -377,6 +376,10 @@
> #define REG_SRC_PORT_FC_MAP6 0x2298
> #define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
>
> +#define REG_WAN_MTU0 0x2300
> +#define WAN_MTU1_MASK GENMASK(29, 16)
> +#define WAN_MTU0_MASK GENMASK(13, 0)
> +
> #define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
>
> /* QDMA */
>
> ---
> base-commit: fd1269e454089abda0e4f9e5e25ecd02a90ab009
> change-id: 20260618-airoha-fix-rx-max-len-57654b661646
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Mike Rapoport @ 2026-06-26 8:23 UTC (permalink / raw)
To: Sang-Heon Jeon
Cc: Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Muchun Song, Oscar Salvador, Palmer Dabbelt,
Paul Walmsley, Will Deacon, Alexander Potapenko, Alexandre Ghiti,
Andrey Konovalov, David Hildenbrand, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, linux-mm, linux-riscv, loongarch,
Vincenzo Frascino, WANG Xuerui
In-Reply-To: <20260621145919.1453-1-ekffu200098@gmail.com>
On Sun, Jun 21, 2026 at 11:59:10PM +0900, Sang-Heon Jeon wrote:
> The memblock API guarantees that for_each_mem_range() and
> for_each_mem_pfn_range() never return an invalid range, meaning start is
> always less than end.
>
> Several memblock callers still have unnecessary invalid range checks in
> their loop bodies, so remove them.
>
> Sang-Heon Jeon (6):
> arm64: mm: remove unreachable invalid range check in
> kasan_init_shadow()
> LoongArch: remove unreachable invalid range check in kasan_init()
> riscv: remove unreachable invalid range check in
> create_linear_mapping_page_table()
> riscv: remove unreachable invalid range check in kasan_init()
> mm: remove unnecessary empty range check in
> early_calculate_totalpages()
> mm/hugetlb: remove unnecessary empty range check in
> hugetlb_bootmem_set_nodes()
I queued this for inclusion into memblock tree.
> arch/arm64/mm/kasan_init.c | 3 ---
> arch/loongarch/mm/kasan_init.c | 3 ---
> arch/riscv/mm/init.c | 2 --
> arch/riscv/mm/kasan_init.c | 3 ---
> mm/hugetlb.c | 3 +--
> mm/mm_init.c | 3 +--
> 6 files changed, 2 insertions(+), 15 deletions(-)
>
> --
> 2.43.0
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH 2/2] usb: mtu3: condition PHY wakeup for host mode and runtime suspend
From: Fei Shao @ 2026-06-26 8:21 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Fei Shao, Greg Kroah-Hartman, linux-arm-kernel, linux-kernel,
linux-mediatek, linux-usb
In-Reply-To: <20260626082218.2750459-1-fshao@chromium.org>
Host bus activity during gadget mode system suspend can trigger
unexpected system wakeups via interrupts because PHY wakeup is enabled
unconditionally.
Improve the suspend flow by conditioning PHY wakeup setup on
device_may_wakeup() and restricting it to host mode or runtime suspend
to ensure proper wakeup handling in gadget mode.
Signed-off-by: Fei Shao <fshao@chromium.org>
---
drivers/usb/mtu3/mtu3_plat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index cc8a864dbd63..b4f4c776adb9 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -544,7 +544,8 @@ static int mtu3_suspend_common(struct device *dev, pm_message_t msg)
ssusb_phy_power_off(ssusb);
clk_bulk_disable_unprepare(BULK_CLKS_CNT, ssusb->clks);
- ssusb_wakeup_set(ssusb, true);
+ if (device_may_wakeup(dev) && (ssusb->is_host || PMSG_IS_AUTO(msg)))
+ ssusb_wakeup_set(ssusb, true);
return 0;
sleep_err:
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 1/2] usb: mtu3: allow system suspend during active gadget connection
From: Fei Shao @ 2026-06-26 8:21 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Fei Shao, Greg Kroah-Hartman, linux-arm-kernel, linux-kernel,
linux-mediatek, linux-usb
In-Reply-To: <20260626082218.2750459-1-fshao@chromium.org>
When operating in gadget mode connected to a USB host, system suspend
fails with -EBUSY because active peripheral connections block suspend
entry.
Fix this by restricting the -EBUSY check to runtime autosuspend
(PMSG_IS_AUTO). For system suspend (!PMSG_IS_AUTO), perform soft
disconnect to disconnect from the bus and allow MAC sleep.
Fixes: 427c66422e14 ("usb: mtu3: support suspend/resume for device mode")
Signed-off-by: Fei Shao <fshao@chromium.org>
---
drivers/usb/mtu3/mtu3_core.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index 66dbfe1705d5..a40bf5bad2d5 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -1037,9 +1037,14 @@ int ssusb_gadget_suspend(struct ssusb_mtk *ssusb, pm_message_t msg)
if (!mtu->gadget_driver)
return 0;
- if (mtu->connected)
+ /* Prevent runtime suspend when active connection exists */
+ if (mtu->connected && PMSG_IS_AUTO(msg))
return -EBUSY;
+ /* Perform soft disconnect for system suspend */
+ if (mtu->softconnect && !PMSG_IS_AUTO(msg))
+ mtu3_dev_on_off(mtu, 0);
+
mtu3_dev_suspend(mtu);
synchronize_irq(mtu->irq);
@@ -1055,5 +1060,9 @@ int ssusb_gadget_resume(struct ssusb_mtk *ssusb, pm_message_t msg)
mtu3_dev_resume(mtu);
+ /* Restore soft connect for system resume */
+ if (mtu->softconnect && !PMSG_IS_AUTO(msg))
+ mtu3_dev_on_off(mtu, 1);
+
return 0;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 0/2] usb: mtu3: fix system suspend failure and improve gadget PM
From: Fei Shao @ 2026-06-26 8:21 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Fei Shao, Greg Kroah-Hartman, linux-arm-kernel, linux-kernel,
linux-mediatek, linux-usb
This series resolves system suspend failures and improves power
management in the MediaTek MTU3 USB driver when operating in gadget
mode:
Patch 1 fixes a system suspend failure when connected to a host by
restricting the active connection -EBUSY check to runtime autosuspend
and performing a soft disconnect.
Patch 2 improves PHY wakeup handling by conditioning setup on
device_may_wakeup() and restricting it to host mode or runtime suspend.
Regards,
Fei
Fei Shao (2):
usb: mtu3: allow system suspend during active gadget connection
usb: mtu3: condition PHY wakeup for host mode and runtime suspend
drivers/usb/mtu3/mtu3_core.c | 11 ++++++++++-
drivers/usb/mtu3/mtu3_plat.c | 3 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply
* Re: [PATCH 0/4] module: force sh_addr=0 for arch-specific sections
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Petr Pavlu
Cc: linux-riscv, linux, catalin.marinas, will, geert, pjw, palmer,
aou, samitolvanen, alex, mcgrof, da.gomez, atomlin, joe.lawrence,
linux-arm-kernel, linux-m68k, linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Sami Tolvanen <samitolvanen@google.com>:
On Fri, 27 Mar 2026 08:58:59 +0100 you wrote:
> When linking modules with 'ld.bfd -r', sections defined without an address
> inherit the location counter, resulting in non-zero sh_addr values in the
> resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
> all sections. Non-zero addresses are confusing in this context, typically
> worse compressible, and may cause tools to misbehave [1].
>
> Joe Lawrence previously addressed the same issue in the main
> scripts/module.lds.S file [2] and we discussed that the same fix should be
> also applied to architecture-specific module sections. This series
> implements these changes.
>
> [...]
Here is the summary with links:
- [1/4] module, arm: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/ffe1545ce8a0
- [2/4] module, arm64: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/c5553deb577f
- [3/4] module, m68k: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/9cb4d4dc8227
- [4/4] module, riscv: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/04e17ca3f77e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 0/5] mm/sparse-vmemmap: Provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Muchun Song
Cc: linux-riscv, akpm, david, catalin.marinas, will, palmer, pjw,
chenhuacai, andreas, davem, muchun.song, linux-mm, linux-kernel,
linux-arm-kernel, loongarch, sparclinux, alex, aou, kernel, ljs,
liam, vbabka, rppt, surenb, mhocko
In-Reply-To: <20260601084845.3792171-1-songmuchun@bytedance.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 1 Jun 2026 16:48:39 +0800 you wrote:
> The weak vmemmap_set_pmd() and vmemmap_check_pmd() hooks are
> currently no-ops in the generic code, which leaves architectures that
> need PMD-level handling to open-code the same logic locally.
>
> This series provides generic implementations for both helpers in
> mm/sparse-vmemmap.c. vmemmap_set_pmd() installs a huge PMD with
> PAGE_KERNEL protection, and vmemmap_check_pmd() verifies a present
> leaf PMD before reusing the existing vmemmap_verify() helper.
>
> [...]
Here is the summary with links:
- [v3,1/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
https://git.kernel.org/riscv/c/0b6073ff1574
- [v3,2/5] arm64/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/f521f198b50a
- [v3,3/5] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
- [v3,4/5] loongarch/mm: drop vmemmap_check_pmd helper and use generic code
https://git.kernel.org/riscv/c/ecca7da924b1
- [v3,5/5] sparc/mm: drop vmemmap_check_pmd helper and use generic code
https://git.kernel.org/riscv/c/d3d58e946900
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Muchun Song
Cc: linux-riscv, catalin.marinas, will, chenhuacai, pjw, palmer, aou,
davem, andreas, akpm, david, linux-mm, muchun.song, kernel, alex,
ljs, Liam.Howlett, vbabka, rppt, surenb, mhocko, ryan.roberts,
kevin.brodsky, dev.jain, anshuman.khandual, yang,
chaitanyas.prakash, ptesarik, vishal.moola, junhui.liu,
austin.kim, chengkaitao, willy, alexs, linux-arm-kernel,
linux-kernel, loongarch, sparclinux
In-Reply-To: <20260404122105.3989557-1-songmuchun@bytedance.com>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Sat, 4 Apr 2026 20:20:53 +0800 you wrote:
> The two weak functions vmemmap_set_pmd() and vmemmap_check_pmd() are
> currently no-ops on every architecture, forcing each platform that needs
> them to duplicate the same handful of lines. Provide a generic implementation:
>
> - vmemmap_set_pmd() simply sets a huge PMD with PAGE_KERNEL protection.
>
> - vmemmap_check_pmd() verifies that the PMD is present and leaf,
> then calls the existing vmemmap_verify() helper.
>
> [...]
Here is the summary with links:
- [v2,3/5] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Muchun Song
Cc: linux-riscv, catalin.marinas, will, chenhuacai, pjw, palmer, aou,
davem, andreas, akpm, david, muchun.song, kernel, alex, ljs,
Liam.Howlett, vbabka, rppt, surenb, mhocko, ryan.roberts,
kevin.brodsky, dev.jain, anshuman.khandual, yang,
chaitanyas.prakash, wangyuquan1236, ptesarik, austin.kim,
vishal.moola, junhui.liu, willy, alexs, chengkaitao,
linux-arm-kernel, linux-kernel, loongarch, sparclinux, linux-mm
In-Reply-To: <20260404071720.3577290-1-songmuchun@bytedance.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Sat, 4 Apr 2026 15:17:04 +0800 you wrote:
> The two weak functions vmemmap_set_pmd() and vmemmap_check_pmd() are
> currently no-ops on every architecture, forcing each platform that needs
> them to duplicate the same handful of lines. Provide a generic implementation:
>
> - vmemmap_set_pmd() simply sets a huge PMD with PAGE_KERNEL protection.
>
> - vmemmap_check_pmd() verifies that the PMD is present and leaf,
> then calls the existing vmemmap_verify() helper.
>
> [...]
Here is the summary with links:
- [2/4] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
- [3/5] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Wandun
Cc: linux-riscv, linux-arm-kernel, linux-kernel, loongarch,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, robh, saravanak, akpm,
bhe, rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260527032917.3385849-1-chenwandun1@gmail.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Rob Herring (Arm) <robh@kernel.org>:
On Wed, 27 May 2026 11:29:06 +0800 you wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> On SoCs that carve out large firmware-owned reserved memory (GPU
> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
> those carveouts as part of system RAM even though their contents are
> firmware state that is not useful for kernel crash analysis.
>
> [...]
Here is the summary with links:
- [v3,01/11] of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
https://git.kernel.org/riscv/c/cfba13a18672
- [v3,02/11] kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n
(no matching commit)
- [v3,03/11] of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails
(no matching commit)
- [v3,04/11] of: reserved_mem: zero total_reserved_mem_cnt if no valid /reserved-memory entry
https://git.kernel.org/riscv/c/50a488de5fcc
- [v3,05/11] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late()
(no matching commit)
- [v3,06/11] of: reserved_mem: add dumpable flag to opt-in vmcore
(no matching commit)
- [v3,07/11] of: reserved_mem: save /memreserve/ entries into the reserved_mem array
(no matching commit)
- [v3,08/11] of: reserved_mem: add kdump helpers to exclude non-dumpable regions
(no matching commit)
- [v3,09/11] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
(no matching commit)
- [v3,10/11] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
(no matching commit)
- [v3,11/11] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-riscv, akpm, catalin.marinas, will, ardb, chenhuacai,
kernel, maddy, mpe, npiggin, chleroy, pjw, palmer, aou, alex, hca,
gor, agordeev, borntraeger, svens, tglx, mingo, bp, dave.hansen,
x86, hpa, herbert, dan.j.williams, clm, dsterba, arnd, song,
yukuai, linan122, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260512052230.2947683-2-hch@lst.de>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Tue, 12 May 2026 07:20:41 +0200 you wrote:
> While the RAID6 algorithm could in theory support 3 devices by just
> copying the data disk to the two parity disks, this version is not only
> useless because it is a suboptimal version of 3-way mirroring, but also
> broken with various crashes and incorrect parity generation in various
> architecture-optimized implementations. Disallow it similar to mdraid
> which requires at least 4 devices for RAID 6.
>
> [...]
Here is the summary with links:
- [01/19] btrfs: require at least 4 devices for RAID 6
(no matching commit)
- [02/19] raid6: turn the userspace test harness into a kunit test
(no matching commit)
- [03/19] raid6: remove __KERNEL__ ifdefs
https://git.kernel.org/riscv/c/3d6beb659ddf
- [04/19] raid6: move to lib/raid/
(no matching commit)
- [05/19] raid6: remove unused defines in pq.h
https://git.kernel.org/riscv/c/06d2a66fb7c0
- [06/19] raid6: remove raid6_get_zero_page
https://git.kernel.org/riscv/c/885d31423183
- [07/19] raid6: use named initializers for struct raid6_calls
https://git.kernel.org/riscv/c/7e91f76a9668
- [08/19] raid6: improve the public interface
(no matching commit)
- [09/19] raid6: hide internals
(no matching commit)
- [10/19] raid6: rework the init helpers
(no matching commit)
- [11/19] raid6: use static_call for gen_syndrom and xor_syndrom
https://git.kernel.org/riscv/c/10f4b8e2a164
- [12/19] raid6: use static_call for raid6_recov_2data and raid6_recov_datap
(no matching commit)
- [13/19] raid6: update top of file comments
https://git.kernel.org/riscv/c/30bf04bd13a5
- [14/19] raid6_kunit: use KUNIT_CASE_PARAM
https://git.kernel.org/riscv/c/2175395f76c3
- [15/19] raid6_kunit: dynamically allocate data buffers using vmalloc
https://git.kernel.org/riscv/c/d67c25712fe3
- [16/19] raid6_kunit: cleanup dataptr handling
https://git.kernel.org/riscv/c/562bcbfcb99b
- [17/19] raid6_kunit: randomize parameters and increase limits
(no matching commit)
- [18/19] raid6_kunit: randomize parameters and increase limits
(no matching commit)
- [19/19] raid6_kunit: randomize buffer alignment
https://git.kernel.org/riscv/c/8cf0a6c4bb9e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v9 0/4] Introduce ASPEED AST27xx BMC SoC
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Ryan Chen
Cc: linux-riscv, robh, krzk+dt, conor+dt, joel, andrew,
catalin.marinas, will, arnd, krzk, alexandre.belloni, linusw,
fustini, pjw, palmer, aou, alex, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, soc, conor.dooley
In-Reply-To: <20260609-upstream_ast2700-v9-0-f631752f0cb1@aspeedtech.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Arnd Bergmann <arnd@arndb.de>:
On Tue, 9 Jun 2026 10:47:17 +0800 you wrote:
> This introduces initial support for the Aspeed AST27xx SoC and the AST2700
> Evaluation Board (EVB) to the Linux kernel. The AST27xx is the 8th
> generation Baseboard Management Controller (BMC) SoC from Aspeed,
> featuring improved performance, enhanced security, and expanded I/O
> capabilities compared to previous generations.
>
> AST27xx SOC Family
> - https://www.aspeedtech.com/server_ast2700/
> - https://www.aspeedtech.com/server_ast2720/
> - https://www.aspeedtech.com/server_ast2750/
>
> [...]
Here is the summary with links:
- [v9,1/4] dt-bindings: arm: aspeed: Add AST2700 board compatible
https://git.kernel.org/riscv/c/34efd73379ff
- [v9,2/4] arm64: Kconfig: Add ASPEED SoC family Kconfig support
https://git.kernel.org/riscv/c/df6f379eb4ac
- [v9,3/4] arm64: dts: aspeed: Add initial AST27xx SoC device tree
https://git.kernel.org/riscv/c/e77bb5dc5759
- [v9,4/4] arm64: configs: Update defconfig for AST2700 platform support
https://git.kernel.org/riscv/c/512cef2af615
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 01/18] raid6: turn the userspace test harness into a kunit test
From: patchwork-bot+linux-riscv @ 2026-06-26 8:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-riscv, akpm, catalin.marinas, will, ardb, chenhuacai,
kernel, maddy, mpe, npiggin, chleroy, pjw, palmer, aou, alex, hca,
gor, agordeev, borntraeger, svens, tglx, mingo, bp, dave.hansen,
x86, hpa, herbert, dan.j.williams, clm, dsterba, arnd, song,
yukuai, linan122, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260518051804.462141-2-hch@lst.de>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 18 May 2026 07:17:44 +0200 you wrote:
> Currently the raid6 code can be compiled as userspace code to run the
> test suite. Convert that to be a kunit case with minimal changes to
> avoid mutating global state so that we can drop this requirement.
>
> Note that this is not a good kunit test case yet and will need a lot more
> work, but that is deferred until the raid6 code is moved to it's new
> place, which is easier if the userspace makefile doesn't need adjustments
> for the new location first.
>
> [...]
Here is the summary with links:
- [01/18] raid6: turn the userspace test harness into a kunit test
https://git.kernel.org/riscv/c/c4697486fc23
- [02/18] raid6: remove __KERNEL__ ifdefs
https://git.kernel.org/riscv/c/3d6beb659ddf
- [03/18] raid6: move to lib/raid/
https://git.kernel.org/riscv/c/3626738bc714
- [04/18] raid6: remove unused defines in pq.h
https://git.kernel.org/riscv/c/06d2a66fb7c0
- [05/18] raid6: remove raid6_get_zero_page
https://git.kernel.org/riscv/c/885d31423183
- [06/18] raid6: use named initializers for struct raid6_calls
https://git.kernel.org/riscv/c/7e91f76a9668
- [07/18] raid6: improve the public interface
https://git.kernel.org/riscv/c/35472bc6f31b
- [08/18] raid6: warn when using less than four devices
https://git.kernel.org/riscv/c/2790045a62eb
- [09/18] raid6: hide internals
(no matching commit)
- [10/18] raid6: rework registration of optimized algorithms
(no matching commit)
- [11/18] raid6: use static_call for gen_syndrom and xor_syndrom
https://git.kernel.org/riscv/c/10f4b8e2a164
- [12/18] raid6: use static_call for raid6_recov_2data and raid6_recov_datap
https://git.kernel.org/riscv/c/dd83de0341da
- [13/18] raid6: update top of file comments
https://git.kernel.org/riscv/c/30bf04bd13a5
- [14/18] raid6_kunit: use KUNIT_CASE_PARAM
https://git.kernel.org/riscv/c/2175395f76c3
- [15/18] raid6_kunit: dynamically allocate data buffers using vmalloc
https://git.kernel.org/riscv/c/d67c25712fe3
- [16/18] raid6_kunit: cleanup dataptr handling
https://git.kernel.org/riscv/c/562bcbfcb99b
- [17/18] raid6_kunit: randomize parameters and increase limits
https://git.kernel.org/riscv/c/fa0c812c0aa5
- [18/18] raid6_kunit: randomize buffer alignment
https://git.kernel.org/riscv/c/8cf0a6c4bb9e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 1/7] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Ian Rogers
Cc: linux-riscv, acme, adrian.hunter, dapeng1.mi, james.clark,
namhyung, florian.fainelli, guanli.oerv, 9erthalion6, alex,
alexander.shishkin, andrew.jones, aou, atrajeev, howardchu95,
john.g.garry, jolsa, leo.yan, libunwind-devel, linux-arm-kernel,
linux-kernel, linux-perf-users, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will
In-Reply-To: <20260513233151.572332-2-irogers@google.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Arnaldo Carvalho de Melo <acme@redhat.com>:
On Wed, 13 May 2026 16:31:45 -0700 you wrote:
> Currently, both libdw and libunwind define 'unwind__get_entries'. This
> causes a duplicate symbol build failure when both are compiled into
> perf.
>
> This commit refactors the DWARF unwind post-processing to be
> configurable at runtime via the .perfconfig file option
> 'unwind.style', or using the argument '--unwind-style' in the commands
> 'perf report', 'perf script' and 'perf inject', in a similar manner to
> the addr2line or the disassembler style.
>
> [...]
Here is the summary with links:
- [v5,1/7] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
(no matching commit)
- [v5,2/7] tools build: Deduplicate test-libunwind for different architectures
https://git.kernel.org/riscv/c/6d13d53be9dd
- [v5,3/7] perf build: Be more programmatic when setting up libunwind variables
https://git.kernel.org/riscv/c/444508cd7c7b
- [v5,4/7] perf unwind-libunwind: Make libunwind register reading cross platform
(no matching commit)
- [v5,5/7] perf unwind-libunwind: Move flush/finish access out of local
https://git.kernel.org/riscv/c/2723e9f8b5cf
- [v5,6/7] perf unwind-libunwind: Remove libunwind-local
(no matching commit)
- [v5,7/7] perf unwind-libunwind: Add RISC-V libunwind support
https://git.kernel.org/riscv/c/834c557167a9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 0/6] power: Use named initializers for platform_device_id arrays
From: patchwork-bot+linux-riscv @ 2026-06-26 8:20 UTC (permalink / raw)
To: =?utf-8?q?Uwe_Kleine-K=C3=B6nig_=28The_Capable_Hub=29_=3Cu=2Ekleine-koenig?=,
=?utf-8?q?=40baylibre=2Ecom=3E?=
Cc: linux-riscv, sre, visitorckw, bleung, groeck, linux, krzk,
matthias.bgg, angelogioacchino.delregno, linux-pm, linux-kernel,
chrome-platform, linux-arm-kernel, linux-mediatek, hansg,
m.szyprowski, sebastian.krzyszkowiak, kernel, dlan, andreas,
mazziesaccount, sven, j, neal, amitsd, samkay014, spacemit, asahi,
imx, wens
In-Reply-To: <cover.1780048925.git.u.kleine-koenig@baylibre.com>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Sebastian Reichel <sebastian.reichel@collabora.com>:
On Fri, 29 May 2026 12:18:15 +0200 you wrote:
> Hello,
>
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> [...]
Here is the summary with links:
- [v1,4/6] power: Use named initializers for platform_device_id arrays
https://git.kernel.org/riscv/c/e28f7498dd81
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-26 8:23 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <20260624074409.5jwpWs61@linutronix.de>
On Wed, Jun 24, 2026 at 09:44:09AM +0200, Sebastian Andrzej Siewior wrote:
>On 2026-06-22 19:24:00 [+0800], Peng Fan wrote:
>> We may need to use atomic API for TXDB_V2. For the patchset itself, it
>> looks good to me.
>>
>> Reviewed-by: Peng Fan <peng.fan@nxp.com>
>
>Thank you. Is there anything you want me to do or is this series good
>as-is?
If you would like to address the AI reported issue further, you may
update readl_poll_timeout to readl_poll_timeout_atomic.
From the fix on error return, this patch is ok to me, and the series is good.
Thanks,
Peng
>
>Sebastian
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Lorenzo Bianconi @ 2026-06-26 8:18 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 12249 bytes --]
> Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> during hardware initialization instead of updating it according to the
> configured MTU. This avoids dropping incoming frames that exceed the
> current MTU but could still be processed by the networking stack, which
> is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> Move the per-port MTU configuration to the PPE egress path where it
> belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> to dynamically track the maximum MTU across running interfaces sharing
> the same PPE instance.
> Fix the PPE MTU register addressing to pack two port entries per
> register word and add WAN_MTU0 configuration for non-LAN GDM devices.
commenting on sashiko's report:
https://sashiko.dev/#/patchset/20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d%40kernel.org
>
> Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 68 ++++++++++---------------------
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +
> drivers/net/ethernet/airoha/airoha_ppe.c | 39 +++++++++++++-----
> drivers/net/ethernet/airoha/airoha_regs.h | 9 ++--
> 4 files changed, 58 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 932b3a3df2e5..3f451c2d4c24 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -178,10 +178,15 @@ static void airoha_fe_maccr_init(struct airoha_eth *eth)
> {
> int p;
>
> - for (p = 1; p <= ARRAY_SIZE(eth->ports); p++)
> + for (p = 1; p <= ARRAY_SIZE(eth->ports); p++) {
> airoha_fe_set(eth, REG_GDM_FWD_CFG(p),
> GDM_TCP_CKSUM_MASK | GDM_UDP_CKSUM_MASK |
> GDM_IP4_CKSUM_MASK | GDM_DROP_CRC_ERR_MASK);
> + airoha_fe_rmw(eth, REG_GDM_LEN_CFG(p),
> + GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> + FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> + FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_RX_SIZE));
> + }
>
> airoha_fe_rmw(eth, REG_CDM_VLAN_CTRL(1), CDM_VLAN_MASK,
> FIELD_PREP(CDM_VLAN_MASK, 0x8100));
> @@ -1831,13 +1836,24 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> spin_unlock(&port->stats_lock);
- This is a pre-existing issue, but can the spin_lock() used in
airoha_update_hw_stats() cause a deadlock?
If a process context holds port->stats_lock via spin_lock() and is preempted
by a networking softirq on the same CPU that calls dev_get_stats()
(which invokes ndo_get_stats64 -> airoha_update_hw_stats()), will the softirq
spin forever trying to acquire the same lock? Should this use spin_lock_bh()
instead?
- The reported issue has not been introduced by this patch. Moreover, I do
not think this is a real problem since in the current codebase
airoha_update_hw_stats() is always run in process context and not in-irq
context.
> }
>
> +static void airoha_dev_set_xmit_frame_size(struct net_device *netdev)
> +{
> + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> +
> + airoha_ppe_set_xmit_frame_size(dev);
> + if (!airoha_is_lan_gdm_dev(dev))
> + airoha_fe_rmw(dev->eth, REG_WAN_MTU0, WAN_MTU0_MASK,
> + FIELD_PREP(WAN_MTU0_MASK,
> + VLAN_ETH_HLEN + netdev->mtu));
> +}
- Does this unconditional write to REG_WAN_MTU0 break sibling network devices
sharing the same WAN port?
If multiple interfaces share the same hardware port, this appears to overwrite
the shared register using only the current interface's MTU, ignoring the
maximum MTU of any active sibling interfaces. Could this cause the hardware to
drop frames for sibling interfaces if their MTU is larger than the most
recently configured interface?
- This is not a real issue since we can have at most a single WAN port in the
system
> +
> static int airoha_dev_open(struct net_device *netdev)
> {
> - int err, len = ETH_HLEN + netdev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> - u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
> + u32 pse_port = FE_PSE_PORT_PPE1;
> + int err;
>
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
[...]
> static int airoha_dev_stop(struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> @@ -1909,7 +1889,7 @@ static int airoha_dev_stop(struct net_device *netdev)
> airoha_set_vip_for_gdm_port(dev, false);
>
> if (--port->users)
> - airoha_set_port_mtu(dev->eth, port);
> + airoha_ppe_set_xmit_frame_size(dev);
- Does this stop path fail to update the WAN MTU limit?
When an interface is stopped, airoha_ppe_set_xmit_frame_size() recalculates
the PPE MTU, but it looks like the global REG_WAN_MTU0 register is not updated
here. Will this prevent the MTU limit from correctly shrinking when an
interface is brought down?
- This is not a real issue since, as pointed out above, we can have at most a
single WAN port in the system, so there is no point to reconfigure
REG_WAN_MTU0 if this interface is stopped.
> else
> airoha_set_gdm_port_fwd_cfg(qdma->eth,
> REG_GDM_FWD_CFG(port->id),
> @@ -1962,10 +1942,6 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
> FIELD_PREP(LPBK_CHAN_MASK, chan) |
> LBK_GAP_MODE_MASK | LBK_LEN_MODE_MASK |
> LBK_CHAN_MODE_MASK | LPBK_EN_MASK);
> - airoha_fe_rmw(eth, REG_GDM_LEN_CFG(AIROHA_GDM2_IDX),
> - GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> - FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> - FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_MTU));
> /* Forward the traffic to the proper GDM port */
> pse_port = port->id == AIROHA_GDM3_IDX ? FE_PSE_PORT_GDM3
> : FE_PSE_PORT_GDM4;
> @@ -2098,7 +2074,7 @@ static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
>
> WRITE_ONCE(netdev->mtu, mtu);
> if (port->users)
> - airoha_set_port_mtu(dev->eth, port);
> + airoha_dev_set_xmit_frame_size(netdev);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index d7ff8c5200e2..0c3fb6e5d7f1 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -23,6 +23,7 @@
> #define AIROHA_MAX_DSA_PORTS 7
> #define AIROHA_MAX_NUM_RSTS 3
> #define AIROHA_MAX_MTU 9220
> +#define AIROHA_MAX_RX_SIZE 16128
> #define AIROHA_MAX_PACKET_SIZE 2048
> #define AIROHA_NUM_QOS_CHANNELS 4
> #define AIROHA_NUM_QOS_QUEUES 8
> @@ -676,6 +677,7 @@ int airoha_get_fe_port(struct airoha_gdm_dev *dev);
> bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> struct airoha_gdm_dev *dev);
>
> +void airoha_ppe_set_xmit_frame_size(struct airoha_gdm_dev *dev);
> void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport);
> bool airoha_ppe_is_enabled(struct airoha_eth *eth, int index);
> void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 42f4b0f21d17..e7c78293002a 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -97,6 +97,33 @@ void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport)
> __field_prep(DFT_CPORT_MASK(fport), fe_cpu_port));
> }
>
> +void airoha_ppe_set_xmit_frame_size(struct airoha_gdm_dev *dev)
> +{
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + int i, ppe_id, index;
> + u32 len = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
> + struct airoha_gdm_dev *d = port->devs[i];
> + struct net_device *netdev;
> +
> + if (!d)
> + continue;
> +
> + netdev = netdev_from_priv(d);
> + if (netif_running(netdev))
> + len = max_t(u32, len, netdev->mtu);
> + }
> + len += VLAN_ETH_HLEN;
> +
> + ppe_id = !airoha_is_lan_gdm_dev(dev) && airoha_ppe_is_enabled(eth, 1);
> + index = port->id == AIROHA_GDM4_IDX ? 7 : port->id;
> + airoha_fe_rmw(eth, REG_PPE_MTU(ppe_id, index),
> + FP_EGRESS_MTU_MASK(index),
> + __field_prep(FP_EGRESS_MTU_MASK(index), len));
- Does this leave the egress MTU limit uninitialized for other PPE engines?
The patch removes the loop in airoha_ppe_hw_init() that previously initialized
REG_PPE_MTU for all ports on all available PPEs. This function now only
configures it for a single ppe_id.
During cross-PPE routing (such as WAN-to-LAN), if PPE1 (WAN) forwards a packet
to a LAN port, it will check REG_PPE_MTU(1, LAN_port). Since this register was
only configured for PPE0, will the uninitialized limit (0) cause the packet to
be dropped?
- This is not a real issue since every airoha_gdm_dev/net_device is
associated to a PPE engine/QDMA according to the logic in
airoha_dev_open()/airoha_dev_set_qdma(). The other PPE engine's MTU will be
updated according to the assigned net_device.
Regards,
Lorenzo
> +}
> +
> static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> {
> u32 sram_ppe_num_data_entries = PPE_SRAM_NUM_ENTRIES, sram_num_entries;
> @@ -115,8 +142,6 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> PPE_RAM_NUM_ENTRIES_SHIFT(sram_ppe_num_data_entries);
>
> for (i = 0; i < eth->soc->num_ppe; i++) {
> - int p;
> -
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
>
> @@ -166,15 +191,6 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_fe_wr(eth, REG_PPE_HASH_SEED(i), PPE_HASH_SEED);
> airoha_fe_clear(eth, REG_PPE_PPE_FLOW_CFG(i),
> PPE_FLOW_CFG_IP6_6RD_MASK);
> -
> - for (p = 0; p < ARRAY_SIZE(eth->ports); p++)
> - airoha_fe_rmw(eth, REG_PPE_MTU(i, p),
> - FP0_EGRESS_MTU_MASK |
> - FP1_EGRESS_MTU_MASK,
> - FIELD_PREP(FP0_EGRESS_MTU_MASK,
> - AIROHA_MAX_MTU) |
> - FIELD_PREP(FP1_EGRESS_MTU_MASK,
> - AIROHA_MAX_MTU));
> }
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> @@ -196,6 +212,7 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_ppe_is_enabled(eth, 1);
> fport = airoha_get_fe_port(dev);
> airoha_ppe_set_cpu_port(dev, ppe_id, fport);
> + airoha_ppe_set_xmit_frame_size(dev);
> }
> }
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
> index 436f3c8779c1..6fed63d013b4 100644
> --- a/drivers/net/ethernet/airoha/airoha_regs.h
> +++ b/drivers/net/ethernet/airoha/airoha_regs.h
> @@ -327,9 +327,8 @@
> #define PPE_SRAM_TABLE_EN_MASK BIT(0)
>
> #define REG_PPE_MTU_BASE(_n) (((_n) ? PPE2_BASE : PPE1_BASE) + 0x304)
> -#define REG_PPE_MTU(_m, _n) (REG_PPE_MTU_BASE(_m) + ((_n) << 2))
> -#define FP1_EGRESS_MTU_MASK GENMASK(29, 16)
> -#define FP0_EGRESS_MTU_MASK GENMASK(13, 0)
> +#define REG_PPE_MTU(_m, _n) (REG_PPE_MTU_BASE(_m) + (((_n) / 2) << 2))
> +#define FP_EGRESS_MTU_MASK(_n) GENMASK(13 + (((_n) % 2) << 4), ((_n) % 2) << 4)
>
> #define REG_PPE_RAM_CTRL(_n) (((_n) ? PPE2_BASE : PPE1_BASE) + 0x31c)
> #define PPE_SRAM_CTRL_ACK_MASK BIT(31)
> @@ -377,6 +376,10 @@
> #define REG_SRC_PORT_FC_MAP6 0x2298
> #define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
>
> +#define REG_WAN_MTU0 0x2300
> +#define WAN_MTU1_MASK GENMASK(29, 16)
> +#define WAN_MTU0_MASK GENMASK(13, 0)
> +
> #define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
>
> /* QDMA */
>
> ---
> base-commit: fd1269e454089abda0e4f9e5e25ecd02a90ab009
> change-id: 20260618-airoha-fix-rx-max-len-57654b661646
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Pandey, Radhey Shyam @ 2026-06-26 8:10 UTC (permalink / raw)
To: Alex Bereza, Vinod Koul, Frank Li, Michal Simek,
Geert Uytterhoeven, Ulf Hansson, Arnd Bergmann, Tony Lindgren,
Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Suraj Gupta, Frank Li
In-Reply-To: <DJITDJYQEOPN.I0S9T54IS104@bereza.email>
On 6/26/2026 1:18 PM, Alex Bereza wrote:
> Hi, could it be that this patch was forgotten? I still can't find it in
> dmaengine tree. Is there anything I should do? It still applies cleanly
> to dmaengine/fixes.
>
I see both the patches are reviewed. So let's wait for Vinod.
Thanks,
Radhey
^ permalink raw reply
* Re: [PATCH] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-26 8:09 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260626080422.4191435-1-christianshewitt@gmail.com>
> On 26 Jun 2026, at 12:04 pm, Christian Hewitt <christianshewitt@gmail.com> wrote:
>
> The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
> AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
> vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
> it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
> producing the "machine gun noise" buffer underrun - on start when switching
> outputs, and on stop when playback ends. The latter is audible on devices
> with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>
> The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
> both enable and disable (audio_hw_958_enable), and when reconfiguring
> (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
> reset before enabling the DCU on start, and after disabling it on stop.
Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support”)
^ I can send a v2 with it done properly if needed?
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> sound/soc/meson/aiu-fifo-spdif.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/sound/soc/meson/aiu-fifo-spdif.c b/sound/soc/meson/aiu-fifo-spdif.c
> index e0e00ec026dc..826055a71421 100644
> --- a/sound/soc/meson/aiu-fifo-spdif.c
> +++ b/sound/soc/meson/aiu-fifo-spdif.c
> @@ -24,6 +24,7 @@
> #define AIU_MEM_IEC958_CONTROL_MODE_16BIT BIT(7)
> #define AIU_MEM_IEC958_CONTROL_MODE_LINEAR BIT(8)
> #define AIU_MEM_IEC958_BUF_CNTL_INIT BIT(0)
> +#define AIU_RST_SOFT_958_FAST BIT(2)
>
> #define AIU_FIFO_SPDIF_BLOCK 8
>
> @@ -68,12 +69,16 @@ static int fifo_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + snd_soc_component_write(component, AIU_RST_SOFT,
> + AIU_RST_SOFT_958_FAST);
> fifo_spdif_dcu_enable(component, true);
> break;
> case SNDRV_PCM_TRIGGER_SUSPEND:
> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> case SNDRV_PCM_TRIGGER_STOP:
> fifo_spdif_dcu_enable(component, false);
> + snd_soc_component_write(component, AIU_RST_SOFT,
> + AIU_RST_SOFT_958_FAST);
> break;
> default:
> return -EINVAL;
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support
From: Icenowy Zheng @ 2026-06-26 8:05 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
在 2026-06-25四的 17:44 +0800，Joey Lu写道：
> This series adds support for the Verisilicon DCUltraLite display
> controller as integrated in the Nuvoton MA35D1 SoC.
>
> The Verisilicon DC driver and its DT binding were originally written
> by
> Icenowy Zheng <zhengxingda@iscas.ac.cn> for the T-Head TH1520 SoC,
> which
> carries a DC8200 IP block. The present series builds on that
> foundation
> with gratitude to Icenowy for the original work.
>
> The DCUltraLite is a different variant in the DC IP family. While
> the two
> IPs share a broadly similar register layout, a number of differences
> prevent the existing driver from working on the MA35D1 without
> modification:
>
> - No CONFIG_EX commit path: the DC8200 staging registers
> (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
> PANEL_CONFIG_EX) are absent. The DCUltraLite uses enable (bit 0)
> and
> reset (bit 4) bits in FB_CONFIG for direct framebuffer updates,
> and
> requires a per-frame VALID bit toggle (FB_CONFIG bit 3) to latch
> configuration changes.
>
> - No PANEL_START register: panel output begins when
> PANEL_CONFIG.RUNNING is set; the DC8200 multi-display sync start
> register at 0x1CCC does not exist.
>
> - Different IRQ registers: DISP_IRQ_STA at 0x147C / DISP_IRQ_EN at
> 0x1480, versus the DC8200's TOP_IRQ_ACK at 0x0010 / TOP_IRQ_EN at
> 0x0014.
>
> - Simpler clock topology: two clocks ("core" bus gate and "pix0"
> pixel
> divider); no axi or ahb clocks required.
>
> - Single display output: no per-output indexing beyond index 0 is
> needed.
>
> - Hardware-discoverable identity: the DCUltraLite exposes chip
> identity
> registers whose model field reads 0x0 (revision 0x5560,
> customer_id 0x305), allowing the existing vs_fill_chip_identity()
> path to identify the variant purely through register reads.
>
> Patch 1 generalises the verisilicon,dc DT binding to accommodate the
> Nuvoton MA35D1 SoC-specific compatible and the variant's two-clock,
> one-reset, single-port topology.
>
> Patch 2 adds the register-level macros needed by the DC8000 ops.
>
> Patches 3-5 introduce the driver changes in three logical steps: the
> vs_dc_funcs hardware ops vtable with DC8200 ops extracted into
> vs_dc8200.c; making axi/ahb clocks optional as a separate atomic
> change;
> and the DC8000 ops in vs_dc8000.c. Patch 6 adds the DCUltraLite HWDB
> entry that gates hardware recognition once all support is in place.
>
> Patch 7 adds the Kconfig dependency on ARCH_MA35, placed last because
> it
> is only meaningful after the HWDB entry is added.
>
> All patches have been tested on Nuvoton MA35D1 hardware.
I also tested these patches on TH1520, and it seems to show no
regression.
Thanks,
Icenowy
>
> Changes from v4:
> - [dt-bindings] Kept clock and reset item descriptions in the
> global
> clocks:/resets: properties; per-compatible sections only
> constrain
> minItems/maxItems and override clock-names items for
> nuvoton,ma35d1-dcu.
> - [dt-bindings] Dropped redundant global minItems/maxItems on
> clocks:
> and clock-names:.
> - [dt-bindings] Dropped the extra-space typo fix in port@0
> description
> to keep the patch atomic; left for a separate patch later.
> - [ops] Renamed crtc_enable/crtc_disable hooks to crtc_enable_ex/
> crtc_disable_ex.
> - [ops] Added unified IRQ bit definitions; each irq_ack()
> implementation
> now translates hardware-specific bits before returning.
> - [clocks] Split the axi/ahb optional-clock change into its own
> patch
> for atomicity.
> - [hwdb] Simplified the commit message for patch 6.
> - [kconfig] Simplified the commit message for patch 7.
>
> Joey Lu (7):
> dt-bindings: display: verisilicon,dc: generalize for single-output
> variants
> drm/verisilicon: add register-level macros for DC8000
> drm/verisilicon: introduce per-variant hardware ops table
> drm/verisilicon: make axi and ahb clocks optional
> drm/verisilicon: add DC8000 (DCUltraLite) display controller
> support
> drm/verisilicon: add DCUltraLite chip identity to HWDB
> drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
>
> .../bindings/display/verisilicon,dc.yaml | 57 +++++++++
> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
> drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
> drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dc.c | 13 +-
> drivers/gpu/drm/verisilicon/vs_dc.h | 33 +++++
> drivers/gpu/drm/verisilicon/vs_dc8000.c | 86 +++++++++++++
> drivers/gpu/drm/verisilicon/vs_dc8200.c | 115
> ++++++++++++++++++
> drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
> drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 14 +++
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
> .../drm/verisilicon/vs_primary_plane_regs.h | 3 +
> 16 files changed, 378 insertions(+), 57 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
^ 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