driver: ethernet: add adin2111

[GeorgeCGV]

Adds initial ADIN2111 2-Port 10BASE-T1L (Single Pair Ethernet [SPE]) switch support (implementation wise not really a switch). It works over SPI using ADI Generic SPI protocol instead of OPEN Alliance.

SPE:

Single Pair Ethernet (SPE) describes the transmission of Ethernet via only one pair of copper wires.
It provides the necessary infrastructure for the Industrial Internet of Things (IIoT)

ADIN2111 overview:

The ADIN2111 is a low power, 2-port 10BASE-T1L transceiver designed for industrial Ethernet applications, and is compliant with the IEEE® 802.3cg-2019™ Ethernet standard for long reach, 10 Mbps single pair Ethernet (SPE). Featuring an integrated media access control (MAC) and a switch, the ADIN2111 enables direct connectivity with a variety of controllers via a serial peripheral interface (SPI). The switch (cut through or store and forward) supports various routing configurations between the two Ethernet ports and the SPI host port providing a flexible solution for line, daisy-chain, or ring network topologies.

The ADIN2111 can be used in unmanaged configurations where the device automatically forwards the traffic between the two Ethernet ports.

The driver creates 2 eth interfaces, one for each port (PHY). Didn't use DSA as I am not sure if it fits.
It configures multicast and broadcast reception and forwarding.

Supports:

• Link state detection via INT that is detected in the main driver and handled by PHY's driver
• Works with CRC enabled and without
• Provides separate drivers for MDIO and PHY.
  Where MDIO uses exposed functions of the main driver. PHY utilizes MDIO API and exposed MDIO
  functions to access Clause 45 registers.^*
• MDIO driver is integrated into the shell. There it exposes Clause 22 registers.
• PHY hardware fault detection (at init)
• PHY LED0, LED1 enable/disable
• PHY TX 2.4V Mode enable/disable and ability detection
• Ports ETH stats
• Interface set config (MAC)

This PR doesn't modify existing APIs to not be intrusive. At the same time, the goal was to make use
of existing MDIO and PHY APIs.

Tested on custom hardware.

The existing MDIO API is very restrictive. Currently, MDIO API doesn't support Clause 45 and Clause 22 at the same time. It exposes read and write calls that are either Clause 45 or Clause 22. However, for C45 it misses the device address from the function definition. Not sure how Clause 45 works for others there.

The PHY driver shall access registers over MDIO via Clause 45 and Clause 22.

That can be solved by the introduction of specific Clause 22 and Clause 45 functions into MDIO. This would allow us not to touch the existing API but still support other cases. The alternative is to modify read and write register API functions and change reg. address type to uint32_t to integrate the device and register address in it. However, the Linux kernel went away from that approach.

Another point relates to MDIO locking. I would like to lock the whole device while MDIO is in use by the public (i.e. shell). That allows it to prevent access while it processes frame transfer, IRQ offload, or something else where sequential access to MDIO is required.

The current API doesn't provide a way to lock/unlock the MDIO bus. However, there are the enable and disable calls.

I avoided API modification proposals at this stage and implemented enable and disable as device lock/unlock. That works. However, I assume the meaning behind enable and disable won't be correct.

Should MDIO API be revised/revisited?

@gmarull, @henrikbrixandersen I hope select and depends on are not messed up.

Open for review, suggestions, comments.