[PATCH 1/6] powerpc/pseries: Define common functions for RTAS sequence HCALLs

The RTAS call can be normal where retrieves the data form the hypervisor with one HCALL or sequence based HCALL which has to issue multiple times until the complete data is obtained. For some of these sequence HCALLs, the OS should not interleave calls with different input until the sequence is com

[PATCH 6/6] powerpc/pseries: Add papr-platform-dump character driver for dump retrieval

ibm,platform-dump RTAS call in combination with writable mapping /dev/mem is issued to collect platform dump from the hypervisor and may need multiple calls to get the complete dump. The current implementation uses rtas_platform_dump() API provided by librtas library to issue these HCALLs. But /dev

[PATCH 3/6] powerpc/pseries: Add papr-indices char driver for ibm,get-indices HCALL

The RTAS call ibm,get-indices is used to obtain indices and location codes for a specified indicator or sensor token. The current implementation uses rtas_get_indices() API provided by librtas library which allocates RMO buffer and issue this RTAS call in the user space. But writable mapping /dev/m

[PATCH 4/6] powerpc/pseries: Add ibm,set-dynamic-indicator RTAS call support

The RTAS call ibm,set-dynamic-indicator is used to set the new indicator state identified by a location code. The current implementation uses rtas_set_dynamic_indicator() API provided by librtas library which allocates RMO buffer and issue this RTAS call in the user space. But /dev/mem access by th

[PATCH 0/6] Add character devices for indices and platform-dump RTAS

Several APIs such as rtas_get_indices(), rtas_get_dynamic_sensor(), rtas_set_dynamic_indicator() and rtas_platform_dump() provided by librtas library are implemented in user space using rtas syscall in combination with writable mappings of /dev/mem. But this implementation is not compatible with sy

[PATCH 2/6] powerpc/pseries: Define papr_indices_io_block for papr-indices ioctls

To issue ibm,get-indices, ibm,set-dynamic-indicator and ibm,get-dynamic-sensor-state in the user space, the RMO buffer is allocated for the work area which is restricted under system lockdown. So instead of user space execution, the kernel will provide /dev/papr-indices interface to execute these R

[PATCH 5/6] powerpc/pseries: Add ibm,get-dynamic-sensor-state RTAS call support

The RTAS call ibm,get-dynamic-sensor-state is used to get the sensor state identified by the location code and the sensor token. The librtas library provides an API rtas_get_dynamic_sensor() which uses /dev/mem access for work area allocation but is restricted under system lockdown. This patch pro

Re: [PATCH 1/6] powerpc/pseries: Define common functions for RTAS sequence HCALLs

Hi Haren, kernel test robot noticed the following build warnings: [auto build test WARNING on powerpc/next] [also build test WARNING on powerpc/fixes linus/master v6.13-rc5 next-20241220] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest

[PATCH v2 5/5] crash: Remove KEXEC_CORE_NOTE_NAME

Now KEXEC_CORE_NOTE_NAME is only used at one place and it does not seem to provide any value anymore. Replace the remaining usage with the literal and remove the macro. Signed-off-by: Akihiko Odaki --- arch/s390/kernel/crash_dump.c | 2 +- include/linux/kexec.h | 2 -- include/linux/vmco

[PATCH v2 0/5] elf: Define note name macros

elf.h had a comment saying: > Notes used in ET_CORE. Architectures export some of the arch register > sets using the corresponding note types via the PTRACE_GETREGSET and > PTRACE_SETREGSET requests. > The note name for these types is "LINUX", except NT_PRFPREG that is > named "CORE". However, NT_

[PATCH v2 1/5] elf: Define note name macros

elf.h had a comment saying: > Notes used in ET_CORE. Architectures export some of the arch register > sets using the corresponding note types via the PTRACE_GETREGSET and > PTRACE_SETREGSET requests. > The note name for these types is "LINUX", except NT_PRFPREG that is > named "CORE". However, NT_

[PATCH v2 3/5] powwerpc: Use note name macros

Use note name macros to match with the userspace's expectation. Signed-off-by: Akihiko Odaki --- arch/powerpc/kernel/fadump.c | 2 +- arch/powerpc/platforms/powernv/opal-core.c | 8 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/fadump.c

[PATCH v2 4/5] crash: Use note name macros

Use note name macros to match with the userspace's expectation. Signed-off-by: Akihiko Odaki --- fs/proc/kcore.c | 12 ++-- include/linux/vmcore_info.h | 2 +- kernel/crash_core.c | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/proc/kcore.c

[PATCH v2 2/5] binfmt_elf: Use note name macros

Use note name macros to match with the userspace's expectation. Signed-off-by: Akihiko Odaki --- fs/binfmt_elf.c | 21 ++--- fs/binfmt_elf_fdpic.c | 8 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 106f0e8

Re: [PATCH net-next 04/13] net: enetc: add MAC filter for i.MX95 ENETC PF

On Fri, 3 Jan 2025 14:06:00 +0800 Wei Fang wrote: > The i.MX95 ENETC supports both MAC hash filter and MAC exact filter. MAC > hash filter is implenented through a 64-bits hash table to match against > the hashed addresses, PF and VFs each have two MAC hash tables, one is > for unicast and the oth

Re: [PATCH 14/19] powerpc: mpc83xx: Switch to of_platform_populate

On Thu, Jan 02, 2025 at 12:51:47PM -0600, Rob Herring wrote: > On Thu, Jan 2, 2025 at 12:32 PM J. Neuschäfer via B4 Relay > wrote: > > > > From: "J. Neuschäfer" > > > > Quoting from drivers/of/platform.c: > > > > > of_platform_populate() - [...] > > > Similar to of_platform_bus_probe(), this func

Re: [PATCH 3/6] powerpc/pseries: Add papr-indices char driver for ibm,get-indices HCALL

Hi Haren, kernel test robot noticed the following build warnings: [auto build test WARNING on powerpc/next] [also build test WARNING on powerpc/fixes linus/master v6.13-rc5 next-20241220] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest

Re: [PATCH 13/19] gpio: mpc8xxx: Add MPC8314 support

On Thu, Jan 02, 2025 at 10:38:22PM +0100, Linus Walleij wrote: > On Thu, Jan 2, 2025 at 7:32 PM J. Neuschäfer via B4 Relay > wrote: > > > From: "J. Neuschäfer" > > > > GPIO input, output, and interrupts have been tested on a MPC8314E board. > > > > Signed-off-by: J. Neuschäfer > > Reviewed-by: