Page MenuHomeFreeBSD

Introduce new driver for NXP ENETC Ethernet controller

Authored by kd on Jun 11 2021, 3:06 PM.



ENETC it a gigabit Ethernet controller found on the LS1028A board.
It supports basic VLAN offloads - tag extraction, injection and hardware filtering.
Inband MDIO connectivity is used for link status monitoring through the miibus interface.
Fixed-link mode is also supported, which allows for operation of internal cpu to switch port.
Since no admin interrupts are present in hardware, link status polling has to be used.
Due to a hardware bug software reset of the NIC results in a external abort.
Because of that most of the hardware initialization is done during attach.
This also means that in the case of an fatal error full board reset is required.
The enetc_hw.h header was imported from Linux, it is dual licensed.

Diff Detail

rG FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kd requested review of this revision.Jun 11 2021, 3:06 PM
kd added a parent revision: D30728: iflib: Add a new quirk.
gallatin added inline comments.

Any reason that you didn't enable LRO? This does not require device support AFAIK.

Also, does this device really not even support transmit checksum offload?


You don't need to capitalise soc_nxp_ls.


This driver depends on fdt, but it seems to be missing from the config file.

Don't capitalize soc_nxp_ls.




I'm pretty much sure that the 'fdt' is present.
I don't require it for dev/enetc/enetc_mdio.c, but I don't think it is needed there.


If I understand correctly LRO is usable only if L4 checksum has been calculated in hardware. (sys/net/iflib.c:3033)
TX checksum offload it is not supported. There is no mention of it in documentation, Linux driver doesn't enable it either.
In general the selection of offloads implemented in this NIC is somewhat weird.
We have VLAN related offloads, PTP, (not implemented in this driver) but the the TX checksum is missing.


Yes, it seems more of a switch chip, given the feature set.

The chip has passed you a checksum. See mxge_rx_csum() for an example of what to do when the NIC passes you a checksum and does not validate it.


I'm pretty much sure that the checksum is validated.
Apart from it NIC also passes a 16 bit parser status.
I checked it manually and the error bit within it is set when the ip checksum is incorrect.
Frames with wrong FCS are automatically dropped, L4 checksum is not checked in hardware, so there is no ambiguity.

With that in mind should I be doing something extra with that checksum from the NIC?

This revision was not accepted when it landed; it landed in state Needs Review.Jun 24 2021, 11:12 AM
This revision was automatically updated to reflect the committed changes.