diff options
| author | Maciej W. Rozycki <macro@linux-mips.org> | 2018-10-09 23:57:43 +0100 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2018-10-15 21:46:06 -0700 |
| commit | 61414f5ec9834df8aa4f55c90de16b71a3d6ca8d (patch) | |
| tree | 63fbcf2a6cbe3d285fca8b2e4aa41ef18220cd50 /include/uapi/linux/if_fddi.h | |
| parent | df52eab23d703142c766ac00bdb8db19d71238d0 (diff) | |
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>
Diffstat (limited to 'include/uapi/linux/if_fddi.h')
| -rw-r--r-- | include/uapi/linux/if_fddi.h | 21 |
1 files changed, 18 insertions, 3 deletions
diff --git a/include/uapi/linux/if_fddi.h b/include/uapi/linux/if_fddi.h index 75eed8b62823..7239aa9c0766 100644 --- a/include/uapi/linux/if_fddi.h +++ b/include/uapi/linux/if_fddi.h @@ -6,9 +6,10 @@ * * Global definitions for the ANSI FDDI interface. * - * Version: @(#)if_fddi.h 1.0.2 Sep 29 2004 + * Version: @(#)if_fddi.h 1.0.3 Oct 6 2018 * - * Author: Lawrence V. Stefani, <stefani@lkg.dec.com> + * Author: Lawrence V. Stefani, <stefani@yahoo.com> + * Maintainer: Maciej W. Rozycki, <macro@linux-mips.org> * * if_fddi.h is based on previous if_ether.h and if_tr.h work by * Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG> @@ -45,7 +46,21 @@ #define FDDI_K_OUI_LEN 3 /* Octets in OUI in 802.2 SNAP header */ -/* Define FDDI Frame Control (FC) Byte values */ +/* Define FDDI Frame Control (FC) Byte masks */ +#define FDDI_FC_K_CLASS_MASK 0x80 /* class bit */ +#define FDDI_FC_K_CLASS_SYNC 0x80 +#define FDDI_FC_K_CLASS_ASYNC 0x00 +#define FDDI_FC_K_ALEN_MASK 0x40 /* address length bit */ +#define FDDI_FC_K_ALEN_48 0x40 +#define FDDI_FC_K_ALEN_16 0x00 +#define FDDI_FC_K_FORMAT_MASK 0x30 /* format bits */ +#define FDDI_FC_K_FORMAT_FUTURE 0x30 +#define FDDI_FC_K_FORMAT_IMPLEMENTOR 0x20 +#define FDDI_FC_K_FORMAT_LLC 0x10 +#define FDDI_FC_K_FORMAT_MANAGEMENT 0x00 +#define FDDI_FC_K_CONTROL_MASK 0x0f /* control bits */ + +/* Define FDDI Frame Control (FC) Byte specific values */ #define FDDI_FC_K_VOID 0x00 #define FDDI_FC_K_NON_RESTRICTED_TOKEN 0x80 #define FDDI_FC_K_RESTRICTED_TOKEN 0xC0 |