From: Thomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembler code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This is bad since macros starting with two underscores are names
that are reserved by the C
From: Thomas Huth
__ASSEMBLY__ is only defined by the Makefile of the kernel, so
this is not really useful for uapi headers (unless the userspace
Makefile defines it, too). Let's switch to __ASSEMBLER__ which
gets set automatically by the compiler when compiling assembler
code.
This is a complet
The kernel Makefiles define the __ASSEMBLY__ macro to provide
a way to use headers in both, assembler and C source code.
However, all the supported versions of the GCC and Clang compilers
also define the macro __ASSEMBLER__ automatically already when compiling
assembler code, so some kernel headers
On 10/06/2025 22.26, Segher Boessenkool wrote:
On Tue, Jun 10, 2025 at 06:01:28PM +0200, Thomas Huth wrote:
From: Thomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefil
On 10/06/2025 22.12, Segher Boessenkool wrote:
On Tue, Jun 10, 2025 at 06:01:27PM +0200, Thomas Huth wrote:
From: Thomas Huth
__ASSEMBLY__ is only defined by the Makefile of the kernel, so
this is not really useful for uapi headers (unless the userspace
Makefile defines it, too). Let's switch
On Tue, 2025-06-10 at 09:33 +0200, Christophe Leroy wrote:
> This series requires a rebase after commit 91e40668e70a
> ("mm/page_table_check: Batch-check pmds/puds just like ptes")
Will respin!
>
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
allnoconfiggcc-15.1.0
arc defconfiggcc-15.1.0
arc randconfig-001-20250610gcc-12.4.0
arc randconfig-002-20250610gcc-12.4.0
arm allnoconfiggcc-15.1.0
arm
Standardize KVM's include paths across all architectures by declaring
the KVM-specific includes in the common Makefile.kvm. Having common KVM
"own" the included paths reduces the temptation to unnecessarily add
virt/kvm to arch include paths, and conversely if allowing arch code to
grab headers fr
Don't add virt/kvm to KVM s390's include path, the headers in virt/kvm are
intended to be used only by other code in virt/kvm, i.e. are "private" to
the core KVM code. It's not clear that s390 *ever* included a header from
virt/kvm, i.e. odds are good the "-Ivirt/kvm" was copied from a x86's
Makef
Move iodev.h, the last remaining holdout in include/kvm, to the standard
include/linux directory as kvm_iodev.h and delete include/kvm.
Acked-by: Anup Patel
Signed-off-by: Sean Christopherson
---
MAINTAINERS| 1 -
arch/arm64/include/asm/kvm_vgic.h | 2 +-
Don't add virt/kvm to KVM MIPS' include path, the headers in virt/kvm are
intended to be used only by other code in virt/kvm, i.e. are "private" to
the core KVM code. It's not clear that MIPS *ever* included a header from
virt/kvm, i.e. odds are good the "-Ivirt/kvm" was copied from a different
ar
Move kvm/arm_{arch_timer,pmu,vgic}.h to arch/arm64/include/asm and drop
the "arm" prefix from all file names. Now that KVM no longer supports
32-bit ARM, there is no reason to expose ARM specific headers to other
architectures beyond arm64.
Cc: Colton Lewis
Signed-off-by: Sean Christopherson
--
Don't add virt/kvm to KVM PPC's include path, the headers in virt/kvm are
intended to be used only by other code in virt/kvm, i.e. are "private" to
the core KVM code. It's not clear that PPC *ever* included a header from
virt/kvm, i.e. odds are good the "-Ivirt/kvm" was copied from a different
arc
From: Anish Ghulati
Move arm_hypercalls.h and arm_psci.h into arch/arm64/kvm now that KVM
no longer supports 32-bit ARM, i.e. now that there's no reason to make
the hypercall and PSCI APIs "public".
Signed-off-by: Anish Ghulati
[sean: squash into one patch, write changelog]
Signed-off-by: Sean
Include include/uapi/linux/kvm.h and include/linux/kvm_types.h in ARM's
public arm_arch_timer.h and arm_pmu.h headers to get forward declarations
of things like "struct kvm_vcpu" and "struct kvm_device_attr", which are
referenced but never declared (neither file includes *any* KVM headers).
The mi
Kill off include/kvm (through file moves/renames), and standardize the set of
KVM includes across all architectures.
This conflicts with Colton's partioned PMU series[1], but this should work as
a nice prepatory cleanup for the partitioned PMU work (and hopefully can land
sooner).
Note, these pat
On Sat, 7 Jun 2025 13:37:42 +0200
Christophe Leroy wrote:
> With user access protection (Called SMAP on x86 or KUAP on powerpc)
> each and every call to get_user() or put_user() performs heavy
> operations to unlock and lock kernel access to userspace.
>
> To avoid that, perform user accesses b
On PLPKS enabled PowerVM LPAR, there is no provision to load signed
third-party kernel modules when the key management mode is static. This
is because keys from secure boot secvars are only loaded when the key
management mode is dynamic.
Allow loading of the trustedcadb and moduledb keys even in t
On a PLPKS enabled PowerVM LPAR, the secvar format property for static
key management is misrepresented as "ibm,plpks-sb-unknown", creating
reason for confusion.
Static key management mode uses fixed, built-in keys. Dynamic key
management mode allows keys to be updated in production to handle
secu
The PLPKS enabled PowerVM LPAR sysfs exposes all of the secure boot
secvars irrespective of the key management mode.
The PowerVM LPAR supports static and dynamic key management for secure
boot. The key management option can be updated in the management
console. The secvars PK, trustedcadb, and mod
The PLPKS enabled Power LPAR sysfs exposes all of the secure boot secure
variables irrespective of the key management mode. There is support for
both static and dynamic key management and the key management mode can
be updated using the management console. The user should be able to read
from and w
On Tue, Jun 10, 2025 at 06:01:28PM +0200, Thomas Huth wrote:
> From: Thomas Huth
>
> While the GCC and Clang compilers already define __ASSEMBLER__
> automatically when compiling assembly code, __ASSEMBLY__ is a
> macro that only gets defined by the Makefiles in the kernel.
And it should not, th
On Tue, Jun 10, 2025 at 06:01:27PM +0200, Thomas Huth wrote:
> From: Thomas Huth
>
> __ASSEMBLY__ is only defined by the Makefile of the kernel, so
> this is not really useful for uapi headers (unless the userspace
> Makefile defines it, too). Let's switch to __ASSEMBLER__ which
> gets set automa
On Tue, Jun 10, 2025 at 11:03:39PM +0300, Laurent Pinchart wrote:
> On Tue, Jun 10, 2025 at 10:39:31PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 25, 2025 at 08:07:32PM +0300, Laurent Pinchart wrote:
> > > On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote:
> > > > Whatever happened w
On Tue, Jun 10, 2025 at 10:39:31PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 25, 2025 at 08:07:32PM +0300, Laurent Pinchart wrote:
> > On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote:
> > > Whatever happened with this thread from Feb.
> > > https://lore.kernel.org/all/20250207013117
On Tue, Jun 10, 2025 at 06:01:26PM +0200, Thomas Huth wrote:
> The kernel Makefiles define the __ASSEMBLY__ macro to provide
> a way to use headers in both, assembly and C source code.
> However, all the supported versions of the GCC and Clang compilers
> also define the macro __ASSEMBLER__ automat
On Fri, Apr 25, 2025 at 08:07:32PM +0300, Laurent Pinchart wrote:
> On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote:
> > Whatever happened with this thread from Feb.
> > https://lore.kernel.org/all/20250207013117.104205-1-zhangzeku...@huawei.com/
> >
> > The issue was that people wer
On Tue, Jun 10, 2025 at 11:39:22AM -0600, Jason A. Donenfeld wrote:
> On Sun, Jun 08, 2025 at 04:48:17PM -0700, Eric Biggers wrote:
> > On Sat, Jun 07, 2025 at 05:47:02PM -0600, Jason A. Donenfeld wrote:
> > > On Sat, Jun 07, 2025 at 01:04:42PM -0700, Eric Biggers wrote:
> > > > Having arch-specifi
On Sat, Jun 07, 2025 at 01:04:42PM -0700, Eric Biggers wrote:
> This series is also available at:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
> lib-crc-arch-v2
>
> This series improves how lib/crc supports arch-optimized code. First,
> instead of the
On Sun, Jun 08, 2025 at 04:48:17PM -0700, Eric Biggers wrote:
> On Sat, Jun 07, 2025 at 05:47:02PM -0600, Jason A. Donenfeld wrote:
> > On Sat, Jun 07, 2025 at 01:04:42PM -0700, Eric Biggers wrote:
> > > Having arch-specific code outside arch/ was somewhat controversial when
> > > Zinc proposed it
Le 10/06/2025 à 16:29, Thomas Fourier a écrit :
[Vous ne recevez pas souvent de courriers de fourier.tho...@gmail.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
If the device configuration fails (if `dma_dev->device_config()`),
`sg_dma_address(&
Hello:
This patch was applied to riscv/linux.git (fixes)
by Masahiro Yamada :
On Tue, 3 Jun 2025 03:12:54 +0900 you wrote:
> The extra-y syntax is deprecated. Instead, use always-$(KBUILD_BUILTIN),
> which behaves equivalently.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/alpha/kernel/M
From: Thomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when d
From: Thomas Huth
__ASSEMBLY__ is only defined by the Makefile of the kernel, so
this is not really useful for uapi headers (unless the userspace
Makefile defines it, too). Let's switch to __ASSEMBLER__ which
gets set automatically by the compiler when compiling assembly
code.
This is a complete
The kernel Makefiles define the __ASSEMBLY__ macro to provide
a way to use headers in both, assembly and C source code.
However, all the supported versions of the GCC and Clang compilers
also define the macro __ASSEMBLER__ automatically already when compiling
assembly code, so some kernel headers a
If the device configuration fails (if `dma_dev->device_config()`),
`sg_dma_address(&sg)` is not initialized and the jump to `err_dma_prep`
leads to calling `dma_unmap_single()` on `sg_dma_address(&sg)`.
Signed-off-by: Thomas Fourier
---
arch/powerpc/platforms/512x/mpc512x_lpbfifo.c | 6 ++
1
From: Bartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski
---
drivers/soc/fsl/qe/gpio.c | 6 --
1 file changed, 4 insertions(+), 2 deletion
From: Bartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski
---
drivers/soc/renesas/pwc-rzv2m.c | 8 +---
1 file changed, 5 insertions(+), 3
Commit 98ce1eb1fd87e ("gpiolib: introduce gpio_chip setters that return
values") added new line setter callbacks to struct gpio_chip. They allow
to indicate failures to callers. We're in the process of converting all
GPIO controllers to using them before removing the old ones. This series
converts
Le 11/04/2025 à 07:43, Andrew Donnellan a écrit :
Support page table check on all PowerPC platforms. This works by
serialising assignments, reassignments and clears of page table
entries at each level in order to ensure that anonymous mappings
have at most one writable consumer, and likewise t
Hello again.. It looks like there are specific system configurations that are
extremely likely to have issues with this patch & result in undesirable
system behavior..
Specifically hot-plug systems with side-band presence detection & without
Power Controls (i.e PwrCtrl-) given to config space. I
41 matches
Mail list logo
