The new version info format has a superset of symbols in the old format.
Since this is a tool for in-tree modules, we don't need to parse the old
one with this tool any longer.
Signed-off-by: Matthew Maurer
---
scripts/export_report.pl | 22 ++
1 file changed, 10 insertions(+
With variable length symbol names from extended modversions, we can
enable MODVERSIONS alongside RUST due to support for its longer symbol
names.
Signed-off-by: Matthew Maurer
---
init/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index 9ffb103fc927..6cac
Adds a new format for modversions which stores each field in a separate
ELF section. This initially adds support for variable length names, but
could later be used to add additional fields to modversions in a
backwards compatible way if needed.
Since PPC munges its version records to strip leading
Functionality is almost identical, just structured for better
documentation and readability. Changes:
* Section names are checked for *all* non-SHT_NULL sections, not just
SHF_ALLOC sections. We have code that accesses section names of
non-SHF_ALLOC sections (see find_any_sec for example)
* Th
* modules.order has .o files when in a build dir, support this
* .mod.c source layout has changed, update regexes to match
* Add a stage 3, to be more robust against additional .mod.c content
Signed-off-by: Matthew Maurer
---
scripts/export_report.pl | 9 +++--
1 file changed, 7 insertions(+
The goal of this patch series is to allow MODVERSIONS and RUST to be
enabled simultaneously. The primary issue with doing this at the moment
is that Rust uses some extremely long symbol names - for those
unfamiliar with Rust, it may be helpful to think of some of the mangled
C++ names you may have
From: Nathan Lynch
Move the function descriptor table lookup out of rtas_function_token()
into a separate routine for use in new code to follow. No functional
change.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 31 +++
1 file changed, 19 insertions(
From: Nathan Lynch
Enabling any of the powerpc:rtas_* tracepoints at boot is likely to
result in an oops on RTAS platforms. For example, booting a QEMU
pseries model with 'trace_event=powerpc:rtas_input' in the command
line leads to:
BUG: Kernel NULL pointer dereference on read at 0x0008
From: Nathan Lynch
Allocate one identifying code (the first column of the ioctl-number
table) for the collection of PAPR miscdev drivers to share.
Signed-off-by: Nathan Lynch
---
arch/powerpc/include/uapi/asm/papr-miscdev.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powe
From: Nathan Lynch
Use the function lock API to prevent interleaving call sequences of
the ibm,activate-firmware RTAS function, which typically requires
multiple calls to complete the update. While the spec does not
specifically prohibit interleaved sequences, there's almost certainly
no advantag
From: Nathan Lynch
PowerVM LPARs may retrieve Vital Product Data (VPD) for system
components using the ibm,get-vpd RTAS function.
We can expose this to user space with a /dev/papr-vpd character
device, where the programming model is:
struct papr_location_code plc = { .str = "", }; /* obtain a
From: Nathan Lynch
Until now the papr_sysparm APIs have been kernel-internal. But user
space needs access to PAPR system parameters too. The only method
available to user space today to get or set system parameters is using
sys_rtas() and /dev/mem to pass RTAS-addressable buffers between user
spa
From: Nathan Lynch
Add selftests for /dev/papr-vpd, exercising the common expected use
cases:
* Retrieve all VPD by passing an empty location code.
* Retrieve the "system VPD" by passing a location code derived from DT
root node properties, as done by the vpdupdate command.
The tests also ver
From: Nathan Lynch
Consistently testing system parameter access is a bit difficult by
nature -- the set of parameters available depends on the model and
system configuration, and updating a parameter should be considered a
destructive operation reserved for the admin.
So we validate some of the
From: Nathan Lynch
Add a convenience macro for iterating over every element of the
internal function table and convert the one site that can use it. An
additional user of the macro is anticipated in changes to follow.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 9 +++--
1
Add character devices that expose PAPR-specific system parameters and
VPD to user space.
The problem: important platform features are enabled on Linux VMs
through the powerpc-specific rtas() syscall in combination with
writeable mappings of /dev/mem. In typical usage, this is encapsulated
behind A
From: Nathan Lynch
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions
From: Nathan Lynch
Not all of the generic RTAS function statuses specified in PAPR have
symbolic constants and descriptions in rtas.h. Fix this, providing a
little more background, slightly updating the existing wording, and
improving the formatting.
Signed-off-by: Nathan Lynch
---
arch/powerp
From: Nathan Lynch
The ability to get and set system parameters will be exposed to user
space, so let's get a little more strict about malformed
papr_sysparm_buf objects.
* Create accessors for the length field of struct papr_sysparm_buf.
The length is always stored in MSB order and this is be
From: Nathan Lynch
If the function descriptor has a populated lock member, then callers
are required to hold it across calls. Now that the firmware activation
sequence is appropriately guarded, we can warn when the requirement
isn't satisfied.
__do_enter_rtas_trace() gets reorganized a bit as a
Let us enable SBI based earlycon support in defconfigs for both RV32
and RV64 so that "earlycon=sbi" can be used again.
Signed-off-by: Anup Patel
Reviewed-by: Andrew Jones
---
arch/riscv/configs/defconfig | 1 +
arch/riscv/configs/rv32_defconfig | 1 +
2 files changed, 2 insertions(+)
dif
From: Atish Patra
RISC-V SBI specification supports advanced debug console
support via SBI DBCN extension.
Extend the HVC SBI driver to support it.
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
---
drivers/tty/hvc/Kconfig | 2 +-
drivers/tty/hvc/hvc_riscv_sbi.c | 59 +
We extend the existing RISC-V SBI earlycon support to use the new
RISC-V SBI debug console extension.
Signed-off-by: Anup Patel
Reviewed-by: Andrew Jones
---
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/earlycon-riscv-sbi.c | 24
2 files changed,
Let us provide SBI debug console helper routines which can be
shared by serial/earlycon-riscv-sbi.c and hvc/hvc_riscv_sbi.c.
Signed-off-by: Anup Patel
---
arch/riscv/include/asm/sbi.h | 5 +
arch/riscv/kernel/sbi.c | 43
2 files changed, 48 insertio
The functions sbi_console_putchar() and sbi_console_getchar() are
not defined when CONFIG_RISCV_SBI_V01 is disabled so let us add
stub of these functions to avoid "#ifdef" on user side.
Signed-off-by: Anup Patel
Reviewed-by: Andrew Jones
---
arch/riscv/include/asm/sbi.h | 5 +
1 file change
The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines
SBI debug console (DBCN) extension which replaces the legacy SBI v0.1
functions sbi_console_putchar() and sbi_console_getchar().
(Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)
This series adds
On Wed, 15 Nov 2023 15:39:36 +0100 Herve Codina wrote:
>- Removed Patches 6, 7 and 8 (patches applied)
>
>- Patches 7, 20, 21, 23 (patches 10, 23, 24, 26 in v8)
> Add 'Acked-by: Jakub Kicinski '
I thought someone (Mark?) asked for the networking stuff to be put
on a branch. If that'
Hi all,
I'm trying to fix the following -Wstringop-overflow warnings, and I'd like
to get your feedback on this, please:
In function 'do_byte_reverse',
inlined from 'do_vec_store' at
/home/gus/linux/arch/powerpc/lib/sstep.c:722:3,
inlined from 'emulate_loadstore' at
/home/gus/linux/arc
On 17/11/2023 14:07, Sakari Ailus wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Fri, Nov 17, 2023 at 01:07:44PM +0100, Hans Verkuil wrote:
>> Here is an RFC patch adding support for 'fraction_bits'. It's lacking
>> documentation, but it can be used for testing.
>>
>> It was rather a pain
On 11/17/23 at 09:37am, Liu, Yujie wrote:
> Hi Baoquan,
>
> On Fri, 2023-11-17 at 17:14 +0800, Baoquan He wrote:
> > Hi,
> >
> > On 11/16/23 at 05:04am, kernel test robot wrote:
> > > Hi Baoquan,
> > >
> > > kernel test robot noticed the following build errors:
> > >
> > > [auto build test ERRO
On Sat, Oct 21, 2023 at 10:16 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Oct 20, 2023 at 12:51:39PM +0530, Anup Patel wrote:
> > From: Atish Patra
> >
> > RISC-V SBI specification supports advanced debug console
> > support via SBI DBCN extension.
> >
> > Extend the HVC SBI driver to support it.
>
On Sat, Oct 21, 2023 at 10:16 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Oct 20, 2023 at 12:51:38PM +0530, Anup Patel wrote:
> > We extend the existing RISC-V SBI earlycon support to use the new
> > RISC-V SBI debug console extension.
> >
> > Signed-off-by: Anup Patel
> > Reviewed-by: Andrew Jones
Hi Hans,
Thank you for the patch.
On Fri, Nov 17, 2023 at 01:07:44PM +0100, Hans Verkuil wrote:
> Here is an RFC patch adding support for 'fraction_bits'. It's lacking
> documentation, but it can be used for testing.
>
> It was rather a pain logging fixed point number in a reasonable format,
> b
On Sat, Oct 21, 2023 at 10:05 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Oct 20, 2023 at 12:51:37PM +0530, Anup Patel wrote:
> > The functions sbi_console_putchar() and sbi_console_getchar() are
> > not defined when CONFIG_RISCV_SBI_V01 is disabled so let us add
> > stub of these functions to avoid
Hi Hans,
Thank you for the patch.
On Fri, Nov 17, 2023 at 01:07:44PM +0100, Hans Verkuil wrote:
> Here is an RFC patch adding support for 'fraction_bits'. It's lacking
> documentation, but it can be used for testing.
>
> It was rather a pain logging fixed point number in a reasonable format,
> b
Hi Tomasz,
On Thu, Nov 16, 2023 at 04:31:41PM +0900, Tomasz Figa wrote:
> On Wed, Nov 15, 2023 at 8:49 PM Laurent Pinchart wrote:
> > On Wed, Nov 15, 2023 at 12:19:31PM +0100, Hans Verkuil wrote:
> > > On 11/15/23 11:55, Laurent Pinchart wrote:
> > > > On Wed, Nov 15, 2023 at 09:09:42AM +0100, Han
Here is an RFC patch adding support for 'fraction_bits'. It's lacking
documentation, but it can be used for testing.
It was rather a pain logging fixed point number in a reasonable format,
but I think it is OK.
In userspace (where you can use floating point) it is a lot easier:
printf("%.*g\n",
On 17/11/23 4:52 am, Michael Ellerman wrote:
> Vishal Chourasia writes:
>> On 15/11/23 5:46 pm, Aneesh Kumar K V wrote:
>>> On 11/15/23 5:23 PM, Vishal Chourasia wrote:
On 15/11/23 1:39 pm, Aneesh Kumar K.V wrote:
> Vishal Chourasia writes:
>
>> This patch modifies the ARCH_HIB
Hello,
this series converts the platform drivers below drivers/net that are not
covered in the two other series converting drivers/net/ethernet and
drivers/net/wireless. I put them all in a single series even though they
are not maintained together. I thought that to be better than sending
them ou
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve h
On Tue, Oct 24, 2023 at 06:20:15PM +0200, David Gstir wrote:
> DCP is capable of performing AES with two hardware-bound keys:
>
> - The one-time programmable (OTP) key which is burnt via on-chip fuses
> - The unique key (UK) which is derived from the OTP key
>
> In addition to the two hardware-bo
Hi Baoquan,
On Fri, 2023-11-17 at 17:14 +0800, Baoquan He wrote:
> Hi,
>
> On 11/16/23 at 05:04am, kernel test robot wrote:
> > Hi Baoquan,
> >
> > kernel test robot noticed the following build errors:
> >
> > [auto build test ERROR on arm64/for-next/core]
> > [also build test ERROR on tip/x86/
Hi,
On 11/16/23 at 05:04am, kernel test robot wrote:
> Hi Baoquan,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on tip/x86/core powerpc/next powerpc/fixes
> linus/master v6.7-rc1 next-20231115]
> [If your p
- Original Message -
> From: "Timothy Pearson"
> To: "Timothy Pearson"
> Cc: "npiggin" , "linuxppc-dev"
>
> Sent: Friday, November 17, 2023 2:26:37 AM
> Subject: Re: [PATCH] powerpc: Fix data corruption on IPI
> - Original Message -
>> From: "Timothy Pearson"
>> To: "npiggi
On 17/11/23 4:52 am, Michael Ellerman wrote:
> Vishal Chourasia writes:
>> On 15/11/23 5:46 pm, Aneesh Kumar K V wrote:
>>> On 11/15/23 5:23 PM, Vishal Chourasia wrote:
On 15/11/23 1:39 pm, Aneesh Kumar K.V wrote:
> Vishal Chourasia writes:
>
>> This patch modifies the ARCH_HIB
- Original Message -
> From: "Timothy Pearson"
> To: "npiggin"
> Cc: "linuxppc-dev"
> Sent: Friday, November 17, 2023 2:20:29 AM
> Subject: Re: [PATCH] powerpc: Fix data corruption on IPI
> - Original Message -
>> From: "npiggin"
>> To: "Timothy Pearson" , "Michael Ellerman"
On 11/16/23 at 05:57am, kernel test robot wrote:
> Hi Baoquan,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on tip/x86/core powerpc/next powerpc/fixes
> linus/master v6.7-rc1 next-20231115]
> [If your patch
- Original Message -
> From: "npiggin"
> To: "Timothy Pearson" , "Michael Ellerman"
>
> Cc: "linuxppc-dev"
> Sent: Friday, November 17, 2023 2:01:12 AM
> Subject: Re: [PATCH] powerpc: Fix data corruption on IPI
> On Fri Nov 17, 2023 at 5:39 PM AEST, Timothy Pearson wrote:
>>
>>
>> -
On Fri Nov 17, 2023 at 5:39 PM AEST, Timothy Pearson wrote:
>
>
> - Original Message -
> > From: "Michael Ellerman"
> > To: "Timothy Pearson" , "linuxppc-dev"
> >
> > Cc: "Jens Axboe"
> > Sent: Tuesday, November 14, 2023 6:14:37 AM
> > Subject: Re: [PATCH] powerpc: Fix data corruption o
HeXin Tech Co. has applied for a new PVN from the OpenPower Community
for its new processor C2000. The OpenPower has assigned a new PVN
and this newly assigned PVN is 0x0066, add pvr register related
support for this PVN.
Signed-off-by: Zhao Ke
Link:
https://discuss.openpower.foundation/t/how-to
50 matches
Mail list logo
