This family should be dropped upstream since it has been marked source-only in OpenWrt
This includes the following SoC families:
- Amazon-SE
- Danube
- xRX100
- xRX200
- xRX300
- Update and use the LDMA driver instead of the lantiq-specific custom DMA driver API
- this requires updating the upstream
lantiq_xrx200.c
andlantiq_etop.c
Ethernet drivers - it will give us compile-testing support for the Ethernet drivers
- this requires updating the upstream
- porting the PCI controller driver to the "standard" PCI driver framework
PCI_DRIVERS_GENERIC
- this is a pre-condition for the PCIe controller driver
- while doing this we should clean up our PCI driver (honoring the reset GPIO polarity, describing all memory regions in .dts, ...)
- this will require getting rid of
0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
in OpenWrt (probably not used anymore as all boards requiring this are marked as broken/disabled) - latest patches from @xdarklight
- Update and use the pcie-intel-gw PCIe driver (xRX200 and xRX300 only)
- the PCIe PHY driver is already upstreamed and used in OpenWrt, so only the PCIe controller driver is missing
- some details about the PCIe controller revisions can be found in an early version of the pcie-intel-gw patches
- latest patches from @xdarklight
- Refactoring of the IRQ controller driver to use a hierarchical chained IRQ chip
- this means we can describe the MIPS CPU interrupt-controller in our .dts(i)
- required as soon as we want to properly implement the EIU or MSI interrupt-controller drivers
- latest patches from @xdarklight
- introduction of a common clock framework based CGU (and PMU?) driver
- some documentation was created by @Mandrake-Lee
- also some patches were written by @Mandrake-Lee
- implement a soc-info driver (for example as in
drivers/soc/amlogic/meson-mx-socinfo.c
)- this can then be used to identify the SoC in other drivers, for example the
ltq_cputemp.c
driver - see
meson_drm_soc_attrs
indrivers/gpu/drm/meson/meson_drv.c
how this can be used from another driver
- this can then be used to identify the SoC in other drivers, for example the
- switch to the
drivers/mtd/nand/raw/intel-nand-controller.c
NAND driverxway_nand.c
uses legacy raw NAND APIs which need to be updated anyways- switching to the
intel-nand-controller.c
probably also means that it will be easier to implement DMA based transfers and hardware ECC support on xRX300 (xRX200 does not have HW ECC support yet) - experimental driver changes (without DMA or HW ECC support) and the corresponding .dts changes
- switch to the
reset-intel-gw.c
- according to the Intel LGM maintainers the reset IP is backwards compatible
- also according to them the
reset-lantiq.c
implementation has some issues, see the full discussion - patches sent upstream already in version 1, changes for OpenWrt
- DTS files for boards supported in OpenWrt
- Currently we maintain the dts files in OpenWrt, it would be nice to have them in the upstream kernel.
- Having them in the kernel could make changing the ABI harder.
- DTS file changes are ABI changes. These ABI changes would be needed for a better CGU and DMA driver.
- Update the
lantiq_xrx200.c
driver to support the Ethernet controller (MAC) in this SoC- The register layout is very similar and the DMA integration also seems to be (mostly?) identical
- Write a DSA tag and DSA driver for the 3 port switch
- properly describe the registers for
ltq-cputemp.c
in .dts - upstream solution for the hardware-driven Ethernet PHY LEDs
- another PHY has similar functionality so there was an RFC patch-series some time ago and an updated RFC patch-series based on the first one
- use
dev_err_probe()
ingswip_probe()
to fix probe deferral errors such asgswip 1e108000.switch: dsa switch register failed: -517
/sys/kernel/debug/devices_deferred
has all information related to the deferred devices, including the message passed todev_err_probe()
- Making the DSA selftests pass with the GSWIP driver
- work-in-progress by @sch-m and @xdarklight
This is the switch IP on xRX200, xRX300 and newer SoCs. The datasheet for the exact revision on these SoCs is not available. But there are two newer revisions of that IP whose datasheets are available publicly:
There is a public datasheet for MaxLinear's GPY111, which seems to be the new name of the Intel/Lantiq PEF7071