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: David S. Miller <davem@davemloft.net>
Showing
drivers/net/fddi/defza.c
0 → 100644
drivers/net/fddi/defza.h
0 → 100644
Please register or sign in to comment