linux-dev/drivers/net/wan/Kconfig, branch master

net: wan: remove support for Z85230-based devices

2022-04-27T11:22:56Z

Looks like all the changes to this driver had been automated churn since git era begun. The driver is using virt_to_bus(), it's just a maintenance burden unlikely to have any users. Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller

net: wan: remove support for COSA and SRP synchronous serial boards

2022-04-27T11:22:56Z

Looks like all the changes to this driver had been automated churn since git era begun. The driver is using virt_to_bus() so it should be updated to a proper DMA API or removed. Given the latest "news" entry on the website is from 1999 I'm opting for the latter. I'm marking the allocated char device major number as [REMOVED], I reckon we can't reuse it in case some SW out there assumes its COSA? Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller

net: wan: remove the lanmedia (lmc) driver

2022-04-06T14:28:23Z

The driver for LAN Media WAN interfaces spews build warnings on microblaze. The virt_to_bus() calls discard the volatile keyword. The right thing to do would be to migrate this driver to a modern DMA API but it seems unlikely anyone is actually using it. There had been no fixes or functional changes here since the git era begun. Let's remove this driver, there isn't much changing in the APIs, if users come forward we can apologize and revert. Link: https://lore.kernel.org/all/20220321144013.440d7fc0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/ Signed-off-by: Jakub Kicinski Acked-by: Arnd Bergmann Acked-by: Thomas Bogendoerfer Signed-off-by: David S. Miller

net: ixp4xx_hss: Check features using syscon

2022-02-12T17:20:03Z

If we access the syscon (expansion bus config registers) using the syscon regmap instead of relying on direct accessor functions, we do not need to call this static code in the machine (arch/arm/mach-ixp4xx/common.c) which makes things less dependent on custom machine-dependent code. Look up the syscon regmap and handle the error: this will make deferred probe work with relation to the syscon. Select the syscon in Kconfig and depend on OF so we know that all we need will be available. Cc: David S. Miller Cc: Jakub Kicinski Cc: netdev@vger.kernel.org Signed-off-by: Linus Walleij Acked-by: Jakub Kicinski Link: https://lore.kernel.org/r/20220211223238.648934-10-linus.walleij@linaro.org Signed-off-by: Linus Walleij

wan: remove sbni/granch driver

2021-08-03T12:05:26Z

The driver was merged in 1999 and has only ever seen treewide cleanups since then, with no indication whatsoever that anyone has actually had access to hardware for testing the patches. >From the information in the link below, it appears that the hardware is for some leased line system in Russia that has since been discontinued, and useless without any remote end to connect to. As the driver still feels like a Linux-2.2 era artifact today, it appears that the best way forward is to just delete it. Link: https://www.tms.ru/%D0%90%D0%B4%D0%B0%D0%BF%D1%82%D0%B5%D1%80_%D0%B4%D0%BB%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D1%85_%D0%BB%D0%B8%D0%BD%D0%B8%D0%B9_Granch_SBNI12-10 Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller

wan: remove stale Kconfig entries

2021-08-03T12:05:26Z

The dscc4 driver was removed in 2019 but these Kconfig entries remain, so remove them as well. Fixes: 28c9eb9042a9 ("net/wan: dscc4: remove broken dscc4 driver") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller

drivers/net: Remove leading spaces in Kconfig

2021-05-17T23:04:54Z

Remove leading spaces before tabs in Kconfig file(s) by running the following command: $ find drivers/net -name 'Kconfig*' | xargs sed -r -i 's/^[ ]+\t/\t/' Signed-off-by: Juerg Haefliger Signed-off-by: David S. Miller

wan: ds26522: select CONFIG_BITREVERSE

2021-01-05T23:50:36Z

Without this, the driver runs into a link failure arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_ds26522_probe': slic_ds26522.c:(.text+0x100c): undefined reference to `byte_rev_table' arm-linux-gnueabi-ld: slic_ds26522.c:(.text+0x1cdc): undefined reference to `byte_rev_table' arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_write': slic_ds26522.c:(.text+0x1e4c): undefined reference to `byte_rev_table' Fixes: c37d4a0085c5 ("Maxim/driver: Add driver for maxim ds26522") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller

net: wan: Delete the DLCI / SDLA drivers

2020-11-17T21:33:29Z

The DLCI driver (dlci.c) implements the Frame Relay protocol. However, we already have another newer and better implementation of Frame Relay provided by the HDLC_FR driver (hdlc_fr.c). The DLCI driver's implementation of Frame Relay is used by only one hardware driver in the kernel - the SDLA driver (sdla.c). The SDLA driver provides Frame Relay support for the Sangoma S50x devices. However, the vendor provides their own driver (along with their own multi-WAN-protocol implementations including Frame Relay), called WANPIPE. I believe most users of the hardware would use the vendor-provided WANPIPE driver instead. (The WANPIPE driver was even once in the kernel, but was deleted in commit 8db60bcf3021 ("[WAN]: Remove broken and unmaintained Sangoma drivers.") because the vendor no longer updated the in-kernel WANPIPE driver.) Cc: Mike McLagan Signed-off-by: Xie He Link: https://lore.kernel.org/r/20201114150921.685594-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski

net: x25_asy: Delete the x25_asy driver

2020-11-07T22:13:44Z

This driver transports LAPB (X.25 link layer) frames over TTY links. I can safely say that this driver has no actual user because it was not working at all until: commit 8fdcabeac398 ("drivers/net/wan/x25_asy: Fix to make it work") The code in its current state still has problems: 1. The uses of "struct x25_asy" in x25_asy_unesc (when receiving) and in x25_asy_write_wakeup (when sending) are not protected by locks against x25_asy_change_mtu's changing of the transmitting/receiving buffers. Also, all "netif_running" checks in this driver are not protected by locks against the ndo_stop function. 2. The driver stops all TTY read/write when the netif is down. I think this is not right because this may cause the last outgoing frame before the netif goes down to be incompletely transmitted, and the first incoming frame after the netif goes up to be incompletely received. And there may also be other problems. I was planning to fix these problems but after recent discussions about deleting other old networking code, I think we may just delete this driver, too. Signed-off-by: Xie He Acked-by: Martin Schiller Link: https://lore.kernel.org/r/20201105073434.429307-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski