Detach of-mdio dependency from stmmac-core kmod to fix support for
x86_64 target. This target doesn't use OpenFirmware infrastructure and
stmmac-core for the dwmac-intel driver doesn't depends on it.
Add kmod-of-mdio to any other user of stmmac-core as it's not inherit
from stmmac-core anymore.
Fixes: #14209
Fixes: 4b4c940fbc ("x86: Add kmod-dwmac-intel")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move pcs-xpcs kmod from armsr modules.mk to generic modules package.
Also add additional dependency to x86_64 as stmmac-core it's now used
by x86_64 target and depends on this package.
Fixes: 4b4c940fbc ("x86: Add kmod-dwmac-intel")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The kernel FSL_ENETC_QOS option is only a compile time
option, it does not result in a separate module being built.
Set it to 'y' to resolve a warning from the kernel compile:
.config:2654:warning: symbol value 'm' invalid for FSL_ENETC_QOS
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Fixes: c3151b6f04 ("armvirt: 64: add support for other SystemReady-compatible vendors")
This MDIO driver was already being built, but not installed due
to being selected by the ThunderX Ethernet driver.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The initial armv8 module incorrectly labelled the Thunder(v1) as
supporting the ThunderX2, when they have different drivers.
Add kmod-octeon-tx2 to support the newer devices.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
These are used by common Broadcom SoC's like
the BCM2711 (RPi4) and iProc network processor.
Tested on the RPi4B using the Raspberry Pi
UEFI+ACPI firmware[1].
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] - https://github.com/pftf/RPi4
the Marvell 10G PHY driver is no way specific to ARM SystemReady
systems, it frequently occurs on SFP+ copper modules and is useful on
many targets.
Hence it been added to package/kernel/linux/modules/netdevices and we
can remove the now redundant target-specific module.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Now that the armvirt target supports real hardware, not just
VMs, thanks to the addition of EFI, rename it to something
more appropriate.
'armsr' (Arm SystemReady) was chosen after the name of
the Arm standards program.
The 32 and 64 bit targets have also been renamed
armv7 and armv8 respectively, to allow future profiles
where required (such as armv9).
See https://developer.arm.com/documentation/102858/0100/Introduction
for more information.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
