Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
adacfc6d |
| 14-Oct-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code d
kbuild: unify vdso_install rules
[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
Currently, there is no standard implementation for vdso_install, leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install rule.
Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away.
vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23 |
|
#
5ca26530 |
| 03-Apr-2023 |
Neil Armstrong <neil.armstrong@linaro.org> |
ARM: oxnas: remove OXNAS support
Due to lack of maintainance and stall of development for a few years now, and since no new features will ever be added upstream, remove support for OX810 and OX820 A
ARM: oxnas: remove OXNAS support
Due to lack of maintainance and stall of development for a few years now, and since no new features will ever be added upstream, remove support for OX810 and OX820 ARM support.
Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
e9faf9b0 |
| 24-Jan-2023 |
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> |
ARM: add multi_v7_lpae_defconfig
The only missing configuration option preventing us from using multi_v7_defconfig with the Raspberry Pi 4 is ARM_LPAE. It's needed as the PCIe controller found on th
ARM: add multi_v7_lpae_defconfig
The only missing configuration option preventing us from using multi_v7_defconfig with the Raspberry Pi 4 is ARM_LPAE. It's needed as the PCIe controller found on the SoC depends on 64bit addressing, yet can't be included as not all v7 boards support LPAE.
Introduce multi_v7_lpae_defconfig, built off multi_v7_defconfig, which will avoid us having to duplicate and maintain multiple similar configurations.
Needless to say the Raspberry Pi 4 is not the only platform that can benefit from this new configuration.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20230124110213.3221264-11-alexander.stein@ew.tq-group.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v6.1.8 |
|
#
2f62847c |
| 18-Jan-2023 |
Nathan Chancellor <nathan@kernel.org> |
ARM: 9287/1: Reduce __thumb2__ definition to crypto files that require it
Commit 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") added a __thumb2__ define to ASFLAGS to avoid build error
ARM: 9287/1: Reduce __thumb2__ definition to crypto files that require it
Commit 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") added a __thumb2__ define to ASFLAGS to avoid build errors in the crypto code, which relies on __thumb2__ for preprocessing. Commit 59e2cf8d21e0 ("ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA") followed up on this by removing -mthumb from AFLAGS so that __thumb2__ would not be defined when the default target was ARMv7 or newer.
Unfortunately, the second commit's fix assumes that the toolchain defaults to -mno-thumb / -marm, which is not the case for Debian's arm-linux-gnueabihf target, which defaults to -mthumb:
$ echo | arm-linux-gnueabihf-gcc -dM -E - | grep __thumb #define __thumb2__ 1 #define __thumb__ 1
This target is used by several CI systems, which will still see redefined macro warnings, despite '-mthumb' not being present in the flags:
<command-line>: warning: "__thumb2__" redefined <built-in>: note: this is the location of the previous definition
Remove the global AFLAGS __thumb2__ define and move it to the crypto folder where it is required by the imported OpenSSL algorithms; the rest of the kernel should use the internal CONFIG_THUMB2_KERNEL symbol to know whether or not Thumb2 is being used or not. Be sure that __thumb2__ is undefined first so that there are no macro redefinition warnings.
Link: https://github.com/ClangBuiltLinux/linux/issues/1772
Reported-by: "kernelci.org bot" <bot@kernelci.org> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Fixes: 59e2cf8d21e0 ("ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA") Fixes: 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
Revision tags: v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0 |
|
#
61b7f892 |
| 29-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: s3c: remove all s3c24xx support
The platform was deprecated in commit 6a5e69c7ddea ("ARM: s3c: mark as deprecated and schedule removal") and can be removed. This includes all files that are exc
ARM: s3c: remove all s3c24xx support
The platform was deprecated in commit 6a5e69c7ddea ("ARM: s3c: mark as deprecated and schedule removal") and can be removed. This includes all files that are exclusively for s3c24xx and not shared with s3c64xx, as well as the glue logic in Kconfig and the maintainer file entries.
Cc: Arnaud Patard <arnaud.patard@rtp-net.org> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Christer Weinigel <christer@weinigel.se> Cc: Guillaume GOURAT <guillaume.gourat@nexvision.tv> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Simtec Linux Team <linux@simtec.co.uk> Cc: openmoko-kernel@lists.openmoko.org Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
cdc3116f |
| 10-Jan-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
ARM: 9285/1: remove meaningless arch/arm/mach-rda/Makefile
You do not need to put Makefile if there is nothing to compile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Russe
ARM: 9285/1: remove meaningless arch/arm/mach-rda/Makefile
You do not need to put Makefile if there is nothing to compile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
b91a69d1 |
| 29-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: iop32x: remove the platform
This was marked as unused in 5.19 and can now be removed
Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Martin Michlmayr <tbm@cyrius.com> Acked-by: Dan Williams
ARM: iop32x: remove the platform
This was marked as unused in 5.19 and can now be removed
Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Martin Michlmayr <tbm@cyrius.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
e73307b9 |
| 29-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: cns3xxx: remove entire platform
cns3xxx was marked as unused a while ago, and gets removed entirely now.
Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.d
ARM: cns3xxx: remove entire platform
cns3xxx was marked as unused a while ago, and gets removed entirely now.
Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
59e2cf8d |
| 21-Nov-2022 |
Nathan Chancellor <nathan@kernel.org> |
ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA
When building with CONFIG_THUMB2_KERNEL=y + a version of clang from Debian using CROSS_COMPILE=arm-linux-gnueabihf-, the following warning occurs frequent
ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA
When building with CONFIG_THUMB2_KERNEL=y + a version of clang from Debian using CROSS_COMPILE=arm-linux-gnueabihf-, the following warning occurs frequently:
<built-in>:383:9: warning: '__thumb2__' macro redefined [-Wmacro-redefined] #define __thumb2__ 2 ^ <built-in>:353:9: note: previous definition is here #define __thumb2__ 1 ^ 1 warning generated.
Debian carries a downstream patch that changes the default CPU of the arm-linux-gnueabihf target from 'arm1176jzf-s' (v6) to 'cortex-a7' (v7). As a result, '-mthumb' defines both '__thumb__' and '__thumb2__'. The define of '__thumb2__' via the command line was purposefully added to catch a situation like this.
In a similar vein as commit 26b12e084bce ("ARM: 9264/1: only use -mtp=cp15 for the compiler"), do not add '-mthumb' to AFLAGS_ISA, as it is already passed to the assembler via '-Wa,-mthumb' and '__thumb2__' is already defined for preprocessing.
Link: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/622dbcbd40b316ed3905a2d25d9623544a06e6b1/debian/patches/930008-arm.diff
Fixes: 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") Reported-by: "kernelci.org bot" <bot@kernelci.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
1d2e9b67 |
| 24-Oct-2022 |
Nick Desaulniers <ndesaulniers@google.com> |
ARM: 9265/1: pass -march= only to compiler
When both -march= and -Wa,-march= are specified for assembler or assembler-with-cpp sources, GCC and Clang will prefer the -Wa,-march= value but Clang will
ARM: 9265/1: pass -march= only to compiler
When both -march= and -Wa,-march= are specified for assembler or assembler-with-cpp sources, GCC and Clang will prefer the -Wa,-march= value but Clang will warn that -march= is unused.
warning: argument unused during compilation: '-march=armv6k' [-Wunused-command-line-argument]
This is the top group of warnings we observe when using clang to assemble the kernel via `ARCH=arm make LLVM=1`.
Split the arch-y make variable into two, so that -march= flags only get passed to the compiler, not the assembler. -D flags are added to KBUILD_CPPFLAGS which is used for both C and assembler-with-cpp sources.
Clang is trying to warn that it doesn't support different values for -march= and -Wa,-march= (like GCC does, but the kernel doesn't need this) though the value of the preprocessor define __thumb2__ is based on -march=. Make sure to re-set __thumb2__ via -D flag for assembler sources now that we're no longer passing -march= to the assembler. Set it to a different value than the preprocessor would for -march= in case -march= gets accidentally re-added to KBUILD_AFLAGS in the future. Thanks to Ard and Nathan for this suggestion.
Link: https://github.com/ClangBuiltLinux/linux/issues/1315 Link: https://github.com/ClangBuiltLinux/linux/issues/1587 Link: https://github.com/llvm/llvm-project/issues/55656
Suggested-by: Ard Biesheuvel <ardb@kernel.org> Suggested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
26b12e08 |
| 24-Oct-2022 |
Nick Desaulniers <ndesaulniers@google.com> |
ARM: 9264/1: only use -mtp=cp15 for the compiler
Avoids an error from the assembler for CONFIG_THUMB2 kernels:
clang-15: error: hardware TLS register is not supported for the thumbv4t sub-architect
ARM: 9264/1: only use -mtp=cp15 for the compiler
Avoids an error from the assembler for CONFIG_THUMB2 kernels:
clang-15: error: hardware TLS register is not supported for the thumbv4t sub-architecture
This flag only makes sense to pass to the compiler, not the assembler.
Perhaps CFLAGS_ABI can be renamed to CPPFLAGS_ABI to reflect that they will be passed to both the compiler and assembler for sources that require pre-processing.
Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
5aa4860e |
| 24-Oct-2022 |
Nick Desaulniers <ndesaulniers@google.com> |
ARM: 9262/1: remove lazy evaluation in Makefile
arch-y and tune-y used lazy evaluation since they used to contain
cc-option checks. They don't any longer, so just eagerly evaluate these command lin
ARM: 9262/1: remove lazy evaluation in Makefile
arch-y and tune-y used lazy evaluation since they used to contain
cc-option checks. They don't any longer, so just eagerly evaluate these command line flags.
Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
Revision tags: v5.15.71 |
|
#
ce697cce |
| 24-Sep-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: remove head-y syntax
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point.
A counter approach is to
kbuild: remove head-y syntax
Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point.
A counter approach is to control the section order by the linker script. Actually, the code marked as __HEAD goes into the ".head.text" section, which is placed before the normal ".text" section.
I do not know if both of them are needed. From the build system perspective, head-y is not mandatory. If you can achieve the proper code placement by the linker script only, it would be cleaner.
I collected the current head-y objects into head-object-list.txt. It is a whitelist. My hope is it will be reduced in the long run.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61 |
|
#
3d47ff25 |
| 12-Aug-2022 |
Ben Wolsieffer <ben.wolsieffer@hefring.com> |
ARM: 9226/1: disable FDPIC ABI
When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is enabled by default but should not be used to build the kernel. Therefore, pass -mno-fdpic if s
ARM: 9226/1: disable FDPIC ABI
When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is enabled by default but should not be used to build the kernel. Therefore, pass -mno-fdpic if supported by the compiler.
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
Revision tags: v5.15.60, v5.15.59, v5.19, v5.15.58 |
|
#
8c7d29a7 |
| 27-Jul-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: simplify machdirs/platdirs handling
There is only one plat-* directory left, and the MACHINE variable is only used for the mach/*.h header path.
Simplify this by removing the checks for ARCH_M
ARM: simplify machdirs/platdirs handling
There is only one plat-* directory left, and the MACHINE variable is only used for the mach/*.h header path.
Simplify this by removing the checks for ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, and just adding the include directories for the remaining three platforms manually.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
92481c7d |
| 27-Jul-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: remove obsolete Makefile.boot infrastructure
There are a number of old Makefile.boot files that remain from the multiplatform conversion, and three that are still in use.
These provide the "ZR
ARM: remove obsolete Makefile.boot infrastructure
There are a number of old Makefile.boot files that remain from the multiplatform conversion, and three that are still in use.
These provide the "ZRELADDR", "PARAMS_PHYS" and "INITRD_PHYS" values that are platform specific. It turns out that we can generally just derive this from information that is available elsewhere:
- ZRELADDR is normally detected at runtime with the CONFIG_AUTO_ZRELADDR flag, but also needed to be passed to for 'make uImage'. In a multiplatform kernel, one always has to pass this as the $(LOADADDR) variable, but in the StrongARM kernels we can derive it from the sum of $(CONFIG_PHYS_OFFSET) and $(TEXT_OFFSET) that are already known.
- PARAMS_PHYS and INITRD_PHYS are only used for bootpImage, which in turn is only used for the pre-ATAGS 'param_struct' based boot interface on StrongARM based machines with old boot loaders. They can both be derived from CONFIG_PHYS_OFFSET and a machine specific offset for the initrd, so all of the logic for these can be part of arch/arm/boot/bootp/Makefile.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51 |
|
#
0aa94eea |
| 28-Jun-2022 |
Qin Jian <qinjian@cqplus1.com> |
ARM: sunplus: Add initial support for Sunplus SP7021 SoC
This patch aims to add an initial support for Sunplus SP7021 SoC.
Signed-off-by: Qin Jian <qinjian@cqplus1.com> Reviewed-by: Arnd Bergmann <
ARM: sunplus: Add initial support for Sunplus SP7021 SoC
This patch aims to add an initial support for Sunplus SP7021 SoC.
Signed-off-by: Qin Jian <qinjian@cqplus1.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41 |
|
#
11d89440 |
| 16-May-2022 |
Nick Hawkins <nick.hawkins@hpe.com> |
ARM: hpe: Introduce the HPE GXP architecture
The GXP is the HPE BMC SoC that is used in the majority of current generation HPE servers. Traditionally the asic will last multiple generations of serve
ARM: hpe: Introduce the HPE GXP architecture
The GXP is the HPE BMC SoC that is used in the majority of current generation HPE servers. Traditionally the asic will last multiple generations of server before being replaced.
Info about SoC:
HPE GXP is the name of the HPE Soc. This SoC is used to implement many BMC features at HPE. It supports ARMv7 architecture based on the Cortex A9 core. It is capable of using an AXI bus to whicha memory controller is attached. It has multiple SPI interfaces to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC for network connectivity. It has multiple i2c engines to drive connectivity with a host infrastructure. There currently are no public specifications but this process is being worked.
Previously there was a requirement to reset the EHCI controller for the asic to boot. This functionality has been moved to the u-boot bootloader.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v5.15.40, v5.15.39, v5.15.38 |
|
#
f774f5bb |
| 02-May-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: factor out the common installation code into scripts/install.sh
Many architectures have similar install.sh scripts.
The first half is really generic; it verifies that the kernel image and S
kbuild: factor out the common installation code into scripts/install.sh
Many architectures have similar install.sh scripts.
The first half is really generic; it verifies that the kernel image and System.map exist, then executes ~/bin/${INSTALLKERNEL} or /sbin/${INSTALLKERNEL} if available.
The second half is kind of arch-specific; it copies the kernel image and System.map to the destination, but the code is slightly different.
Factor out the generic part into scripts/install.sh.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
show more ...
|