Commit 3325cf9e authored by David S. Miller's avatar David S. Miller

Merge branch 'defza-fddi'

Maciej W. Rozycki says:

====================
FDDI: DEC FDDIcontroller 700 TURBOchannel adapter support

 This is an update to <http://patchwork.ozlabs.org/patch/342737/>.  I
believe I have addressed all the requests made in the previous review
round.

 There is still one `checkpatch.pl' warning remaining:

WARNING: quoted string split across lines
+       pr_info("%s: ROM rev. %.4s, firmware rev. %.4s, RMC rev. %.4s, "
+               "SMT ver. %u\n", fp->name, rom_rev, fw_rev, rmc_rev, smt_ver);

total: 0 errors, 1 warnings, 2458 lines checked

however I think the value of staying within 80 columns is higher than the
value of having the string on a single line.  This is because with all the
formatting specifiers there it is not directly greppable based on the
final output produced to the kernel log on one hand, e.g.:

tc2: ROM rev. 1.0, firmware rev. 1.2, RMC rev. A, SMT ver. 1

while it can be easily tracked down by grepping for an obvious substring
such as "RMC rev" on the other.

 The issue with MMIO barriers I discussed in the course of the original
review turned out mostly irrelevant to this driver, because as I have
learnt in a recent Alpha/Linux discussion starting here:
<https://marc.info/?i=alpine.LRH.2.02.1808161556450.13597%20()%20file01%20!%20intranet%20!%20prod%20!%20int%20!%20rdu2%20!%20redhat%20!%20com>
our MMIO API mandates the `readX' and `writeX' accessors to be strongly
ordered with respect to each other, even if that is not implicitly
enforced by hardware.

 Consequently I have removed all the explicit ordering barriers and
instead submitted a fix for MIPS MMIO implementation, which currently does
not guarantee strong ordering (the MIPS architecture does not define bus
ordering rules except in terms of SYNC barriers), as recorded here:
<https://patchwork.linux-mips.org/project/linux-mips/list/?series=1538>.

 Enforcing strong MMIO ordering can be costly however and is often
unnecessary, e.g. when using PIO to access network frame data in onboard
packet memory.  I have therefore retained the information that would be
lost by the removal of barriers, by defining accessor wrappers suffixed by
`_o' and `_u', for accesses that have to be ordered and can be unordered
respectively.

 If we ever have an API defined for weakly-ordered MMIO accesses, then
these wrappers can be redefined accordingly.  Right now they all expand to
the respective `_relaxed' accessors, because, again, enforcing the
ordering WRT DMA transfers can be costly and we don't need it here except
in one place, where I chose to use explicit `dma_rmb' instead.

 Similarly I have replaced the completion barriers with a read back from
the respective MMIO location (all adapter MMIO registers can be read with
no side effects incurred), which will serve its purpose on the basis of
MMIO being strongly ordered (although a read from TURBOchannel is going to
be slower than `iob', making the delay incurred unnecessarily longer).

 And last but not least, I have split off the SMT Tx network tap support
to a separate change, 2/2 in this series, so that it does not block the
driver proper and can be discussed separately.

 I think it has value in that it makes the view of the outgoing network
traffic complete, as if one actually physically tapped into the outgoing
line of the ring, between the station being examined and its downstream
neighbour.  Without this part only traffic passed from applications
through the whole protocol stack can be captured and this is only a part
of the view.

 With the `dev_queue_xmit_nit' interface now exported it's only
`ptype_all' that remains private, and to define a properly abstracted API
I propose to provide am exported `dev_nit_active' predicate that tells
whether any taps are active.  This predicate is then used accordingly.

 NB if there is a long-term maintenance concern about the `dev_nit_active'
predicate, then well, corresponding inline code currently present in
`xmit_one' has to be maintained anyway, and if the resulting changes
require `defza' to be updated accordingly, then I am going to handle it;
after some 20 years with Linux it's not that I am going to disappear
anywhere anytime.  And once I am dead, which is inevitably going to happen
sooner or later, then the driver can simply be ripped from the kernel.
Though I suspect that at that point no DECstation Linux users may survive
anymore, even though hardware, being as sturdy as it is, likely will.

 I have a patch for `tcpdump' to actually decode SMT frames, which I plan
to upstream sometime.  Here's a sample of SMT traffic captured through the
`defza' driver in a small network of 4 stations and no concentrators,
printed in the most verbose mode:

01:16:59.138381 4f 00:60:b0:58:41:e7 00:60:b0:58:41:e7 73: SMT NIF ann vid:1 tid:00000270 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
01:17:00.332750 4f 08:00:2b:a3:a3:29 08:00:2b:a3:a3:29 73: SMT NIF ann vid:1 tid:0000013b sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
01:17:00.354479 4f 00:60:b0:58:40:75 00:60:b0:58:40:75 73: SMT NIF ann vid:1 tid:0000029c sid:00-00-00-60-b0-58-40-75 len:40: UNA: 00 00 10 00 d4 74 b6 ae StationDescr: 00 01 02 00 StationState: 00 00 31 00 MACFrameStatusFunctions.3: 00 00 00 01
01:17:00.442175 4f 00:60:b0:58:41:e7 Broadcast 73: SMT NIF req vid:1 tid:00000271 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
01:17:00.448657 41 08:00:2b:a3:a3:29 00:60:b0:58:41:e7 73: SMT NIF rsp vid:1 tid:00000271 sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
01:17:01.015152 4f 08:00:2b:a3:a3:29 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
01:17:01.111644 41 08:00:2b:2e:6d:75 08:00:2b:a3:a3:29 73: SMT NIF rsp vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
01:17:04.814603 4f 08:00:2b:2e:6d:75 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
01:17:04.814939 4f 08:00:2b:2e:6d:75 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
01:17:04.820960 4f 08:00:2b:2e:6d:75 08:00:2b:2e:6d:75 73: SMT NIF ann vid:1 tid:0000013b sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01

 Questions, comments?  Otherwise, please apply.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents df52eab2 9f9a742d
...@@ -56,6 +56,8 @@ de4x5.txt ...@@ -56,6 +56,8 @@ de4x5.txt
- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver - the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
decnet.txt decnet.txt
- info on using the DECnet networking layer in Linux. - info on using the DECnet networking layer in Linux.
defza.txt
- the DEC FDDIcontroller 700 (DEFZA-xx) TURBOchannel FDDI driver
dl2k.txt dl2k.txt
- README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko). - README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
dm9000.txt dm9000.txt
......
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>
...@@ -4170,6 +4170,11 @@ S: Maintained ...@@ -4170,6 +4170,11 @@ S: Maintained
F: drivers/platform/x86/dell-smbios-wmi.c F: drivers/platform/x86/dell-smbios-wmi.c
F: tools/wmi/dell-smbios-example.c F: tools/wmi/dell-smbios-example.c
DEFZA FDDI NETWORK DRIVER
M: "Maciej W. Rozycki" <macro@linux-mips.org>
S: Maintained
F: drivers/net/fddi/defza.*
DELL LAPTOP DRIVER DELL LAPTOP DRIVER
M: Matthew Garrett <mjg59@srcf.ucam.org> M: Matthew Garrett <mjg59@srcf.ucam.org>
M: Pali Rohár <pali.rohar@gmail.com> M: Pali Rohár <pali.rohar@gmail.com>
......
...@@ -15,6 +15,17 @@ config FDDI ...@@ -15,6 +15,17 @@ config FDDI
if FDDI if FDDI
config DEFZA
tristate "DEC FDDIcontroller 700/700-C (DEFZA-xx) support"
depends on FDDI && TC
help
This is support for the DEC FDDIcontroller 700 (DEFZA-AA, fiber)
and 700-C (DEFZA-CA, copper) TURBOchannel network cards which
can connect you to a local FDDI network.
To compile this driver as a module, choose M here: the module
will be called defza. If unsure, say N.
config DEFXX config DEFXX
tristate "Digital DEFTA/DEFEA/DEFPA adapter support" tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
depends on FDDI && (PCI || EISA || TC) depends on FDDI && (PCI || EISA || TC)
......
...@@ -3,4 +3,5 @@ ...@@ -3,4 +3,5 @@
# #
obj-$(CONFIG_DEFXX) += defxx.o obj-$(CONFIG_DEFXX) += defxx.o
obj-$(CONFIG_DEFZA) += defza.o
obj-$(CONFIG_SKFP) += skfp/ obj-$(CONFIG_SKFP) += skfp/
This diff is collapsed.
This diff is collapsed.
...@@ -3645,6 +3645,7 @@ static __always_inline int ____dev_forward_skb(struct net_device *dev, ...@@ -3645,6 +3645,7 @@ static __always_inline int ____dev_forward_skb(struct net_device *dev,
return 0; return 0;
} }
bool dev_nit_active(struct net_device *dev);
void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev); void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev);
extern int netdev_budget; extern int netdev_budget;
......
...@@ -6,9 +6,10 @@ ...@@ -6,9 +6,10 @@
* *
* Global definitions for the ANSI FDDI interface. * 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 * 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> * Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
...@@ -45,7 +46,21 @@ ...@@ -45,7 +46,21 @@
#define FDDI_K_OUI_LEN 3 /* Octets in OUI in 802.2 SNAP #define FDDI_K_OUI_LEN 3 /* Octets in OUI in 802.2 SNAP
header */ 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_VOID 0x00
#define FDDI_FC_K_NON_RESTRICTED_TOKEN 0x80 #define FDDI_FC_K_NON_RESTRICTED_TOKEN 0x80
#define FDDI_FC_K_RESTRICTED_TOKEN 0xC0 #define FDDI_FC_K_RESTRICTED_TOKEN 0xC0
......
...@@ -1976,6 +1976,17 @@ static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb) ...@@ -1976,6 +1976,17 @@ static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb)
return false; return false;
} }
/**
* dev_nit_active - return true if any network interface taps are in use
*
* @dev: network device to check for the presence of taps
*/
bool dev_nit_active(struct net_device *dev)
{
return !list_empty(&ptype_all) || !list_empty(&dev->ptype_all);
}
EXPORT_SYMBOL_GPL(dev_nit_active);
/* /*
* Support routine. Sends outgoing frames to any network * Support routine. Sends outgoing frames to any network
* taps currently in use. * taps currently in use.
...@@ -3233,7 +3244,7 @@ static int xmit_one(struct sk_buff *skb, struct net_device *dev, ...@@ -3233,7 +3244,7 @@ static int xmit_one(struct sk_buff *skb, struct net_device *dev,
unsigned int len; unsigned int len;
int rc; int rc;
if (!list_empty(&ptype_all) || !list_empty(&dev->ptype_all)) if (dev_nit_active(dev))
dev_queue_xmit_nit(skb, dev); dev_queue_xmit_nit(skb, dev);
len = skb->len; len = skb->len;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment