Hi Robert,
On 2023-01-30 at 00:08, Robert Marko wrote:
Shouldn't it be possible for the modem driver itself to be fixed
instead of faking
the PCI details?
This hack is definitely far from ideal, but I'm not sure if there is a
better way to fix this.
Here are a few more details about the issue:
On the affected devices (so far, three users reported it on the VRX518
thread in the forum [0]), the function call to turn on the "EMA"
hardware unit in the vrx518_tc driver [1] fails with the error mentioned
in the commit message.
I don't have any details about it, but this EMA unit is part of the data
path (it is also referenced in the ltq-atm and ltq-ptm data path drivers
for older Lantiq modems). If the EMA unit is not running, then at least
the transmit data path doesn't work, and any packets the driver writes
to the TX ring are not actually sent out by the device.
This is also reproducible on non-affected devices by calling tc_clkoff
instead of tc_clkon in the vrx518_tc driver (i.e. disabling the hardware
unit). The same issue also occurs on affected devices running vendor
firmware, if the "magic" in the PCIe driver is disabled in the device
tree. So this is not just a bug in the data path driver.
Regards,
Jan
Especially considering that now modem support is not self-contained
and will require
patching the DWC Qualcomm PCI driver forever.
Regards,
Robert
[0]
https://forum.openwrt.org/t/adding-support-for-vrx518-and-maybe-vrx320/55160
[1]
https://gitlab.com/prpl-foundation/intel/vrx518_tc_drv/-/blob/ugw-8.5.2/dcdp/tc_main.c#L112
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
