<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>4be07393 - lib/raid6: use CC_FLAGS_FPU for NEON CFLAGS</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#4be07393</link>
        <description>lib/raid6: use CC_FLAGS_FPU for NEON CFLAGSNow that CC_FLAGS_FPU is exported and can be used anywhere in the sourcetree, use it instead of duplicating the flags here.Link: https://lkml.kernel.org/r/20240329072441.591471-7-samuel.holland@sifive.comSigned-off-by: Samuel Holland &lt;samuel.holland@sifive.com&gt;Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;Acked-by: Christian K&#246;nig &lt;christian.koenig@amd.com&gt; Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;Cc: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;Cc: Huacai Chen &lt;chenhuacai@kernel.org&gt;Cc: Ingo Molnar &lt;mingo@redhat.com&gt;Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;Cc: Masahiro Yamada &lt;masahiroy@kernel.org&gt;Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;Cc: Nicolas Schier &lt;nicolas@fjasle.eu&gt;Cc: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;Cc: Russell King &lt;linux@armlinux.org.uk&gt;Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;Cc: WANG Xuerui &lt;git@xen0n.name&gt;Cc: Will Deacon &lt;will@kernel.org&gt;Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Fri, 29 Mar 2024 07:18:21 +0000</pubDate>
        <dc:creator>Samuel Holland &lt;samuel.holland@sifive.com&gt;</dc:creator>
    </item>
<item>
        <title>b1992c37 - kbuild: use $(src) instead of $(srctree)/$(src) for source directory</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#b1992c37</link>
        <description>kbuild: use $(src) instead of $(srctree)/$(src) for source directoryKbuild conventionally uses $(obj)/ for generated files, and $(src)/ forchecked-in source files. It is merely a convention without any functionaldifference. In fact, $(obj) and $(src) are exactly the same, as definedin scripts/Makefile.build:    src := $(obj)When the kernel is built in a separate output directory, $(src) doesnot accurately reflect the source directory location. While Kbuildresolves this discrepancy by specifying VPATH=$(srctree) to search forsource files, it does not cover all cases. For example, when adding aheader search path for local headers, -I$(srctree)/$(src) is typicallypassed to the compiler.This introduces inconsistency between upstream and downstream Makefilesbecause $(src) is used instead of $(srctree)/$(src) for the latter.To address this inconsistency, this commit changes the semantics of$(src) so that it always points to the directory in the source tree.Going forward, the variables used in Makefiles will have the followingmeanings:  $(obj)     - directory in the object tree  $(src)     - directory in the source tree  (changed by this commit)  $(objtree) - the top of the kernel object tree  $(srctree) - the top of the kernel source treeConsequently, $(srctree)/$(src) in upstream Makefiles need to be replacedwith $(src).Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;Reviewed-by: Nicolas Schier &lt;nicolas@fjasle.eu&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Sat, 27 Apr 2024 14:55:02 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>2947a456 - treewide: update LLVM Bugzilla links</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#2947a456</link>
        <description>treewide: update LLVM Bugzilla linksLLVM moved their issue tracker from their own Bugzilla instance to GitHubissues.  While all of the links are still valid, they may not necessarilyshow the most up to date information around the issues, as all updateswill occur on GitHub, not Bugzilla.Another complication is that the Bugzilla issue number is not always thesame as the GitHub issue number.  Thankfully, LLVM maintains this mappingthrough two shortlinks:  https://llvm.org/bz&lt;num&gt; -&gt; https://bugs.llvm.org/show_bug.cgi?id=&lt;num&gt;  https://llvm.org/pr&lt;num&gt; -&gt; https://github.com/llvm/llvm-project/issues/&lt;mapped_num&gt;Switch all &quot;https://bugs.llvm.org/show_bug.cgi?id=&lt;num&gt;&quot; links to the&quot;https://llvm.org/pr&lt;num&gt;&quot; shortlink so that the links show the most up todate information.  Each migrated issue links back to the Bugzilla entry,so there should be no loss of fidelity of information here.Link: https://lkml.kernel.org/r/20240109-update-llvm-links-v1-3-eb09b59db071@kernel.orgSigned-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;Acked-by: Fangrui Song &lt;maskray@google.com&gt;Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;Cc: Andrii Nakryiko &lt;andrii@kernel.org&gt;Cc: Daniel Borkmann &lt;daniel@iogearbox.net&gt;Cc: Mykola Lysenko &lt;mykolal@fb.com&gt;Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Tue, 09 Jan 2024 22:16:31 +0000</pubDate>
        <dc:creator>Nathan Chancellor &lt;nathan@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>b089ea3c - lib/raid6: Drop IA64 support</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#b089ea3c</link>
        <description>lib/raid6: Drop IA64 supportDrop Itanium support from the RAID6 code, and along with it, the 16x and32x unrolled versions, which were only used by IA64.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Fri, 13 Jan 2023 17:08:32 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>f2091321 - raid6: Add LoongArch SIMD recovery implementation</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#f2091321</link>
        <description>raid6: Add LoongArch SIMD recovery implementationSimilar to the syndrome calculation, the recovery algorithms also workon 64 bytes at a time to align with the L1 cache line size of currentand future LoongArch cores (that we care about). Which meansunrolled-by-4 LSX and unrolled-by-2 LASX code.The assembly is originally based on the x86 SSSE3/AVX2 ports, butregister allocation has been redone to take advantage of LSX/LASX&apos;s 32vector registers, and instruction sequence has been optimized to suit(e.g. LoongArch can perform per-byte srl and andi on vectors, but x86cannot).Performance numbers measured by instrumenting the raid6test code, on a3A5000 system clocked at 2.5GHz:&gt; lasx  2data: 354.987 MiB/s&gt; lasx  datap: 350.430 MiB/s&gt; lsx   2data: 340.026 MiB/s&gt; lsx   datap: 337.318 MiB/s&gt; intx1 2data: 164.280 MiB/s&gt; intx1 datap: 187.966 MiB/sBecause recovery algorithms are chosen solely based on priority andavailability, lasx is marked as priority 2 and lsx priority 1. At leastfor the current generation of LoongArch micro-architectures, LASX shouldalways be faster than LSX whenever supported, and have similar powerconsumption characteristics (because the only known LASX-capable uarch,the LA464, always compute the full 256-bit result for vector ops).Acked-by: Song Liu &lt;song@kernel.org&gt;Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Wed, 06 Sep 2023 14:53:55 +0000</pubDate>
        <dc:creator>WANG Xuerui &lt;git@xen0n.name&gt;</dc:creator>
    </item>
<item>
        <title>8f3f06df - raid6: Add LoongArch SIMD syndrome calculation</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#8f3f06df</link>
        <description>raid6: Add LoongArch SIMD syndrome calculationThe algorithms work on 64 bytes at a time, which is the L1 cache linesize of all current and future LoongArch cores (that we care about), asconfirmed by Huacai. The code is based on the generic int.uc algorithm,unrolled 4 times for LSX and 2 times for LASX. Further unrolling doesnot meaningfully improve the performance according to experiments.Performance numbers measured during system boot on a 3A5000 @ 2.5GHz:&gt; raid6: lasx     gen() 12726 MB/s&gt; raid6: lsx      gen() 10001 MB/s&gt; raid6: int64x8  gen()  2876 MB/s&gt; raid6: int64x4  gen()  3867 MB/s&gt; raid6: int64x2  gen()  2531 MB/s&gt; raid6: int64x1  gen()  1945 MB/sComparison of xor() speeds (from different boots but meaningful anyway):&gt; lasx:    11226 MB/s&gt; lsx:     6395 MB/s&gt; int64x4: 2147 MB/sPerformance as measured by raid6test:&gt; raid6: lasx     gen() 25109 MB/s&gt; raid6: lsx      gen() 13233 MB/s&gt; raid6: int64x8  gen()  4164 MB/s&gt; raid6: int64x4  gen()  6005 MB/s&gt; raid6: int64x2  gen()  5781 MB/s&gt; raid6: int64x1  gen()  4119 MB/s&gt; raid6: using algorithm lasx gen() 25109 MB/s&gt; raid6: .... xor() 14439 MB/s, rmw enabledAcked-by: Song Liu &lt;song@kernel.org&gt;Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Wed, 06 Sep 2023 14:53:55 +0000</pubDate>
        <dc:creator>WANG Xuerui &lt;git@xen0n.name&gt;</dc:creator>
    </item>
<item>
        <title>04e85bbf - isystem: delete global -isystem compile option</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#04e85bbf</link>
        <description>isystem: delete global -isystem compile optionFurther isolate kernel from userspace, prevent accidental inclusion ofundesireable headers, mainly float.h and stdatomic.h.nds32 keeps -isystem globally due to intrinsics used in entrenched header.-isystem is selectively reenabled for some files, again, for intrinsics.Compile tested on:hexagon-defconfig hexagon-allmodconfigalpha-allmodconfig alpha-allnoconfig alpha-defconfig arm64-allmodconfigarm64-allnoconfig arm64-defconfig arm-am200epdkit arm-aspeed_g4arm-aspeed_g5 arm-assabet arm-at91_dt arm-axm55xx arm-badge4 arm-bcm2835arm-cerfcube arm-clps711x arm-cm_x300 arm-cns3420vb arm-colibri_pxa270arm-colibri_pxa300 arm-collie arm-corgi arm-davinci_all arm-dovearm-ep93xx arm-eseries_pxa arm-exynos arm-ezx arm-footbridge arm-geminiarm-h3600 arm-h5000 arm-hackkit arm-hisi arm-imote2 arm-imx_v4_v5arm-imx_v6_v7 arm-integrator arm-iop32x arm-ixp4xx arm-jornada720arm-keystone arm-lart arm-lpc18xx arm-lpc32xx arm-lpd270 arm-lubbockarm-magician arm-mainstone arm-milbeaut_m10v arm-mini2440 arm-mmp2arm-moxart arm-mps2 arm-multi_v4t arm-multi_v5 arm-multi_v7 arm-mv78xx0arm-mvebu_v5 arm-mvebu_v7 arm-mxs arm-neponset arm-netwinder arm-nhk8815arm-omap1 arm-omap2plus arm-orion5x arm-oxnas_v6 arm-palmz72 arm-pcm027arm-pleb arm-pxa arm-pxa168 arm-pxa255-idp arm-pxa3xx arm-pxa910arm-qcom arm-realview arm-rpc arm-s3c2410 arm-s3c6400 arm-s5pv210arm-sama5 arm-shannon arm-shmobile arm-simpad arm-socfpga arm-spear13xxarm-spear3xx arm-spear6xx arm-spitz arm-stm32 arm-sunxi arm-tct_hammerarm-tegra arm-trizeps4 arm-u8500 arm-versatile arm-vexpress arm-vf610m4arm-viper arm-vt8500_v6_v7 arm-xcep arm-zeus csky-allmodconfigcsky-allnoconfig csky-defconfig h8300-edosk2674 h8300-h8300h-simh8300-h8s-sim i386-allmodconfig i386-allnoconfig i386-defconfigia64-allmodconfig ia64-allnoconfig ia64-bigsur ia64-generic ia64-gensparseia64-tiger ia64-zx1 m68k-amcore m68k-amiga m68k-apollo m68k-atarim68k-bvme6000 m68k-hp300 m68k-m5208evb m68k-m5249evb m68k-m5272c3m68k-m5275evb m68k-m5307c3 m68k-m5407c3 m68k-m5475evb m68k-macm68k-multi m68k-mvme147 m68k-mvme16x m68k-q40 m68k-stmark2 m68k-sun3m68k-sun3x microblaze-allmodconfig microblaze-allnoconfig microblaze-mmumips-ar7 mips-ath25 mips-ath79 mips-bcm47xx mips-bcm63xx mips-bigsurmips-bmips_be mips-bmips_stb mips-capcella mips-cavium_octeon mips-ci20mips-cobalt mips-cu1000-neo mips-cu1830-neo mips-db1xxx mips-decstationmips-decstation_64 mips-decstation_r4k mips-e55 mips-fuloong2emips-gcw0 mips-generic mips-gpr mips-ip22 mips-ip27 mips-ip28 mips-ip32mips-jazz mips-jmr3927 mips-lemote2f mips-loongson1b mips-loongson1cmips-loongson2k mips-loongson3 mips-malta mips-maltaaprp mips-malta_kvmmips-malta_qemu_32r6 mips-maltasmvp mips-maltasmvp_eva mips-maltaupmips-maltaup_xpa mips-mpc30x mips-mtx1 mips-nlm_xlp mips-nlm_xlrmips-omega2p mips-pic32mzda mips-pistachio mips-qi_lb60 mips-rb532mips-rbtx49xx mips-rm200 mips-rs90 mips-rt305x mips-sb1250_swarmmips-tb0219 mips-tb0226 mips-tb0287 mips-vocore2 mips-workpad mips-xwaynds32-allmodconfig nds32-allnoconfig nds32-defconfig nios2-10m50nios2-3c120 nios2-allmodconfig nios2-allnoconfig openrisc-allmodconfigopenrisc-allnoconfig openrisc-or1klitex openrisc-or1ksimopenrisc-simple_smp parisc-allnoconfig parisc-generic-32bitparisc-generic-64bit powerpc-acadia powerpc-adder875 powerpc-akebonopowerpc-amigaone powerpc-arches powerpc-asp8347 powerpc-bamboopowerpc-bluestone powerpc-canyonlands powerpc-cell powerpc-chrp32powerpc-cm5200 powerpc-currituck powerpc-ebony powerpc-eigerpowerpc-ep8248e powerpc-ep88xc powerpc-fsp2 powerpc-g5 powerpc-gamecubepowerpc-ge_imp3a powerpc-holly powerpc-icon powerpc-iss476-smppowerpc-katmai powerpc-kilauea powerpc-klondike powerpc-kmeter1powerpc-ksi8560 powerpc-linkstation powerpc-lite5200b powerpc-makalupowerpc-maple powerpc-mgcoge powerpc-microwatt powerpc-motionpropowerpc-mpc512x powerpc-mpc5200 powerpc-mpc7448_hpc2 powerpc-mpc8272_adspowerpc-mpc8313_rdb powerpc-mpc8315_rdb powerpc-mpc832x_mdspowerpc-mpc832x_rdb powerpc-mpc834x_itx powerpc-mpc834x_itxgppowerpc-mpc834x_mds powerpc-mpc836x_mds powerpc-mpc836x_rdkpowerpc-mpc837x_mds powerpc-mpc837x_rdb powerpc-mpc83xxpowerpc-mpc8540_ads powerpc-mpc8560_ads powerpc-mpc85xx_cdspowerpc-mpc866_ads powerpc-mpc885_ads powerpc-mvme5100 powerpc-obs600powerpc-pasemi powerpc-pcm030 powerpc-pmac32 powerpc-powernvpowerpc-ppa8548 powerpc-ppc40x powerpc-ppc44x powerpc-ppc64powerpc-ppc64e powerpc-ppc6xx powerpc-pq2fads powerpc-ps3powerpc-pseries powerpc-rainier powerpc-redwood powerpc-sam440eppowerpc-sbc8548 powerpc-sequoia powerpc-skiroot powerpc-socratespowerpc-storcenter powerpc-stx_gp3 powerpc-taishan powerpc-tqm5200powerpc-tqm8540 powerpc-tqm8541 powerpc-tqm8548 powerpc-tqm8555powerpc-tqm8560 powerpc-tqm8xx powerpc-walnut powerpc-warp powerpc-wiipowerpc-xes_mpc85xx riscv-allmodconfig riscv-allnoconfig riscv-nommu_k210riscv-nommu_k210_sdcard riscv-nommu_virt riscv-rv32 s390-allmodconfigs390-allnoconfig s390-debug s390-zfcpdump sh-ap325rxa sh-apsh4a3ash-apsh4ad0a sh-dreamcast sh-ecovec24 sh-ecovec24-romimage sh-edosk7705sh-edosk7760 sh-espt sh-hp6xx sh-j2 sh-kfr2r09 sh-kfr2r09-romimagesh-landisk sh-lboxre2 sh-magicpanelr2 sh-microdev sh-migor sh-polarissh-r7780mp sh-r7785rp sh-rsk7201 sh-rsk7203 sh-rsk7264 sh-rsk7269sh-rts7751r2d1 sh-rts7751r2dplus sh-sdk7780 sh-sdk7786 sh-se7206 sh-se7343sh-se7619 sh-se7705 sh-se7712 sh-se7721 sh-se7722 sh-se7724 sh-se7750sh-se7751 sh-se7780 sh-secureedge5410 sh-sh03 sh-sh2007 sh-sh7710voipgwsh-sh7724_generic sh-sh7757lcr sh-sh7763rdp sh-sh7770_generic sh-sh7785lcrsh-sh7785lcr_32bit sh-shmin sh-shx3 sh-titan sh-ul2 sh-urquellsparc-allmodconfig sparc-allnoconfig sparc-sparc32 sparc-sparc64um-i386-allmodconfig um-i386-allnoconfig um-i386-defconfigum-x86_64-allmodconfig um-x86_64-allnoconfig x86_64-allmodconfigx86_64-allnoconfig x86_64-defconfig xtensa-allmodconfig xtensa-allnoconfigxtensa-audio_kc705 xtensa-cadence_csp xtensa-common xtensa-generic_kc705xtensa-iss xtensa-nommu_kc705 xtensa-smp_lx200 xtensa-virtxtensa-xip_kc705Tested-by: Nathan Chancellor &lt;nathan@kernel.org&gt; # build (hexagon)Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Mon, 02 Aug 2021 20:43:15 +0000</pubDate>
        <dc:creator>Alexey Dobriyan &lt;adobriyan@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>0c36d88c - lib/raid6: Let $(UNROLL) rules work with macOS userland</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#0c36d88c</link>
        <description>lib/raid6: Let $(UNROLL) rules work with macOS userlandOlder versions of BSD awk are fussy about the order of &apos;-v&apos; and &apos;-f&apos;flags, and require a space after the flag name. This causes buildfailures on platforms with an old awk, such as macOS and NetBSD.Since GNU awk and modern versions of BSD awk (distributed withFreeBSD/OpenBSD) are fine with either form, the definition of&apos;cmd_unroll&apos; can be trivially tweaked to let the lib/raid6 Makefilework with both old and new awk flag dialects.Signed-off-by: John Millikin &lt;john@john-millikin.com&gt;Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Wed, 23 Dec 2020 06:23:25 +0000</pubDate>
        <dc:creator>John Millikin &lt;john@john-millikin.com&gt;</dc:creator>
    </item>
<item>
        <title>b16838c6 - kbuild: trace functions in subdirectories of lib/</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#b16838c6</link>
        <description>kbuild: trace functions in subdirectories of lib/ccflags-remove-$(CONFIG_FUNCTION_TRACER) += $(CC_FLAGS_FTRACE)exists here in sub-directories of lib/ to keep the behavior ofcommit 2464a609ded0 (&quot;ftrace: do not trace library functions&quot;).Since that commit, not only the objects in lib/ but also the ones inthe sub-directories are excluded from ftrace (although the commitdescription did not explicitly mention this).However, most of library functions in sub-directories are not so hot.Re-add them to ftrace.Going forward, only the objects right under lib/ will be excluded.Cc: Ingo Molnar &lt;mingo@kernel.org&gt;Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;Acked-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Tue, 07 Jul 2020 09:21:17 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>15d5761a - kbuild: introduce ccflags-remove-y and asflags-remove-y</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#15d5761a</link>
        <description>kbuild: introduce ccflags-remove-y and asflags-remove-yCFLAGS_REMOVE_&lt;file&gt;.o filters out flags when compiling a particularobject, but there is no convenient way to do that for every object ina directory.Add ccflags-remove-y and asflags-remove-y to make it easily.Use ccflags-remove-y to clean up some Makefiles.The add/remove order works as follows: [1] KBUILD_CFLAGS specifies compiler flags used globally [2] ccflags-y adds compiler flags for all objects in the     current Makefile [3] ccflags-remove-y removes compiler flags for all objects in the     current Makefile (New feature) [4] CFLAGS_&lt;file&gt; adds compiler flags per file. [5] CFLAGS_REMOVE_&lt;file&gt; removes compiler flags per file.Having [3] before [4] allows us to remove flags from most (but not all)objects in the current Makefile.For example, kernel/trace/Makefile removes $(CC_FLAGS_FTRACE)from all objects in the directory, then adds it back totrace_selftest_dynamic.o and CFLAGS_trace_kprobe_selftest.oThe same applies to lib/livepatch/Makefile.Please note ccflags-remove-y has no effect to the sub-directories.In contrast, the previous notation got rid of compiler flags also fromall the sub-directories.The following are not affected because they have no sub-directories:  arch/arm/boot/compressed/  arch/powerpc/xmon/  arch/sh/  kernel/trace/However, lib/ has several sub-directories.To keep the behavior, I added ccflags-remove-y to all Makefilesin subdirectories of lib/, except the following:  lib/vdso/Makefile        - Kbuild does not descend into this Makefile  lib/raid/test/Makefile   - This is not used for the kernel buildI think commit 2464a609ded0 (&quot;ftrace: do not trace library functions&quot;)excluded too much. In the next commit, I will remove ccflags-remove-yfrom the sub-directories of lib/.Suggested-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;Acked-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt; (powerpc)Acked-by: Brendan Higgins &lt;brendanhiggins@google.com&gt; (KUnit)Tested-by: Anders Roxell &lt;anders.roxell@linaro.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Tue, 07 Jul 2020 09:21:16 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>5f2fb52f - kbuild: rename hostprogs-y/always to hostprogs/always-y</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#5f2fb52f</link>
        <description>kbuild: rename hostprogs-y/always to hostprogs/always-yIn old days, the &quot;host-progs&quot; syntax was used for specifying hostprograms. It was renamed to the current &quot;hostprogs-y&quot; in 2004.It is typically useful in scripts/Makefile because it allows Kbuild toselectively compile host programs based on the kernel configuration.This commit renames like follows:  always       -&gt;  always-y  hostprogs-y  -&gt;  hostprogsSo, scripts/Makefile will look like this:  always-$(CONFIG_BUILD_BIN2C) += ...  always-$(CONFIG_KALLSYMS)    += ...      ...  hostprogs := $(always-y) $(always-m)I think this makes more sense because a host program is always a hostprogram, irrespective of the kernel configuration. We want to specifywhich ones to compile by CONFIG options, so always-y will be handier.The &quot;always&quot;, &quot;hostprogs-y&quot;, &quot;hostprogs-m&quot; will be kept for backwardcompatibility for a while.Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Sat, 01 Feb 2020 16:49:24 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>e2a280d2 - lib/raid6: fix unnecessary rebuild of vpermxor*.c</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#e2a280d2</link>
        <description>lib/raid6: fix unnecessary rebuild of vpermxor*.cThe following four files are every time rebuilt:  UNROLL  lib/raid6/vpermxor1.c  UNROLL  lib/raid6/vpermxor2.c  UNROLL  lib/raid6/vpermxor4.c  UNROLL  lib/raid6/vpermxor8.cFix the suffixes in the targets.Fixes: 72ad21075df8 (&quot;lib/raid6: refactor unroll rules with pattern rules&quot;)Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Tue, 30 Jul 2019 16:40:42 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;</dc:creator>
    </item>
<item>
        <title>72ad2107 - lib/raid6: refactor unroll rules with pattern rules</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#72ad2107</link>
        <description>lib/raid6: refactor unroll rules with pattern rulesThis Makefile repeats very similar rules.Let&apos;s use pattern rules. $(UNROLL) can be replaced with $*.No intended change in behavior.Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Sun, 16 Jun 2019 17:48:05 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;</dc:creator>
    </item>
<item>
        <title>7747badc - lib/raid6: remove duplicated CFLAGS_REMOVE_altivec8.o</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#7747badc</link>
        <description>lib/raid6: remove duplicated CFLAGS_REMOVE_altivec8.oNo intended change in behavior.Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Sun, 16 Jun 2019 17:48:04 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;</dc:creator>
    </item>
<item>
        <title>de9c0d49 - ARM: 8833/1: Ensure that NEON code always compiles with Clang</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#de9c0d49</link>
        <description>ARM: 8833/1: Ensure that NEON code always compiles with ClangWhile building arm32 allyesconfig, I ran into the following errors:  arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with  &apos;-mfloat-abi=softfp -mfpu=neon&apos;  In file included from lib/raid6/neon1.c:27:  /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:  error: &quot;NEON support not enabled&quot;Building V=1 showed NEON_FLAGS getting passed along to Clang but__ARM_NEON__ was not getting defined. Ultimately, it boils down to Clangonly defining __ARM_NEON__ when targeting armv7, rather than armv6k,which is the &apos;-march&apos; value for allyesconfig.&gt;From lib/Basic/Targets/ARM.cpp in the Clang source:  // This only gets set when Neon instructions are actually available, unlike  // the VFP define, hence the soft float and arch check. This is subtly  // different from gcc, we follow the intent which was that it should be set  // when Neon instructions are actually available.  if ((FPU &amp; NeonFPU) &amp;&amp; !SoftFloat &amp;&amp; ArchVersion &gt;= 7) {    Builder.defineMacro(&quot;__ARM_NEON&quot;, &quot;1&quot;);    Builder.defineMacro(&quot;__ARM_NEON__&quot;);    // current AArch32 NEON implementations do not support double-precision    // floating-point even when it is present in VFP.    Builder.defineMacro(&quot;__ARM_NEON_FP&quot;,                        &quot;0x&quot; + Twine::utohexstr(HW_FP &amp; ~HW_FP_DP));  }Ard Biesheuvel recommended explicitly adding &apos;-march=armv7-a&apos; at thebeginning of the NEON_FLAGS definitions so that __ARM_NEON__ always getsdefinined by Clang. This doesn&apos;t functionally change anything becausethat code will only run where NEON is supported, which is implicitlyarmv7.Link: https://github.com/ClangBuiltLinux/linux/issues/287Suggested-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;Reviewed-by: Stefan Agner &lt;stefan@agner.ch&gt;Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Sat, 02 Feb 2019 02:34:36 +0000</pubDate>
        <dc:creator>Nathan Chancellor &lt;natechancellor@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>172caf19 - kbuild: remove redundant target cleaning on failure</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#172caf19</link>
        <description>kbuild: remove redundant target cleaning on failureSince commit 9c2af1c7377a (&quot;kbuild: add .DELETE_ON_ERROR specialtarget&quot;), the target file is automatically deleted on failure.The boilerplate code  ... || { rm -f $@; false; }is unneeded.Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Mon, 31 Dec 2018 08:24:08 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;</dc:creator>
    </item>
<item>
        <title>e213574a - raid6/ppc: Fix build for clang</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#e213574a</link>
        <description>raid6/ppc: Fix build for clangWe cannot build these files with clang as it does not allow altivecinstructions in assembly when -msoft-float is passed.Jinsong Ji &lt;jji@us.ibm.com&gt; wrote:&gt; We currently disable Altivec/VSX support when enabling soft-float.  So&gt; any usage of vector builtins will break.&gt;&gt; Enable Altivec/VSX with soft-float may need quite some clean up work, so&gt; I guess this is currently a limitation.&gt;&gt; Removing -msoft-float will make it work (and we are lucky that no&gt; floating point instructions will be generated as well).This is a workaround until the issue is resolved in clang.Link: https://bugs.llvm.org/show_bug.cgi?id=31177Link: https://github.com/ClangBuiltLinux/linux/issues/239Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Fri, 02 Nov 2018 00:44:55 +0000</pubDate>
        <dc:creator>Joel Stanley &lt;joel@jms.id.au&gt;</dc:creator>
    </item>
<item>
        <title>889ce12b - raid: remove tile specific raid6 implementation</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#889ce12b</link>
        <description>raid: remove tile specific raid6 implementationThe Tile architecture is getting removed, so we no longer need this either.Acked-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Fri, 09 Mar 2018 15:05:23 +0000</pubDate>
        <dc:creator>Arnd Bergmann &lt;arnd@arndb.de&gt;</dc:creator>
    </item>
<item>
        <title>751ba79c - lib/raid6/altivec: Add vpermxor implementation for raid6 Q syndrome</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#751ba79c</link>
        <description>lib/raid6/altivec: Add vpermxor implementation for raid6 Q syndromeThis patch uses the vpermxor instruction to optimise the raid6 Qsyndrome. This instruction was made available with POWER8, ISA version2.07. It allows for both vperm and vxor instructions to be done in asingle instruction. This has been tested for correctness on a ppc64levm with a basic RAID6 setup containing 5 drives.The performance benchmarks are from the raid6test in the/lib/raid6/test directory. These results are from an IBM Firestonemachine with ppc64le architecture. The benchmark results show a 35%speed increase over the best existing algorithm for powerpc (altivec).The raid6test has also been run on a big-endian ppc64 vm to ensure italso works for big-endian architectures.Performance benchmarks:  raid6: altivecx4 gen() 18773 MB/s  raid6: altivecx8 gen() 19438 MB/s  raid6: vpermxor4 gen() 25112 MB/s  raid6: vpermxor8 gen() 26279 MB/sSigned-off-by: Matt Brown &lt;matthew.brown.dev@gmail.com&gt;Reviewed-by: Daniel Axtens &lt;dja@axtens.net&gt;[mpe: Add VPERMXOR macro so we can build with old binutils]Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Fri, 04 Aug 2017 03:42:32 +0000</pubDate>
        <dc:creator>Matt Brown &lt;matthew.brown.dev@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/lib/raid6/Makefile#b2441318</link>
        <description>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 &apos;GPL-2.0&apos;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 &amp; 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 &gt;5   lines of source - File already had some variant of a license header in it (even if &lt;5   lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn&apos;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 &quot;GPL-2.0 WITH   Linux-syscall-note&quot; otherwise it was &quot;GPL-2.0&quot;.  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&apos;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 &lt;kstewart@linuxfoundation.org&gt;Reviewed-by: Philippe Ombredanne &lt;pombredanne@nexb.com&gt;Reviewed-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

            List of files:
            /linux-6.15/lib/raid6/Makefile</description>
        <pubDate>Wed, 01 Nov 2017 14:07:57 +0000</pubDate>
        <dc:creator>Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;</dc:creator>
    </item>
</channel>
</rss>
