On 18.01.2025 22:18, Hauke Mehrtens wrote:
On 1/12/25 15:09, Sergey Ryazanov wrote:
ATM TC layer have some issues which effectively prevent VRX518 from
being used as ADSL modem. Specifically, there one crash during the ATM
layer configuration and wrong PVC ID selection on packet receiving what
breaks RX path. Fix both of the issues. Make subif iface registration
optional to prevent the crash (see more details in the new patch) and
update the hardcoded PVC ID to match the first allocated channel.
Run tested with FRITZ!Box 7530.
Fixes: 474bbe23b7 ("kernel: add Intel/Lantiq VRX518 TC driver")
Reported-and-tested-by: nebibigo...@yandex.ru
Signed-off-by: Sergey Ryazanov <ryazanov....@gmail.com>
---
.../lantiq/vrx518_tc/patches/100-compat.patch | 2 +-
...tm_tc-fix-crash-on-subif_reg-absence.patch | 75 +++++++++++++++++++
2 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 package/kernel/lantiq/vrx518_tc/patches/207-dcdp-
atm_tc-fix-crash-on-subif_reg-absence.patch
diff --git a/package/kernel/lantiq/vrx518_tc/patches/100-compat.patch
b/package/kernel/lantiq/vrx518_tc/patches/100-compat.patch
index d04c1ed5df..81e32369ba 100644
--- a/package/kernel/lantiq/vrx518_tc/patches/100-compat.patch
+++ b/package/kernel/lantiq/vrx518_tc/patches/100-compat.patch
@@ -166,7 +166,7 @@
- return (skb->DW0 >> 3) & 0xF;
+// return (skb->DW0 >> 3) & 0xF;
-+ return 1;
++ return 0; /* We use only one connection for now, so return
the first connection id */
}
static int atm_get_qid_by_vcc(struct net_device *dev, struct
sk_buff *skb,
Do we have the information atm_get_pvc_id() should return somewhere else
in the skb?
At the ATM/PTM TC level, skb lacks any metadata at the moment. We build
skb in rxout_action() in sw_plat.c and copy only the actual data in it.
Technically, we have one unclear field in the rx descriptor called 'qid'
which is commented as 'DW 0'. Maybe we can reverse engineer its format
and use it to map a received packet to a specific PVC.
Suddenly, I do not have access to that device anymore and unlikely can
have it a reasonable time. And cannot verify any guess. We can leave a
fully functional mapping for a future development. In a worst case
scenario we will receive a bug report from someone who needs an extra
PVC for e.g. IPTV. But receives all the IPTV packets on the first (data)
PVC.
The DW0 attribute is the patched in DMA descriptor used to transfer this
packet.
Cannot follow you here. Could you clarify at bit?
--
Sergey
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
