[PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility

[Robert Marko]

On Tue, 31 Jan 2023 at 23:52, Jan Hoffmann <jan at 3e8.eu> wrote:
>
> 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.

I get the issue, however, I am failing to see how faking the PCI ID for the
root adaptor is magically solving that?
If that works, why can't you just patch the driver to stop looking for
the ancient
Lantiq ID?

Regards,
Robert
>
>
> 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