I'll have to go double check to see if it does indeed pass ARP frames between
switch ports with this disabled, but it seems required for the CPU port to see
ARP traffic.
I'll dig into this some more.
This indeed uses the same registers as the AR8216 and later chips.
There seems to be an issue with ARP requests being sent out from the CPU
through this switch here, so figuring that out is next. Learning works fine on
the AR8327 ethernet switch on the /other/ gigabit ethernet port, so I don't
think it's the network stack or ethernet driver.
Tested:
* DB120 - AR9340 SOC + ethernet switch (and other bits.)
* Refactor the initial learning configuration (port learning, address expiry,
handling address moving between ports, etc, etc) into a separate HAL routine
* and ensure that it's consistent between switch chips - the AR8216,8316,724x,9331
SoCs all share the same switch code.
* .. the AR8327 needs doing - the defaults seem OK for now
* .. the AR9340 is different but it's also programmed now.
* Add support for flushing a single port worth of ATU entries
* Add support for fetching the ATU table from AR8216 and derived chips
Tested:
* AR9344, Carambola 2
TODO:
* Further testing on other chips
* Add AR9340 support
* Add AR8327 support
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
arswitch_setled() and a number of _global_setup functions did not acquire the
lock before calling arswitch_modifyreg(). With WITNESS enabled this would
instantly panic.
Discovered on a TPLink-3600:
("panic: mutex arswitch not owned at sys/dev/etherswitch/arswitch/arswitch_reg.c:236")
Reviewed by: adrian, kan
Differential Revision: https://reviews.freebsd.org/D9187
The mdio driver interface is generally useful for devices that require
MDIO without the full MII bus interface. This lifts the driver/interface
out of etherswitch(4), and adds a mdio(4) man page.
Submitted by: Landon Fuller <landon@landonf.org>
Differential Revision: https://reviews.freebsd.org/D4606
This is just the chip initialisation code (for now.)
It's not linked into the main build as it requires a bunch of other code
to be tidied up and committed. But it indeed does function as advertised.
Tested:
* AR9344 SoC
