Changes in Makefile

e419ddea - m68k: Use kernel's generic muldi3 libgcc function

Mon, 13 Nov 2023 13:32:09 +0000

m68k: Use kernel's generic muldi3 libgcc functionUse the kernels own generic lib/muldi3.c implementation of muldi3 for68K machines. Some 68K CPUs support 64bit multiplies so move the archspecific umul_ppmm() macro into a header file that is included bylib/muldi3.c. That way it can take advantage of the single instructionwhen available.There does not appear to be any existing mechanism for the genericlib/muldi3.c code to pick up an external arch definition of umul_ppmm().Create an arch specific libgcc.h that can optionally be included bythe system include/linux/libgcc.h to allow for this.Somewhat oddly there is also a similar definition of umul_ppmm() inthe non-architecture code in lib/crypto/mpi/longlong.h for a wide rangeor machines. Its presence ends up complicating the include setup andmeans not being able to use something like compiler.h instead. Actuallythere is a few other defines of umul_ppmm() macros spread around invarious architectures, but not directly usable for the m68k case.Signed-off-by: Greg Ungerer Link: https://lore.kernel.org/20231113133209.1367286-1-gerg@linux-m68k.orgReviewed-by: Geert Uytterhoeven Reviewed-by: Arnd Bergmann Signed-off-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

a0938a8e - m68k: Use kernel's generic libgcc functions

Wed, 13 Sep 2023 07:13:50 +0000

m68k: Use kernel's generic libgcc functionsThe arch/m68k/lib versions of the libgcc functions: ashldi3, ashrdi3and lshrdi3 were taken directly from an older version of gcc.We can use the kernel's own generic lib versions of these - they arevirtually identical. Switch to those and remove the m68k local ones.Signed-off-by: Greg Ungerer Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230913071350.1939818-1-gerg@kernel.orgSigned-off-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/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/arch/m68k/lib/Makefile

d346a5db - m68k: Remove inline strcpy() and strcat() implementations

Sun, 14 Apr 2013 20:17:20 +0000

m68k: Remove inline strcpy() and strcat() implementationsGcc may replace calls to standard string functions by open code and/orcalls to other standard string functions. If the replacement function isnot available out-of-line, link errors will happen.To avoid this, the out-of-line versions were provided byarch/m68k/lib/string.c, but they were usually not linked in anymore astypically none of its symbols are referenced by built-in code.However, if any module would need them, they would not be available.Hence remove the inline strcpy() and strcat() implementations, removearch/m68k/lib/string.c, and let the generic string library code handle it.Impact on a typical kernel build seems minimal or nonexistent:- .text : 0x00001000 - 0x002aac74 (2728 KiB)- .data : 0x002ada48 - 0x00392148 ( 914 KiB)+ .text : 0x00001000 - 0x002aacf4 (2728 KiB)+ .data : 0x002adac8 - 0x00392148 ( 914 KiB)See also commit e00c73ee05dc38ecaccced55d4f5fc58b0b769f7 ("m68k: Removeinline strlen() implementation").Signed-off-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

84f3fb7a - m68k: handle presence of 64bit mul/div instructions cleanly

Fri, 11 Nov 2011 05:13:08 +0000

m68k: handle presence of 64bit mul/div instructions cleanlyThe traditional 68000 processors and the newer reduced instruction setColdFire processors do not support the 32*32->64 multiply or the 64/32->32divide instructions. This is not a difference based on the presence ofa hardware MMU or not.Create a new config symbol to mark that a CPU type doesn't support thelonger multiply/divide instructions. Use this then as a basis for usingthe fast 64bit based divide (in div64.h) and for linking in the extralibgcc functions that may be required (mulsi3, divsi3, etc).Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

7f73bafc - m68k: simpler m68k and ColdFire CPU's can use generic csum code

Tue, 18 Oct 2011 05:49:19 +0000

m68k: simpler m68k and ColdFire CPU's can use generic csum codeWe have two implementations of the IP checksuming code for the m68k arch.One uses the more advanced instructions available in 68020 and aboveprocessors, the other uses the simpler instructions available on theoriginal 68000 processors and the modern ColdFire processors.This simpler code is pretty much the same as the generic lib implementationof the IP csum functions. So lets just switch over to using that. Thatmeans we can completely remove the checksum_no.c file, and only have thelocal fast code used for the more complex 68k CPU family members.Signed-off-by: Greg Ungerer List of files: /linux-6.15/arch/m68k/lib/Makefile

7c946199 - m68k: merge and clean up delay.h files

Fri, 01 Jul 2011 06:47:13 +0000

m68k: merge and clean up delay.h filesThe real difference between the mmu and non-mmu varients of the delay.hfiles has nothing to do with having an mmu or not. It is processor familydifferences that means slightly different code. Merge the delay_mm.h anddelay_no.h files back into a single file.The primarly difference we need to deal with is whether the processorsupports a 32bit * 32bit -> 64bit multiply. Without it we need to do someshift scaling as well as use a 32bit * 32bit -> 32bit multiply. If buildingfor a multi-CPU type kernel then we must use the simpler mult/shift scaling.This version of delay code allows the CPU32 family to use a 64bit mul,since it supports this instruction, the old code did not.The changes use macros where appropriate to try and optimize constant sizedudelay times. And it removes the use of a fixed lib function for the non-mmucase. Code size on typical kernel configurations is similar, or only largerby a few tens of bytes.Also removed the unused muldiv() code from delay_mm.h.Build and run tested on ColdFire and ARAnyM. Build tested only on 68328and 68360 (CPU32).Signed-off-by: Greg Ungerer List of files: /linux-6.15/arch/m68k/lib/Makefile

9461702d - m68k: let Makefile sort out compiling mmu and non-mmu lib/checksum.c

Mon, 18 Apr 2011 05:27:55 +0000

m68k: let Makefile sort out compiling mmu and non-mmu lib/checksum.cWe don't need an arch/m68k/lib/checksum.c wrapper to include the correctmmu or non-mmu version of the checksum code. Let the Makefile just buildthe appropriate one.Signed-off-by: Greg Ungerer List of files: /linux-6.15/arch/m68k/lib/Makefile

66d83ab3 - m68k: remove duplicate memcpy() implementation

Mon, 28 Mar 2011 06:53:37 +0000

m68k: remove duplicate memcpy() implementationMerging the mmu and non-mmu directories we ended up with duplicateimplementations of memcpy(). One is a little more optimized for the>= 68020 case, but that can easily be inserted into a singleimplementation of memcpy(). Clean up the exporting of this symboltoo, otherwise we end up exporting it twice on a no-mmu build.Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

d10ed2f5 - m68k: remove duplicate memset() implementation

Mon, 28 Mar 2011 06:48:00 +0000

m68k: remove duplicate memset() implementationMerging the mmu and non-mmu directories we ended up with duplicateimplementations of memset(). One is a little more optimized for the>= 68020 case, but that can easily be inserted into a singleimplementation of memset(). Clean up the exporting of this symboltoo, otherwise we end up exporting it twice on a no-mmu build.Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

80160de8 - m68k: remove duplicate memmove() implementation

Mon, 28 Mar 2011 06:44:28 +0000

m68k: remove duplicate memmove() implementationMerging the mmu and non-mmu directories we ended up with duplicate(and identical) implementations of memmove(). Remove one of them.Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

b82ed87e - m68k: merge mmu and non-mmu versions of lib/Makefile

Mon, 28 Mar 2011 05:58:49 +0000

m68k: merge mmu and non-mmu versions of lib/MakefileWe can easily support the slight differences in libs needed by themmu and non-mmu builds in a single Makefile, so merge them back intoa single file again.Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven List of files: /linux-6.15/arch/m68k/lib/Makefile

66d857b0 - m68k: merge m68k and m68knommu arch directories

Tue, 22 Mar 2011 03:39:27 +0000

m68k: merge m68k and m68knommu arch directoriesThere is a lot of common code that could be shared between the m68kand m68knommu arch branches. It makes sense to merge the two branchesinto a single directory structure so that we can more easily sharethat common code.This is a brute force merge, based on a script from Stephen King, which was originally written by Arnd Bergmann.> The script was inspired by the script Sam Ravnborg used to merge the> includes from m68knommu. For those files common to both arches but> differing in content, the m68k version of the file is renamed to> _mm. and the m68knommu version of the file is moved into the> corresponding m68k directory and renamed _no. and a small> wrapper file . is used to select between the two version. Files> that are common to both but don't differ are removed from the m68knommu> tree and files and directories that are unique to the m68knommu tree are> moved to the m68k tree. Finally, the arch/m68knommu tree is removed.>> To select between the the versions of the files, the wrapper uses>> #ifdef CONFIG_MMU> #include _mm.> #else> #include _no.> #endifOn top of this file merge I have done a simplistic merge of m68k andm68knommu Kconfig, which primarily attempts to keep existing options andmenus in place. Other than a handful of options being moved it producesidentical .config outputs on m68k and m68knommu targets I tested it on.With this in place there is now quite a bit of scope for merge cleanupsin future patches.Signed-off-by: Greg Ungerer List of files: /linux-6.15/arch/m68k/lib/Makefile

a0c14d28 - Stringify support commas

Thu, 17 Jul 2008 19:16:13 +0000

Stringify support commas> This is a no-no for those archs that still use -traditional. > > I dunno if this is a problem for you at the moment and the > > right fix is anyway to nuke -traditional. > > > > SamSigned-off-by: Mathieu Desnoyers Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/m68k/lib/Makefile

64ac24e7 - Generic semaphore implementation

Sat, 08 Mar 2008 02:55:58 +0000

Generic semaphore implementationSemaphores are no longer performance-critical, so a generic Cimplementation is better for maintainability, debuggability andextensibility. Thanks to Peter Zijlstra for fixing the lockdepwarning. Thanks to Harvey Harrison for pointing out that theunlikely() was unnecessary.Signed-off-by: Matthew Wilcox Acked-by: Ingo Molnar List of files: /linux-6.15/arch/m68k/lib/Makefile

d94af931 - [PATCH] m68k: clean up uaccess.h

Fri, 23 Jun 2006 09:05:00 +0000

[PATCH] m68k: clean up uaccess.hThis uninlines a few large functions in uaccess.h and cleans up the rest.It includes a (hopefully temporary) workaround for the broken typeof ofgcc-4.1.Signed-off-by: Roman Zippel Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/m68k/lib/Makefile

072dffda - [PATCH] m68k: cleanup inline mem functions

Sat, 03 Sep 2005 22:57:10 +0000

[PATCH] m68k: cleanup inline mem functionsUse the builtin functions for memset/memclr/memcpy, special optimizations forpage operations have dedicated functions now. Uninline memmove/memchr andmove all functions into a single file and clean it up a little.Signed-off-by: Roman Zippel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/m68k/lib/Makefile

1da177e4 - Linux-2.6.12-rc2

Sat, 16 Apr 2005 22:20:36 +0000

Linux-2.6.12-rc2Initial git repository build. I'm not bothering with the full history,even though we have it. We can create a separate "historical" gitarchive of that later if we want to, and in the meantime it's about3.2GB when imported into git - space that would just make the earlygit days unnecessarily complicated, when we don't have a lot of goodinfrastructure for it.Let it rip! List of files: /linux-6.15/arch/m68k/lib/Makefile