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

[Paul D]

On 2023-02-08 11:44, Robert Marko wrote:
> On Sun, 5 Feb 2023 at 01:10, Jan Hoffmann <jan at 3e8.eu> wrote:
>>
>>
>> Am 02.02.23 um 11:54 schrieb 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?
>>
>> As far as I can see, the magic values don't appear anywhere in the DSL
>> drivers. So it doesn't seem like there is an easy fix like that.
>>
>> To me this looks like whatever access to these values is being done,
>> seems to happen in hardware (or firmware). Maybe there are some
>> revisions or variants of the modem that don't like to cooperate with
>> non-Lantiq SoCs.
>>
>> But in the end, I don't know with certainty what exactly is happening
>> here, as about the only public information on these modems are the
>> open-source drivers (including the magic hack in the PCIe driver which
>> in its original form contains comments like "do some magic" without
>> really explaining what it actually does).
> 
> Ok, I am now getting the issue, it's probably in the damn firmware.
> I still really dont like the hack that we are gonna need to carry forever.
> 
> I would like for somebody else to chime in as well.
> 

If the OEM does it, unless we can find another way, we should carry the 
hack, if that's what it takes to better support a chipset. DSL will 
still be with us for a while to come. There was a huge amount of work 
and guesswork to even get these chipsets usable.