Add a get_config function for this driver as specified in the
Ethernet subsystem API. The implementation supports querying
the hardware checksum generation capabilities of the specified
GEM device instance. This prevents the transmission of packages
without a valid checksum for protocols such as ICMP, as the
hardware only supports IPv4/IPv6 TCP and UDP checksum generation.
Signed-off-by: Immo Birnbaum <mail@birnbaum.immo>
Align Ethernet/Wi-Fi drivers/L2 with interface state handling update.
For drivers, that did not support carrier detection, no changes are
needed.
Driver that did support carrier detection, are updated to set the
carrier state to OFF by default, instead of setting the
NET_IF_NO_AUTO_START flag. This allows to postopne the actual
NET_EVENT_IF_UP notification until driver detects that carrier is ready.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Fixes a compiler error in eth_xlnx_gem_stats() caused by the
automated replacement of device run-time data pointer accesses
by #41918. The device run-time data access in eth_xlnx_gem_stats()
was likely missed as this function is not usually compiled - its
existance depends on CONFIG_NET_STATISTICS_ETHERNET being set.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@weidmueller.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Do not lock/unlock the System Level Control Registers (SLCRs) in the Xilinx
GEM ethernet driver. The SLRCs are unlocked once at boot time.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Update the Kconfig configuration items used to determine if the current
target is based on the Zynq-7000 SoC family as part of the re-organi-
zation of the Zynq-7000 SoC configuration data.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@Weidmueller.com>
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data and
dev->config instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add support for the Xilinx Zynq-7000 SoC family to this driver. This
includes some SoC-specific register accesses when setting an updated
TX clock divider, also, the device tree binding now supports higher
MDC clock divisor values when the current target SoC is a Zynq rather
than a ZynqMP.
With regards to the use of this driver in a QEMU simulation of the
Zynq-7000, the Kconfig file is modified so that the driver is not
enabled unless QEMU networking is set to Ethernet mode.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@weidmueller.com>
Add support for the Xilinx GEM Ethernet controller, which is integrated
in both the Xilinx Zynq and ZynqMP (UltraScale) SoC families. The driver
supports the management of a PHY attached to the respective GEM's MDIO
interface.
This driver was developed with ultimately the Zynq-7000 series in mind,
but at the time being, it is limited to use in conjunction with the
ZynqMP RPU (Cortex-R5) cores. The differences are minor when it comes
to the adjustment of the TX clock frequency derived from the current
link speed reported by the PHY, but for use in conjunction with the
Zynq-7000, some larger adjustments will have to be made when it comes
to the placement of the DMA memory area, as this involves the confi-
guration of the MMU in Cortex-A CPUs.
The driver was developed under the qemu_cortex_r5 target. The Marvell
88E1111 PHY simulated by QEMU is supported by the driver.
Limitations currently exist when it comes to timestamping or VLAN
support and other minor things. Those haven't been implemented yet,
although they are supported by the hardware. In order to be fully
supported by the ZynqMP APU, 64-bit DMA address descriptor format
support will be added.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@weidmueller.com>
