[OpenWrt-Devel] [PATCH] mvebu: Add support for kernel 4.19

[Tomasz Maciej Nowak]

Hi Marek,

W dniu 16.05.2019 o 20:38, Marek Behún pisze:
> Add support for kernel 4.19 to the mvebu target.
> 
> This is the first version, unfortunately I only have Turris Omnia and
> Turris Mox to test this on, and Turris Mox is not yet supported in these
> patches.

You beat me to it, but not only You https://github.com/openwrt/openwrt/pull/1646.
Only recently I had time to look at it and this:
https://github.com/tmn505/openwrt/tree/mvebu-4.19
is my shot at it (based on initial Marko Ratkaj work). I asked Sébastien in
mentioned PR on GitHub if I can send it here.

Just yesterday and today I got report from owners of WRT1900AC and WRT32X that their
NAND chips are working:
https://forum.openwrt.org/t/kernel-4-19-upgrade-issue-on-mvebu-target-s/32966/32
https://forum.openwrt.org/t/kernel-4-19-upgrade-issue-on-mvebu-target-s/32966/34
So it seems that most difficult devices are working. Unfortunately I don't have
anything with SFP, so would be nice to know if anything needs to be added.

> 
> So if you guys could try this and give feedback.

Most of the kept patches are similar and on ESPRESSObin everything seems to work OK.

> 
> This does not add default config for 4.19, this would also be needed.

There's not much to be added, simple refresh for cortexa9 kernel config should do,
but cortexa53 and cortexa72 needs this ARM64_SVE added, so it won't error out when
building.

> 
> I manually went through all the patches from 4.14 and removed those
> which are already in 4.19 upstream. Those patches which did not apply I
> patched manually. One of them,
> 524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch,
> could not be applied, because the code in pci-aardvark changed too much.

I reverted the c8e144f8ab ("PCI: aardvark: Convert to use pci_host_probe()") which
was mostly code cleanup (that's how I understand it), after that the mentioned patch
could still apply.

> Moreover upstream solved the issue this patch was solving differently
> (via pci-emul-bridge). I did not backport pci-emul-bridge, perhaps this
> would be needed (but is not on Turris Mox with its default PCIe card).

I didn't observe any issues with Aardvark driver from 4.19 with current patches, so
I think we can leave that for next kernel bump.

What I would like to ask is if You've had also link training issues with PCIe port
and particular Atheros/Qualcomm (AR3890, QCA9890) wifi cards on Turris MOX? Which we
work around with these patches:
527-PCI-aardvark-allow-to-specify-link-capability.patch
528-arm64-dts-armada-3720-espressobin-set-max-link-to-ge.patch
Or do You use different chip vendors?

> 
> I used new patches for SFP support from Russell King.
> 
> Signed-off-by: Marek Behún <marek.behun at nic.cz>
> Cc: Russell King <rmk+kernel at armlinux.org.uk>
> Cc: Felix Fietkau <nbd at nbd.name>
> Cc: Hauke Mehrtens <hauke at hauke-m.de>
> Cc: Imre Kaloz <kaloz at openwrt.org>
> Cc: Jeremiah McConnell <miah at miah.com>
> Cc: Jonas Gorski <jonas.gorski at gmail.com>
> Cc: Kevin Darbyshire-Bryant <ldir at darbyshire-bryant.me.uk>
> Cc: Koen Vandeputte <koen.vandeputte at ncentric.com>
> Cc: Michael Gray <michael.gray at lantisproject.com>
> Cc: Rosen Penev <rosenp at gmail.com>
> Cc: Ryan Mounce <ryan at mounce.com.au>
> Cc: Stijn Segers <foss at volatilesystems.org>
> Cc: Stijn Tintel <stijn at linux-ipv6.be>
> Cc: Tomasz Maciej Nowak <tomek_n at o2.pl>

Regards

-- 
TMN

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel