Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11 2024-03-11T09:36:11+00:00 2024-03-11T09:36:11+00:00 Herve Codina herve.codina@bootlin.com 2024-03-07T11:39:04+00:00 urn:sha1:d0f2258e79fd7dba9860e8c97117b3f91ad04371 The QMC HDLC driver provides support for HDLC using the QMC (QUICC Multichannel Controller) to transfer the HDLC data. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> 2023-12-12T22:05:24+00:00 Herve Codina herve.codina@bootlin.com 2023-11-28T13:25:30+00:00 urn:sha1:82c944d05b1a24c76948ee9d6bb1d7de1ebb8b3a A framer is a component in charge of an E1/T1 line interface. Connected usually to a TDM bus, it converts TDM frames to/from E1/T1 frames. It also provides information related to the E1/T1 line. The framer framework provides a set of APIs for the framer drivers (framer provider) to create/destroy a framer and APIs for the framer users (framer consumer) to obtain a reference to the framer, and use the framer. This basic implementation provides a framer abstraction for: - power on/off the framer - get the framer status (line state) - be notified on framer status changes - get/set the framer configuration Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231128132534.258459-2-herve.codina@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 2022-04-27T11:22:56+00:00 Jakub Kicinski kuba@kernel.org 2022-04-26T17:54:35+00:00 urn:sha1:bc6df26f1f785be9b4c10d37e50ac40b46428984 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 <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 2022-04-27T11:22:56+00:00 Jakub Kicinski kuba@kernel.org 2022-04-26T17:54:34+00:00 urn:sha1:89fbca3307d40d5a48bc41919a543dc46298cf7a 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 <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 2022-04-06T14:28:23+00:00 Jakub Kicinski kuba@kernel.org 2022-04-06T04:15:48+00:00 urn:sha1:a5b116a0fa90d6d0e7af4f39199a6ae1f0afc9c7 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 <kuba@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net> 2021-09-16T13:08:04+00:00 Adam Borowski kilobyte@angband.pl 2021-09-12T21:23:21+00:00 urn:sha1:84fb7dfc7463afcba61281f36535576a7f7b0626 It was used but never set. The hardcoded value from before the dawn of time was non-standard; the usual name for cross-tools is $TRIPLET-$TOOL Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: David S. Miller <davem@davemloft.net> 2021-08-03T12:05:26+00:00 Arnd Bergmann arnd@arndb.de 2021-08-03T11:40:49+00:00 urn:sha1:72bcad5393a7079706fcfe02d84ed1599716d6a2 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 <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> 2020-11-17T21:33:29+00:00 Xie He xie.he.0141@gmail.com 2020-11-14T15:09:21+00:00 urn:sha1:f73659192b0bdf7bad826587b3530cef43cc048d 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 <mike.mclagan@linux.org> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201114150921.685594-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 2020-11-07T22:13:44+00:00 Xie He xie.he.0141@gmail.com 2020-11-05T07:34:34+00:00 urn:sha1:f8ae7bbec726f4d09ca19ecea45ea147b8801e10 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 <xie.he.0141@gmail.com> Acked-by: Martin Schiller <ms@dev.tdt.de> Link: https://lore.kernel.org/r/20201105073434.429307-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 2020-03-29T13:37:53+00:00 Masahiro Yamada masahiroy@kernel.org 2020-03-26T05:57:17+00:00 urn:sha1:7d7df745b0a63af33415ec234b29b9d6ed59ad8c Split the big recipe into 3 stages: compile, link, and hexdump. After this commit, the build log with CONFIG_WANXL_BUILD_FIRMWARE will look like this: M68KAS drivers/net/wan/wanxlfw.o M68KLD drivers/net/wan/wanxlfw.bin BLDFW drivers/net/wan/wanxlfw.inc CC [M] drivers/net/wan/wanxl.o Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>