Changes in Makefile

d0f2258e - net: wan: Add support for QMC HDLC

Thu, 07 Mar 2024 11:39:04 +0000

net: wan: Add support for QMC HDLCThe QMC HDLC driver provides support for HDLC using the QMC (QUICCMultichannel Controller) to transfer the HDLC data.Signed-off-by: Herve Codina Reviewed-by: Christophe Leroy Acked-by: Jakub Kicinski Reviewed-by: Andy Shevchenko Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

82c944d0 - net: wan: Add framer framework support

Tue, 28 Nov 2023 13:25:30 +0000

net: wan: Add framer framework supportA 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/T1frames. 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 framerusers (framer consumer) to obtain a reference to the framer, anduse 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 configurationSigned-off-by: Herve Codina Reviewed-by: Christophe Leroy Acked-by: Jakub Kicinski Link: https://lore.kernel.org/r/20231128132534.258459-2-herve.codina@bootlin.comSigned-off-by: Linus Walleij List of files: /linux-6.15/drivers/net/wan/Makefile

bc6df26f - net: wan: remove support for Z85230-based devices

Tue, 26 Apr 2022 17:54:35 +0000

net: wan: remove support for Z85230-based devicesLooks like all the changes to this driver had been automatedchurn 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 List of files: /linux-6.15/drivers/net/wan/Makefile

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

Tue, 26 Apr 2022 17:54:34 +0000

net: wan: remove support for COSA and SRP synchronous serial boardsLooks like all the changes to this driver had been automatedchurn since git era begun. The driver is using virt_to_bus()so it should be updated to a proper DMA API or removed. Giventhe latest "news" entry on the website is from 1999 I'm optingfor 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 itsCOSA?Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

a5b116a0 - net: wan: remove the lanmedia (lmc) driver

Wed, 06 Apr 2022 04:15:48 +0000

net: wan: remove the lanmedia (lmc) driverThe driver for LAN Media WAN interfaces spews build warnings onmicroblaze. The virt_to_bus() calls discard the volatile keyword.The right thing to do would be to migrate this driver to a modernDMA API but it seems unlikely anyone is actually using it.There had been no fixes or functional changes here sincethe 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 List of files: /linux-6.15/drivers/net/wan/Makefile

84fb7dfc - net: wan: wanxl: define CROSS_COMPILE_M68K

Sun, 12 Sep 2021 21:23:21 +0000

net: wan: wanxl: define CROSS_COMPILE_M68KIt was used but never set. The hardcoded value from before the dawn oftime was non-standard; the usual name for cross-tools is $TRIPLET-$TOOLSigned-off-by: Adam Borowski Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

72bcad53 - wan: remove sbni/granch driver

Tue, 03 Aug 2021 11:40:49 +0000

wan: remove sbni/granch driverThe driver was merged in 1999 and has only ever seen treewide cleanupssince then, with no indication whatsoever that anyone has actuallyhad access to hardware for testing the patches.>From the information in the link below, it appears that the hardwareis for some leased line system in Russia that has since beendiscontinued, and useless without any remote end to connect to.As the driver still feels like a Linux-2.2 era artifact today, itappears 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-10Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

f7365919 - net: wan: Delete the DLCI / SDLA drivers

Sat, 14 Nov 2020 15:09:21 +0000

net: wan: Delete the DLCI / SDLA driversThe DLCI driver (dlci.c) implements the Frame Relay protocol. However,we already have another newer and better implementation of Frame Relayprovided by the HDLC_FR driver (hdlc_fr.c).The DLCI driver's implementation of Frame Relay is used by only onehardware 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 ownmulti-WAN-protocol implementations including Frame Relay), called WANPIPE.I believe most users of the hardware would use the vendor-provided WANPIPEdriver instead.(The WANPIPE driver was even once in the kernel, but was deleted incommit 8db60bcf3021 ("[WAN]: Remove broken and unmaintained Sangomadrivers.") because the vendor no longer updated the in-kernel WANPIPEdriver.)Cc: Mike McLagan Signed-off-by: Xie He Link: https://lore.kernel.org/r/20201114150921.685594-1-xie.he.0141@gmail.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/drivers/net/wan/Makefile

f8ae7bbe - net: x25_asy: Delete the x25_asy driver

Thu, 05 Nov 2020 07:34:34 +0000

net: x25_asy: Delete the x25_asy driverThis driver transports LAPB (X.25 link layer) frames over TTY links.I can safely say that this driver has no actual user because it wasnot 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 inx25_asy_write_wakeup (when sending) are not protected by locks againstx25_asy_change_mtu's changing of the transmitting/receiving buffers.Also, all "netif_running" checks in this driver are not protected bylocks 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 framebefore the netif goes down to be incompletely transmitted, and the firstincoming 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 aboutdeleting other old networking code, I think we may just delete thisdriver, too.Signed-off-by: Xie He Acked-by: Martin Schiller Link: https://lore.kernel.org/r/20201105073434.429307-1-xie.he.0141@gmail.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/drivers/net/wan/Makefile

7d7df745 - net: wan: wanxl: refactor the firmware rebuild rule

Thu, 26 Mar 2020 05:57:17 +0000

net: wan: wanxl: refactor the firmware rebuild ruleSplit the big recipe into 3 stages: compile, link, and hexdump.After this commit, the build log with CONFIG_WANXL_BUILD_FIRMWAREwill 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.oSigned-off-by: Masahiro Yamada List of files: /linux-6.15/drivers/net/wan/Makefile

734f3719 - net: wan: wanxl: use $(M68KCC) instead of $(M68KAS) for rebuilding firmware

Thu, 26 Mar 2020 05:57:16 +0000

net: wan: wanxl: use $(M68KCC) instead of $(M68KAS) for rebuilding firmwareThe firmware source, wanxlfw.S, is currently compiled by the combo of$(CPP) and $(M68KAS). This is not what we usually do for compiling *.Sfiles. In fact, this Makefile is the only user of $(AS) in the kernelbuild.Instead of combining $(CPP) and (AS) from different tool sets, using$(M68KCC) as an assembler driver is simpler, and saner.Signed-off-by: Masahiro Yamada List of files: /linux-6.15/drivers/net/wan/Makefile

63b903df - net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware

Thu, 26 Mar 2020 05:57:15 +0000

net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmwareAs far as I understood from the Kconfig help text, this build rule isused to rebuild the driver firmware, which runs on an old m68k-basedchip. So, you need m68k tools for the firmware rebuild.wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI.So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In otherwords, ifeq ($(ARCH),m68k) is false here.I am keeping the dead code for now, but rebuilding the firmware requires'as68k' and 'ld68k', which I do not have in hand.Instead, the kernel.org m68k GCC [1] successfully built it.Allowing a user to pass in CROSS_COMPILE_M68K= is handier.[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/x86_64-gcc-9.2.0-nolibc-m68k-linux.tar.xzSuggested-by: Geert Uytterhoeven Signed-off-by: Masahiro Yamada List of files: /linux-6.15/drivers/net/wan/Makefile

28c9eb90 - net/wan: dscc4: remove broken dscc4 driver

Fri, 13 Sep 2019 13:28:17 +0000

net/wan: dscc4: remove broken dscc4 driverUsing static analysis, I discovered that the "dpriv->pci_priv->pdev"pointer is always NULL. This pointer was supposed to be initializedduring probe and is essential for the driver to work. It would be easyto add a "ppriv->pdev = pdev;" to dscc4_found1() but this driver hasbeen broken since before we started using git and no one has complainedso probably we should just remove it.Signed-off-by: Dan Carpenter Acked-by: Francois Romieu Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/net/wan/Makefile

c37d4a00 - Maxim/driver: Add driver for maxim ds26522

Mon, 27 Jun 2016 01:30:22 +0000

Maxim/driver: Add driver for maxim ds26522Signed-off-by: Zhao Qiang Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

c19b6d24 - drivers/net: support hdlc function for QE-UCC

Mon, 06 Jun 2016 06:30:02 +0000

drivers/net: support hdlc function for QE-UCCThe driver add hdlc support for Freescale QUICC Engine.It support NMSI and TSA mode.Signed-off-by: Zhao Qiang Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

a786a7c0 - wanrouter: completely decouple obsolete code from kernel.

Thu, 31 Jan 2013 02:49:29 +0000

wanrouter: completely decouple obsolete code from kernel.The original suggestion to delete wanrouter started earlierwith the mainline commit f0d1b3c2bcc5de8a17af5f2274f7fcde8292b5fc("net/wanrouter: Deprecate and schedule for removal") in May 2012.More importantly, Dan Carpenter found[1] that the driver had afundamental breakage introduced back in 2008, with commit7be6065b39c3 ("netdevice wanrouter: Convert directly reference ofnetdev->priv"). So we know with certainty that the code hasn't beenused by anyone willing to at least take the effort to send an e-mailreport of breakage for at least 4 years.This commit does a decouple of the wanrouter subsystem, by goingafter the Makefile/Kconfig and similar files, so that these mainlinefiles that we are keeping do not have the big wanrouter file/driverdeletion commit tied into their history.Once this commit is in place, we then can remove the obsolete cyclomxdrivers and similar that have a dependency on CONFIG_WAN_ROUTER_DRIVERS.[1] http://www.spinics.net/lists/netdev/msg218670.htmlOriginally-by: Joe Perches Cc: Dan Carpenter Cc: Arnaldo Carvalho de Melo Signed-off-by: Paul Gortmaker List of files: /linux-6.15/drivers/net/wan/Makefile

b1ead1ae - Make the wanxl firmware array const

Wed, 07 Nov 2012 02:37:31 +0000

Make the wanxl firmware array constMake the wanxl firmware array const so that it goes in the read-only section.Signed-off-by: David Howells Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

c48c8d51 - Fix the wanxl firmware to include missing constants

Wed, 07 Nov 2012 02:37:24 +0000

Fix the wanxl firmware to include missing constantsFix the wanxl firmware to include missing constants such as PARITY_NONE. Itshould be #including the linux/hdlc/ioctl.h header.To make this work, we also have to guard parts of ioctl.h with !__ASSEMBLY__.Signed-off-by: David Howells Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile

bdd4f8cb - UAPI: Fix compilation of the wanxl firmware blob.

Wed, 07 Nov 2012 02:37:09 +0000

UAPI: Fix compilation of the wanxl firmware blob.The wanxl firmware needs access to some bits of UAPI stuff, so the -I flag inthe Makefile needs adjusting to point at the UAPI headers.Signed-off-by: David Howells Signed-off-by: David S. Miller List of files: /linux-6.15/drivers/net/wan/Makefile