2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-27 06:34:11 +08:00
linux-next/Documentation/networking/defza.txt
Maciej W. Rozycki 61414f5ec9 FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter
Add support for the DEC FDDIcontroller 700 (DEFZA), Digital Equipment
Corporation's first-generation FDDI network interface adapter, made for
TURBOchannel and based on a discrete version of what eventually became
Motorola's widely used CAMEL chipset.

The CAMEL chipset is present for example in the DEC FDDIcontroller
TURBOchannel, EISA and PCI adapters (DEFTA/DEFEA/DEFPA) that we support
with the `defxx' driver, however the host bus interface logic and the
firmware API are different in the DEFZA and hence a separate driver is
required.

There isn't much to say about the driver except that it works, but there
is one peculiarity to mention.  The adapter implements two Tx/Rx queue
pairs.

Of these one pair is the usual network Tx/Rx queue pair, in this case
used by the adapter to exchange frames with the ring, via the RMC (Ring
Memory Controller) chip.  The Tx queue is handled directly by the RMC
chip and resides in onboard packet memory.  The Rx queue is maintained
via DMA in host memory by adapter's firmware copying received data
stored by the RMC in onboard packet memory.

The other pair is used to communicate SMT frames with adapter's
firmware.  Any SMT frame received from the RMC via the Rx queue must be
queued back by the driver to the SMT Rx queue for the firmware to
process.  Similarly the firmware uses the SMT Tx queue to supply the
driver with SMT frames that must be queued back to the Tx queue for the
RMC to send to the ring.

This solution was chosen because the designers ran out of PCB space and
could not squeeze in more logic onto the board that would be required to
handle this SMT frame traffic without the need to involve the driver, as
with the later DEFTA/DEFEA/DEFPA adapters.

Finally the driver does some Frame Control byte decoding, so to avoid
magic numbers some macros are added to <linux/if_fddi.h>.

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-10-15 21:46:06 -07:00

58 lines
2.3 KiB
Plaintext

Notes on the DEC FDDIcontroller 700 (DEFZA-xx) driver v.1.1.4.
DEC FDDIcontroller 700 is DEC's first-generation TURBOchannel FDDI
network card, designed in 1990 specifically for the DECstation 5000
model 200 workstation. The board is a single attachment station and
it was manufactured in two variations, both of which are supported.
First is the SAS MMF DEFZA-AA option, the original design implementing
the standard MMF-PMD, however with a pair of ST connectors rather than
the usual MIC connector. The other one is the SAS ThinWire/STP DEFZA-CA
option, denoted 700-C, with the network medium selectable by a switch
between the DEC proprietary ThinWire-PMD using a BNC connector and the
standard STP-PMD using a DE-9F connector. This option can interface to
a DECconcentrator 500 device and, in the case of the STP-PMD, also other
FDDI equipment and was designed to make it easier to transition from
existing IEEE 802.3 10BASE2 Ethernet and IEEE 802.5 Token Ring networks
by providing means to reuse existing cabling.
This driver handles any number of cards installed in a single system.
They get fddi0, fddi1, etc. interface names assigned in the order of
increasing TURBOchannel slot numbers.
The board only supports DMA on the receive side. Transmission involves
the use of PIO. As a result under a heavy transmission load there will
be a significant impact on system performance.
The board supports a 64-entry CAM for matching destination addresses.
Two entries are preoccupied by the Directed Beacon and Ring Purger
multicast addresses and the rest is used as a multicast filter. An
all-multi mode is also supported for LLC frames and it is used if
requested explicitly or if the CAM overflows. The promiscuous mode
supports separate enables for LLC and SMT frames, but this driver
doesn't support changing them individually.
Known problems:
None.
To do:
5. MAC address change. The card does not support changing the Media
Access Controller's address registers but a similar effect can be
achieved by adding an alias to the CAM. There is no way to disable
matching against the original address though.
7. Queueing incoming/outgoing SMT frames in the driver if the SMT
receive/RMC transmit ring is full. (?)
8. Retrieving/reporting FDDI/SNMP stats.
Both success and failure reports are welcome.
Maciej W. Rozycki <macro@linux-mips.org>