Ah okay, so that doesn't matter after all 
I also just looked at the errors and grep'ed around a little.
As for your latest update:
There wasn't any noticeable regression with non-threaded NAPI, I tested this for +2 days. No issues, no dmesg entries afaict.
I enabled threaded NAPI yesterday, seems to work just fine too, no regressions either
I just pushed another small update to my branch. This includes just 2 changes:
Moved locking for interrupt mask changes to EP driver (cleans up the code a bit).
Fixed reported upstream MINEFTR value (Removed multiplication by 1000 in the driver which caused an overflow, as the EFTR_min value from the device seems to alredy be in bits/second. The same issue exists for VR9, so a separate patch for these devices is also needed. I'm not entirely sure if this is actually an issue in the Lantiq modem. In theory, this could also be caused by the other end sending data in the wrong format. But the only G.INP line I have for testing is my own DTAG line (Broadcom 194.26). So, if anyone tests this on a line with different vendor ID, please report back with results. The MINEFTR value is reported by dsl_cpe_pipe.sh pmrtctg 1.)
@dhewg It would be great if you could rebase your branch on the current master the next time you work on it: Support for the Fritz!7530 with the new NAND chip was just merged.
Thanks for all the hard work!
I'm using a local provider, but it's all DTAG lines anyway afaik, Broadcom 178.31.
Uptime is less than one hour, because of a new image with your latest patches.
nReturn=0 nDirection=1 nElapsedTime=2763 bValid=1 nEftrMin=42140000 nErrorFreeBits=2788235998 nLeftr=43
Thank you for testing! This is a reasonable value, so it looks like the patch also works on your line.
Now, the interesting question is if it also works for non-Broadcom VTU-C.
@numero53: If you still have the Planet VC-231G, it would be great if you could test this! This of course also applies to anyone else who has a way to test on a non-Broadcom G.INP-enabled line.
@dhewg @janh what a blast 
the fastest VDSL2 device by a mile, nice work guys. Retiring BT Home Hub 5a soon!
Same here, already retired my BTHH for a 7520 last year
But the hard work to get DSL going was all done by @janh, I only got it a bit into shape to get a step closer to upstream it.
About that, maybe we should just try that? I guess the license on a few firmware files are unclear, leave them out for now?
@dhewg I'm also on a 7520 with your tree, but two LAN ports seem to be stuck at 100M. Am I missing a patch in your tree?
I'm guessing this won't be off much use in Belgium? (Only whitelisted firmwares can use vectoring, Else you get a 30/5 fallback profile)
Or are the loaded firmware blobs fixing this?
There is a potential issue with the ATM patch that is worth looking at before trying to upstream the code. @akron reported a build failure due to the function ppp_device not being defined (It went away though with a fresh config). I haven't verified this myself, but it seems like the function is indeed missing.
Other than yet, I agree that it may be time to look into upstreaming. I have finally switched to a 7520 for my actual DSL a few weeks ago, and it also works fine here.
I think that restriction is only lifted with the DSA patch. @dhewg commented about this on Github: https://github.com/openwrt/openwrt/pull/4721#issuecomment-996504471 https://github.com/chunkeey/FritzBox-4040-UBOOT/pull/6#issuecomment-996732085
Depending on how that whitelist is actually implemented I think it could still work. In addition to using a supported DSL firmware version, it is possible to adjust the reported inventory data to match the values from the vendor firmware (using dsl_cpe_pipe.sh G997_LineInventorySet for temporary configuration, but making that permanent should be possible using a modification of the DSL init script). If the whitelist includes any further checks, then this could be more difficult.
I can confirm that setting the version using this method works to get a modem accepted by the whitelist. I added this call to my init script and was thinking maybe a patch to configure these params from uci woyld be nice.
I did extract the os version and serial from a whitelisted fritzbox. But I think it's only the os version that is checked.
As @janh already mentioned, so far the DSA PR is the only way to solve that. Since that's the proper long term solution anyway I didn't bother finding a fix non DSA.
That PR is huge and there may be conflicts if merging it with the work here. That's the only reason I stopped using it. I propose to get the DSL stuff (minus firmware) merged and the DSA PR rebased onto that for a less painfull experience
Note: If you try the DSA PR backup and remove /etc/config/network before rebooting, so the device is at least reachable with the default ethernet setup
I dug a little... That build error occurs with CONFIG_PACKAGE_kmod-pppoa=y.
The missing function is here:
That patch is not part of 999-atm-mpoa-intel-dsl-phy-support.patch here, it probably should?
There's more stuff here, maybe missing here too?
Is ATM even relevant at all anymore? Maybe we can just throw that all out of the tc driver and just don't bother with it?
Yes, e.g. in Germany customers on Deutsche Telekom's MagentaS plan typically get ~16/2.5 Mbps via ADSL2+ and that operates over ATM. However PPPoA is not used by any major ISP in Germany, but e.g. in the UK, PPPoA seems to be an option for links still on ADSL. So I would say, yes ATM/AAL5/ADSL are on the way out, but still have significant users and deployment. It would be nice if OpenWrt would work on such links...
Alright, thanks!
Updated the ATM patches to fix the compile error.
Is anyone able to test an ATM setup?
A slight digression, but this is regarding flashing the 7530 unit...
I use the standard OpenWRT release (with an external modem obviously) and have switched back and forth between that and the Fritz!OS many times.
I find it impossible to flash to OpenWRT from the latest Fritz!OS (7.29) and I've tried several times, I cannot get the first part of the procedure to work at all (the python script).
Each time, I have to flash an older one (7.21) from an older Fritz recovery tool version that I luckily still have, and then from 7.21 I can happily flash OpenWRT.
The reason I mention this is that if it's not just me (why would it be?) and this is a real problem, does someone need to work on updating the procedure or else nobody with an up-to-date Fritz!Box will be able to flash it anyway.
If there's any interest in alternative VR11 xDSL blob versions, have a look at https://github.com/xdarklight/lantiq-xdsl-firmware-info/issues/34 - see the Vigor 165 and Vigor 2765 sections. There are some VR10 versions in the Vigor 2762 section as well.
Are you sure those work on 75x0?
FWIW I'm using 8.13.1.10.1.7, IIRC I extracted that out of the official AVM firmware:
sha256sum package/firmware/intel/dsl-vr11-firmware-xdsl/src/vr11-B-dsl.bin
6aa29f5fa48ca8a43430f998b08c67e596e48e5eb8d97fecfbd4f3283e2fd6c6 package/firmware/intel/dsl-vr11-firmware-xdsl/src/vr11-B-dsl.bin
I can't be certain as I can't test the VR11 8xxxxx files myself on a 75x0 however I'm pretty confident that the files extracted are valid VR11 firmware files. The VR9 and VR10 files I've extracted and tested on respective hardware work perfectly.
If I'm converting correctly that would be 8.D.1.A.1.7 which slots in between the 8.D.1.9.1.7 and 8.D.1.B.1.7 versions present in the Draytek images. If it's working well for you I wouldn't change. While AVM seem to generally end up with versions that work well in most networks, their choice is sometimes outperformed by other versions in some networks. With my devices and connection I can usually get at least 3-5% better sync rates with some specific versions compared to the AVM version - YMMV.