atm_qos struct should be the same both for user and kernel spaces. Via
the __SO_ENCODE() macro it is used to define the SO_ATMQOS socket IOC.
During the VRX518 support introduction, the atm_trafprm sturct nested
into the atm_qos stucture was update with newer fields that are
referenced by the ATM TC layer of the VRX518 TC driver. These new fields
are intended to communicate information for extra traffic classes
supported by the driver. But we are still using vanilla kernel headers
to build the toolchain. Due to the atm.h header incoherency br2684ctl
from linux-atm tools is incapable to configure the ATM bridge netdev:
br2684ctl: Interface "dsl0" created sucessfully
br2684ctl: Communicating over ATM 0.1.2, encapsulation: LLC
br2684ctl: setsockopt SO_ATMQOS 22 <-- EINVAL errno
br2684ctl: Fatal: failed to connect on socket; File descriptor in bad state
There are two options to fix this incoherency. (a) update the header
file in the toolchain to build linux-atm against updated atm_trafprm and
atm_qos structures, or (b) revert atm_trafprm changes.
Since there are no actual users of the extra ATM QoS traffic classes,
just drop these extra traffic classes from vrx518_tc ATM TC layer and
drop the kernel patch updating atm.h.
Besides fixing the compatibility with linux-atm tools, removing the
kernel patch should simplify kernel updates removing unneeded burden of
maintenance.
Run tested with FRITZ!Box 7530 with disabled extra traffic classes and
then removed them entirely before the submission.
CC: John Crispin <john@phrozen.org>
Fixes: cfd42a0098 ("ipq40xx: add Intel/Lantiq ATM hacks")
Suggested-by: Andre Heider <a.heider@gmail.com>
Reported-and-tested-by: nebibigon93@yandex.ru
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250122222654.21833-4-ryazanov.s.a@gmail.com/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
This driver version is also included in Intel UGW 8.5.2.10.
Signed-off-by: Martin Schiller <ms.3headeddevs@gmail.com>
[updated for kernel 5.10]
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
[update to 1.5.12.4, switch to tag tarball]
Signed-off-by: Andre Heider <a.heider@gmail.com>
[add working software data path]
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Andre Heider <a.heider@gmail.com>
