Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131 2024-10-04T14:29:44+00:00 2024-10-04T14:29:44+00:00 Laurent Pinchart laurent.pinchart@ideasonboard.com 2024-07-29T15:57:38+00:00 urn:sha1:38dee6edb700d381d5ade626c67a7d63aca97a5e commit 76be4f5a784533c71afbbb1b8f2963ef9e2ee258 upstream. Commit 3f1b0e1f2875 (".gitignore update") added *.orig and *.rej patterns to .gitignore in v2.6.23. The commit message didn't give a rationale. Later on, commit 1f5d3a6b6532 ("Remove *.rej pattern from .gitignore") removed the *.rej pattern in v2.6.26, on the rationale that *.rej files indicated something went really wrong and should not be ignored. The *.rej files are now shown by `git status`, which helps located conflicts when applying patches and lowers the probability that they will go unnoticed. It is however still easy to overlook the *.orig files which slowly polute the source tree. That's not as big of a deal as not noticing a conflict, but it's still not nice. Drop the *.orig pattern from .gitignore to avoid this and help keep the source tree clean. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [masahiroy@kernel.org: I do not have a strong opinion about this. Perhaps some people may have a different opinion. If you are someone who wants to ignore *.orig, it is likely you would want to do so across all projects. Then, $XDG_CONFIG_HOME/git/ignore would be more suitable for your needs. gitignore(5) suggests, "Patterns which a user wants Git to ignore in all situations generally go into a file specified by core.excludesFile in the user's ~/.gitconfig". Please note that you cannot do the opposite; if *.orig is ignored by the project's .gitignore, you cannot override the decision because $XDG_CONFIG_HOME/git/ignore has a lower priority. If *.orig is sitting on the fence, I'd leave it to the users. ] Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-07-24T15:59:33+00:00 Masahiro Yamada masahiroy@kernel.org 2023-07-22T04:48:03+00:00 urn:sha1:975667d02d134f7b48d15ee7ff0d49e69a6774cf Now kernel.spec and binkernel.spec have the exactly same contents. Use kernel.spec for binrpm-pkg as well. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> 2023-07-04T22:05:12+00:00 Linus Torvalds torvalds@linux-foundation.org 2023-07-04T22:05:12+00:00 urn:sha1:d528014517f2b0531862c02865b9d4c908019dc4 This reverts commit 534066a983df0935847061c844eb178f8a53a9e7. It's actively detrimental in that it hides files that shouldn't be hidden. If I have some b4 mbx file in my git directory, it either was already applied with "git am" and is now stale, or maybe it's waiting for that to happen. In neither case is "ignore it" the right option. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2023-06-22T12:21:06+00:00 Masahiro Yamada masahiroy@kernel.org 2023-06-11T15:50:57+00:00 urn:sha1:5e9e95cc9148b82074a5eae283e63bce3f1aacfe When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses the directory tree to determine which EXPORT_SYMBOL to trim. If an EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the second traverse, where some source files are recompiled with their EXPORT_SYMBOL() tuned into a no-op. Linus stated negative opinions about this slowness in commits: - 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option") - a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding") We can do this better now. The final data structures of EXPORT_SYMBOL are generated by the modpost stage, so modpost can selectively emit KSYMTAB entries that are really used by modules. Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another ground-work to do this in a one-pass algorithm. With the list of modules, modpost sets sym->used if it is used by a module. modpost emits KSYMTAB only for symbols with sym->used==true. BTW, Nicolas explained why the trimming was implemented with recursion: https://lore.kernel.org/all/2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg/ Actually, we never achieved that level of optimization where the chain reaction of trimming comes into play because: - CONFIG_LTO_CLANG cannot remove any unused symbols - CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux, but not modules If deeper trimming is required, we need to revisit this, but I guess that is unlikely to happen. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> 2023-04-24T19:31:32+00:00 Linus Torvalds torvalds@linux-foundation.org 2023-04-24T19:31:32+00:00 urn:sha1:1be89faab3cf1f3dd6eb4924b60d2b9094e7206b Pull KUnit updates from Shuah Khan: - several fixes to kunit tool - new klist structure test - support for m68k under QEMU - support for overriding the QEMU serial port - support for SH under QEMU * tag 'linux-kselftest-kunit-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: add tests for using current KUnit test field kunit: tool: Add support for SH under QEMU kunit: tool: Add support for overriding the QEMU serial port .gitignore: Unignore .kunitconfig list: test: Test the klist structure kunit: increase KUNIT_LOG_SIZE to 2048 bytes kunit: Use gfp in kunit_alloc_resource() kernel-doc kunit: tool: fix pre-existing `mypy --strict` errors and update run_checks.py kunit: tool: remove unused imports and variables kunit: tool: add subscripts for type annotations where appropriate kunit: fix bug of extra newline characters in debugfs logs kunit: fix bug in the order of lines in debugfs logs kunit: fix bug in debugfs logs of parameterized tests kunit: tool: Add support for m68k under QEMU 2023-04-05T18:48:42+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2023-01-27T14:57:08+00:00 urn:sha1:cb8865fd865f5b2f656d0d91f3b0146ef1acb10d There are almost dozen of .kunitconfig files that are ignored but tracked. Unignore them. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 2023-03-16T13:45:56+00:00 Masahiro Yamada masahiroy@kernel.org 2023-03-15T15:50:17+00:00 urn:sha1:81f59a26f3d59c6aeb137b7b5546848779222c65 Prepare to add more files to the source RPM. Also, fix the build error when KCONFIG_CONFIG is set: error: Bad file: ./.config: No such file or directory Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> 2023-02-05T09:51:22+00:00 Masahiro Yamada masahiroy@kernel.org 2023-01-30T08:28:49+00:00 urn:sha1:534066a983df0935847061c844eb178f8a53a9e7 The 'b4' command creates a *.mbx file, and also a *.cover file if the patch set has a cover-letter. Ignore them. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> 2023-01-22T14:43:32+00:00 Masahiro Yamada masahiroy@kernel.org 2022-12-29T07:43:09+00:00 urn:sha1:b8a9ddcafc1a7ed071a44c1e9937d68e7efc8f70 Recent git versions do not accept the noted command. $ git ls-files -i --exclude-standard fatal: ls-files -i must be used with either -o or -c The -c was implied before, but we need to make it explicit since git commit b338e9f66873 ("ls-files: error out on -i unless -o or -c are specified"). Also, replace --exclude-standard with --exclude-per-directory=.gitignore so that everyone will get consistent results. git-ls-files(1) says: --exclude-standard Add the standard Git exclusions: .git/info/exclude, .gitignore in each directory, and the user's global exclusion file. We cannot predict what is locally added to .git/info/exclude or the user's global exclusion file. We can only manage .gitignore files committed to the repository. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> 2022-12-30T08:22:14+00:00 Masahiro Yamada masahiroy@kernel.org 2022-12-26T18:54:44+00:00 urn:sha1:924d28b39e3b62ad5e97751585aed7c89f8c43ee Previously, *.rpm files were created under $HOME/rpmbuild/, but since commit 8818039f959b ("kbuild: add ability to make source rpm buildable using koji"), srcrpm-pkg creates the source rpm in the kernel tree because it sets '_srcrpmdir'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>