kernel/drivers/net/fddi/defxx.c, branch linux-6.18.y

net: handle HAS_IOPORT dependencies

2024-04-08T10:56:56Z

In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add HAS_IOPORT as dependency for those drivers requiring them. For the DEFXX driver the use of I/O ports is optional and we only need to fence specific code paths. It also turns out that with HAS_IOPORT handled explicitly HAMRADIO does not need the !S390 dependency and successfully builds the bpqether driver. Acked-by: Marc Kleine-Budde Acked-by: Jakub Kicinski Acked-by: Maciej W. Rozycki Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle Signed-off-by: David S. Miller

net: defxx: Fix missing err handling in dfx_init()

2022-12-09T10:44:27Z

When eisa_driver_register() or tc_register_driver() failed, the modprobe defxx would fail with some err log as follows: Error: Driver 'defxx' is already registered, aborting... Fix this issue by adding err hanling in dfx_init(). Fixes: e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support") Signed-off-by: Yongqiang Liu Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller

fddi: defxx,defza: use dev_addr_set()

2021-10-22T17:16:03Z

Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Acked-by: Maciej W. Rozycki Signed-off-by: Jakub Kicinski

FDDI: defxx: Fix function names in coments

2021-09-27T11:29:33Z

Use dma_xxx_xxx() instead of pci_xxx_xxx(), because the pci function wrappers are not called here. Signed-off-by: Cai Huoqing Signed-off-by: David S. Miller

FDDI: defxx: Use driver's name with resource requests

2021-03-10T21:08:15Z

Replace repeated "defxx" strings with a reference to the DRV_NAME macro and then use the driver's name rather that the bus address with resource requests so as to have contents of /proc/iomem and /proc/ioports more meaningful to the user, in line with what drivers usually do. So rather than say: 5000-50ff : DEC FDDIcontroller/EISA Adapter 5000-503f : 00:05 5040-5043 : 00:05 5400-54ff : DEC FDDIcontroller/EISA Adapter 5800-58ff : DEC FDDIcontroller/EISA Adapter 5c00-5cff : DEC FDDIcontroller/EISA Adapter 5c80-5cbf : 00:05 or: 620c080020000-620c08002007f : 0031:02:04.0 620c080020000-620c08002007f : 0031:02:04.0 620c080030000-620c08003ffff : 0031:02:04.0 or: 1f100000-1f10003f : tc2 we report: 5000-50ff : DEC FDDIcontroller/EISA Adapter 5000-503f : defxx 5040-5043 : defxx 5400-54ff : DEC FDDIcontroller/EISA Adapter 5800-58ff : DEC FDDIcontroller/EISA Adapter 5c00-5cff : DEC FDDIcontroller/EISA Adapter 5c80-5cbf : defxx and: 620c080020000-620c08002007f : 0031:02:04.0 620c080020000-620c08002007f : defxx 620c080030000-620c08003ffff : 0031:02:04.0 and: 1f100000-1f10003f : defxx respectively for the DEFEA (EISA), DEFPA (PCI), and DEFTA (TURBOchannel) adapters. Signed-off-by: Maciej W. Rozycki Signed-off-by: David S. Miller

FDDI: defxx: Implement dynamic CSR I/O address space selection

2021-03-10T21:08:15Z

Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. Conversely a DEFEA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available for us with the resource allocation infrastructure we implement. However either I/O address space will always be available for use with the DEFEA (EISA) and DEFPA (PCI) adapters and both have double address decoding implemented in hardware for Control and Status Register access. The two kinds of adapters can be present both at once in a single mixed PCI/EISA system. For the DEFTA (TURBOchannel) variant there is no issue as there has been no port I/O address space defined for that bus. To make people's life easier and the driver more robust remove the DEFXX_MMIO configuration option so as to rather than making the choice for the I/O address space to use at build time for all the adapters installed in the system let the driver choose the most suitable address space dynamically on a case-by-case basis at run time. Make MMIO the default and resort to port I/O should the default fail for some reason. This way multiple adapters installed in one system can use different I/O address spaces each, in particular in the presence of DEFEA adapters in a pure-EISA or a mixed EISA/PCI system (it is expected that DEFPA boards will use MMIO in normal circumstances). The choice of the I/O address space to use continues being reported by the driver on startup, e.g.: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.12 2021/03/10 Lawrence V. Stefani and others 00:05: DEFEA at I/O addr = 0x5000, IRQ = 10, Hardware addr = 00-00-f8-c8-b3-b6 00:05: registered as fddi0 and: defxx: v1.12 2021/03/10 Lawrence V. Stefani and others 0031:02:04.0: DEFPA at MMIO addr = 0x620c080020000, IRQ = 57, Hardware addr = 00-60-6d-93-91-98 0031:02:04.0: registered as fddi0 and: defxx: v1.12 2021/03/10 Lawrence V. Stefani and others tc2: DEFTA at MMIO addr = 0x1f100000, IRQ = 21, Hardware addr = 08-00-2b-b0-8b-1e tc2: registered as fddi0 so there is no need to add further information. The change is supposed to cause a negligible performance hit as I/O accessors will now have code executed conditionally at run time. Signed-off-by: Maciej W. Rozycki Signed-off-by: David S. Miller

FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR

2021-03-10T21:08:15Z

Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: Maciej W. Rozycki Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: David S. Miller

FDDI: defxx: Update my e-mail address

2021-03-10T20:45:16Z

Following the recent update to MAINTAINERS update my e-mail address. Signed-off-by: Maciej W. Rozycki Signed-off-by: David S. Miller

remove ioremap_nocache and devm_ioremap_nocache

2020-01-06T08:45:59Z

ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig Acked-by: Arnd Bergmann

net: defxx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles

2019-02-07T01:38:15Z

dev_consume_skb_irq() should be called in dfx_xmt_done() when skb xmit done. It makes drop profiles(dropwatch, perf) more friendly. Signed-off-by: Yang Wei Reviewed-by: Maciej W. Rozycki Signed-off-by: David S. Miller