It looks like VRX518 returns phys addr of data buffer in the 'data_ptr'
field of the RX descriptor and an actual data offset within the buffer
in the 'byte_off' field. In order to map the phys address back to
virtual we need the original phys address of the allocated buffer.
In the same driver applies offset to phys address before the mapping,
what leads to WARN_ON triggering in plat_mem_virt() function with
subsequent kernel panic:
WARNING: CPU: 0 PID: 0 at .../sw_plat.c:764 0xbf306cd0 [vrx518_tc@
8af9f5d0+0x25000]
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd =
aff5701e
[
00000000] *pgd=
00000000
Internal error: Oops: 5 [#1] SMP ARM
Noticed in ATM mode, when chip always returns byte_off = 4.
In order to fix the issue, pass the phys address to plat_mem_virt() as
is and apply byte_off later for proper DMA syncing and on mapped virtual
address when copying RXed data into the skb.
Run tested with FRITZ!Box 7530 on both ADSL and VDSL (thanks Jan) links.
Fixes: 474bbe23b7 ("kernel: add Intel/Lantiq VRX518 TC driver")
Tested-by: Jan Hoffmann <jan@3e8.eu> # VDSL link
Reported-and-tested-by: nebibigon93@yandex.ru # ADSL link
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250122222654.21833-2-ryazanov.s.a@gmail.com/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
- continue;
+
+ // this seems to be a pointer to a DS PKT buffer
-+ phyaddr = desc->data_ptr + desc->byte_off;
++ phyaddr = desc->data_ptr;
+ ptr = plat_mem_virt(phyaddr);
-+
+ len = desc->data_len;
+
-+ dma_sync_single_range_for_cpu(pdev, phyaddr, 0, len, DMA_FROM_DEVICE);
++ dma_sync_single_for_cpu(pdev, phyaddr, desc->byte_off + len,
++ DMA_FROM_DEVICE);
+
+ skb = netdev_alloc_skb(g_plat_priv->netdev, len);
+ if (unlikely(!skb)) {
- ring_idx_inc(rxout, idx);
+
+ dst = skb_put(skb, len);
-+ memcpy(dst, ptr, len);
++ memcpy(dst, ptr + desc->byte_off, len);
+
+ priv->tc_ops.recv(g_plat_priv->netdev, skb);
+