The HASHKEYR register contains a secret per-process key to enable unique
hashes per process. In general it should not be exposed to userspace
at all and a regular process has no need to know its key.
However, checkpoint restore in userspace (CRIU) functionality requires
that a process be able to
The DEXCR register is of interest when ptracing processes. Currently it
is static, but eventually will be dynamically controllable by a process.
If a process can control its own, then it is useful for it to be
ptrace-able to (e.g., for checkpoint-restore functionality).
It is also relevant to
Respin with requested ptrace/coredump support.
The new support is tested by making a core dump. The result has the expected
LINUX 0x0008 Unknown note type: (0x0111) description data: 00 00 00
04 00 00 00 00
LINUX 0x0008 Unknown note type: (0x0112) description data: 53 6c dd
Add a utility 'lsdexcr' to print the current DEXCR status. Useful for
quickly checking the status such as when debugging test failures or
verifying the new default DEXCR does what you want (for userspace at
least). Example output:
# ./lsdexcr
uDEXCR: 0400 (NPHIE)
HDEXCR:
Describe the DEXCR and document how to configure it.
Signed-off-by: Benjamin Gray
---
v2: * Document coredump & ptrace support
v1: * Remove the dynamic control docs, describe the static config
option
This documentation is a little bare for now, but will be expanded on
when
Make the DEXCR value configurable at config time. Intentionally don't
limit possible values to support future aspects without needing kernel
updates.
The default config value enables hashst/hashchk in problem state.
This should be safe, as generally software needs to request these
instructions be
* Include unistd.h for _exit()
* Include stdio.h for fprintf()
* Adds _MSG assertion variants to provide more context behind why a
failure occurred.
* Move ARRAY_SIZE macro to utils.h
The _MSG variants and ARRAY_SIZE will be used by the following
DEXCR selftests.
Signed-off-by: Benjamin Gray
The functions here use struct thread_struct fields, so need to import
the full definition from . The header
that defines current only forward declares struct thread_struct.
Failing to include this header leads to a compilation
error when a translation unit does not also include
indirectly.
Recognise and pass the appropriate signal to the user program when a
hashchk instruction triggers. This is independent of allowing
configuration of DEXCR[NPHIE], as a hypervisor can enforce this aspect
regardless of the kernel.
The signal mirrors how ARM reports their similar check failure. For
ISA 3.1B introduces the Dynamic Execution Control Register (DEXCR). It
is a per-cpu register that allows control over various CPU behaviours
including branch hint usage, indirect branch speculation, and
hashst/hashchk support.
Add some definitions and basic support for the DEXCR in the kernel.
ptrace-decl.h uses user_regset_get2_fn (among other things) from
regset.h. While all current users of ptrace-decl.h include regset.h
before it anyway, it adds an implicit ordering dependency and breaks
source tooling that tries to inspect ptrace-decl.h by itself.
Signed-off-by: Benjamin Gray
On 2023-03-30 10:59:19, Michael Ellerman wrote:
> Kautuk Consul writes:
> > On 2023-03-28 23:02:09, Michael Ellerman wrote:
> >> Kautuk Consul writes:
> >> > On 2023-03-28 15:44:02, Kautuk Consul wrote:
> >> >> On 2023-03-28 20:44:48, Michael Ellerman wrote:
> >> >> > Kautuk Consul writes:
> >>
On Wed, Mar 29, 2023 at 9:22 PM Rob Herring wrote:
>
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h,
> cpuhotplug.h,
On 29-03-23, 10:52, Rob Herring wrote:
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h and
> of.h) and drop including
On 29-03-23, 10:52, Rob Herring wrote:
> Removing the include of cpu.h from of_device.h causes an error:
>
> drivers/cpufreq/sun50i-cpufreq-nvmem.c:42:19: error: implicit declaration of
> function ‘get_cpu_device’; did you mean ‘get_device’?
> [-Werror=implicit-function-declaration]
>
> As
On 29-03-23, 10:52, Rob Herring wrote:
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h and
> of.h) and drop including
We call of_node_get() in wf_sat_probe() after sat is created,
so we need the of_node_put() before *kfree(sat)*.
Fixes: ac171c46667c ("[PATCH] powerpc: Thermal control for dual core G5s")
Signed-off-by: Liang He
---
drivers/macintosh/windfarm_smu_sat.c | 1 +
1 file changed, 1 insertion(+)
diff
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alpha defconfig gcc
alpharandconfig-r004-20230329 gcc
alpharandconfig
Anyone got time to review this one?
> On 16 Feb 2023, at 10:11 am, Rohan McLure wrote:
>
> Support the page table check sanitiser on all PowerPC platforms. This
> sanitiser works by serialising assignments, reassignments and clears of
> page table entries at each level in order to ensure that
successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alphaallyesconfig gcc
alpha defconfig gcc
alpharandconfig-r003-20230329 gcc
alpha
Kautuk Consul writes:
> On 2023-03-28 23:02:09, Michael Ellerman wrote:
>> Kautuk Consul writes:
>> > On 2023-03-28 15:44:02, Kautuk Consul wrote:
>> >> On 2023-03-28 20:44:48, Michael Ellerman wrote:
>> >> > Kautuk Consul writes:
>> >> > > kvmppc_vcore_create() might not be able to allocate
Currently the -mtune options are set in the Makefile, depending on what
the compiler supports.
One downside of doing it that way is that the chosen -mtune option is
not recorded in the .config.
Another downside is that if there's ever a need to do more complicated
logic to calculate the correct
On 28.03.23 12:21:04, Bjorn Helgaas wrote:
> [+cc linux-pci, more error handling folks; beginning of thread at
> https://lore.kernel.org/all/20230323213808.398039-1-terry.bow...@amd.com/]
>
> On Mon, Mar 27, 2023 at 11:51:39PM +0200, Robert Richter wrote:
> > On 24.03.23 17:36:56, Bjorn Helgaas
On Sat, Mar 25, 2023 at 1:09 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> It is not a good idea to change fundamental parameters of core memory
> management. Having predefined ranges suggests that the values within
> those ranges are sensible, but one has to *really* understand
>
Replace open coded reading of "reg" or of_get_address()/
of_translate_address() calls with a single call to
of_address_to_resource().
Signed-off-by: Rob Herring
---
v3:
- Fix compile in ls_uart.c (sigh)
v2:
- Fix compile in tsi108_dev.c
---
arch/powerpc/mm/numa.c| 21
On 27 Mar 2023, at 13:13, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> No other architecture intentionally writes back dirty cache lines into
> a buffer that a device has just finished writing into. If the cache is
> clean, this has no effect at all, but if a cacheline in the buffer has
>
On Mon, Mar 27, 2023 at 02:13:04PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> No other architecture intentionally writes back dirty cache lines into
> a buffer that a device has just finished writing into. If the cache is
> clean, this has no effect at all, but
> if a cacheline in
On Thu, Mar 16, 2023, Nicholas Piggin wrote:
> diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c
> b/tools/testing/selftests/kvm/lib/kvm_util.c
> index 3ea24a5f4c43..28ece960a0bb 100644
> --- a/tools/testing/selftests/kvm/lib/kvm_util.c
> +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
>
On Mon, Mar 27, 2023 at 02:13:05PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> For a DMA_BIDIRECTIONAL transfer, the caches have to be cleaned
> first to let the device see data written by the CPU, and invalidated
> after the transfer to let the CPU see data written by the device.
>
>
On Wed, Mar 29, 2023 at 10:52:13AM -0500, Rob Herring wrote:
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h,
>
On Wed, Mar 29, 2023 at 10:52:07AM -0500, Rob Herring wrote:
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Update the
> includes to use of.h instead of of_device.h.
>
Acked-by: Sudeep Holla
--
On Wed, Mar 29, 2023 at 10:52:01AM -0500, Rob Herring wrote:
> drivers/of/base.c is quite long and we've accumulated a number of CPU
> node functions. Let's move them to a new file, cpu.c, along with the
> lone of_cpu_device_node_get() in of_device.h. Moving the declaration has
> no effect yet as
Michael Ellerman writes:
> Nathan Lynch writes:
>> Nathan Lynch writes:
>>>
>>> aside: does anyone know if the display_status() code is worth keeping?
>>> It looks like it is used to drive the 16-character wide physical LCD I
>>> remember seeing on P4-era and older machines. Is it a vestige of
On Wed, Mar 29, 2023 at 10:52:07AM -0500, Rob Herring wrote:
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Update the
> includes to use of.h instead of of_device.h.
>
> Signed-off-by: Rob Herring
> ---
Dne sreda, 29. marec 2023 ob 17:52:12 CEST je Rob Herring napisal(a):
> Removing the include of cpu.h from of_device.h causes an error:
>
> drivers/cpufreq/sun50i-cpufreq-nvmem.c:42:19: error: implicit declaration of
> function ‘get_cpu_device’; did you mean ‘get_device’?
>
On Wed, Mar 29, 2023 at 5:53 PM Rob Herring wrote:
>
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h and
> of.h) and drop
On Wed, Mar 29, 2023 at 5:53 PM Rob Herring wrote:
>
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h and
> of.h) and drop
On Wed, Mar 29, 2023 at 5:52 PM Rob Herring wrote:
>
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Adjust the
> include files with what was implicitly included by of_device.h (cpu.h,
> cpuhotplug.h,
On Wed, Mar 29, 2023 at 11:53 PM Rob Herring wrote:
>
> Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
> implicitly including other includes, and is no longer needed. Just drop
> including of_device.h as of.h is already included.
>
> Signed-off-by: Rob Herring
> ---
>
drivers/of/base.c is quite long and we've accumulated a number of CPU
node functions. Let's move them to a new file, cpu.c, along with the
lone of_cpu_device_node_get() in of_device.h. Moving the declaration has
no effect yet as of.h is included by of_device.h. This serves as
preparation to
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include files with what was implicitly included by of_device.h (cpu.h and
of.h) and drop including of_device.h.
Signed-off-by: Rob Herring
---
Please
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include files with what was implicitly included by of_device.h (cpu.h and
of.h) and drop including of_device.h.
Signed-off-by: Rob Herring
---
Please
Removing the include of cpu.h from of_device.h (included by
of_platform.h) causes an error:
drivers/soc/mediatek/mtk-svs.c:2134:41: error: implicit declaration of function
'get_cpu_device'; did you mean 'get_swap_device'?
[-Werror=implicit-function-declaration]
of_platform.h is still needed
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include files with what was implicitly included by of_device.h (cpu.h and
of.h) and drop including of_device.h.
Signed-off-by: Rob Herring
---
Please
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include files with what was implicitly included by of_device.h (cpu.h and
of.h) and drop including of_device.h.
Signed-off-by: Rob Herring
---
Please
of_device.h mostly defines functions for bus drivers whereas
of_device_get_match_data() is used by drivers. Let's move it to of.h.
Signed-off-by: Rob Herring
---
include/linux/of.h| 2 ++
include/linux/of_device.h | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Just drop
including of_device.h as of.h is already included.
Signed-off-by: Rob Herring
---
Please ack and I will take the series via the DT tree.
---
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Just drop
including of_device.h as of.h is already included.
Signed-off-by: Rob Herring
---
Please ack and I will take the series via the DT tree.
---
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Update the
includes to use of.h instead of of_device.h.
Signed-off-by: Rob Herring
---
Please ack and I will take the series via the DT tree.
---
Sparc is the only place devtree_lock is used outside of drivers/of/.
Move the devtree_lock declaration into of_private.h and Sparc's prom.h
so pulling in spinlock.h to of.h can be avoided for everything besides
Sparc.
Signed-off-by: Rob Herring
---
arch/sparc/include/asm/prom.h | 3 +++
Removing the include of cpu.h from of_device.h (included by
of_platform.h) causes an error in setup.c:
arch/riscv/kernel/setup.c:313:22: error: arithmetic on a pointer to an
incomplete type 'typeof(struct cpu)' (aka 'struct cpu')
The of_platform.h header is not necessary either, so it can be
Removing include of cpu.h from of_device.h (included by of_platform.h)
causes an error in ingenic-timer:
drivers/clocksource/ingenic-timer.c: In function ‘ingenic_tcu_init’:
drivers/clocksource/ingenic-timer.c:338:15: error: implicit declaration of
function ‘cpuhp_setup_state’
The of_platform.h
Removing the include of cpu.h from of_device.h causes an error:
drivers/cpufreq/sun50i-cpufreq-nvmem.c:42:19: error: implicit declaration of
function ‘get_cpu_device’; did you mean ‘get_device’?
[-Werror=implicit-function-declaration]
As of_device.h is not otherwise needed, it can be replaced
Drop unnecessary includes in DT headers. Some simply aren't needed and
some can be replaced with forward declarations.
Signed-off-by: Rob Herring
---
include/linux/of.h | 5 ++---
include/linux/of_device.h | 3 ++-
include/linux/of_platform.h | 5 +++--
3 files changed, 7
Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include files with what was implicitly included by of_device.h (cpu.h,
cpuhotplug.h, of.h, and of_platform.h) and drop including of_device.h.
Now that all users which had an implicit dependency on cpu.h have been
fixed. the cpu.h include can be dropped from of_device.h
Signed-off-by: Rob Herring
---
include/linux/of_device.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index
Removing the include of cpu.h from of_device.h causes an error:
drivers/irqchip/irq-loongson-eiointc.c:420:9: error: implicit declaration of
function 'cpuhp_setup_state_nocalls' [-Werror=implicit-function-declaration]
This driver doesn't even use DT, so all the DT includes can be dropped.
As of_device_(add|register|unregister) functions work on struct
platform_device, they should be declared in of_platform.h instead.
This move is transparent for now as both headers include each other.
Signed-off-by: Rob Herring
---
include/linux/of_device.h | 4
(-)
---
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
change-id: 20230329-dt-cpu-header-cleanups-c7bed8c0b352
Best regards,
--
Rob Herring
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 198925fae644b0099b66fac1d972721e6e563b17 Add linux-next specific
files for 20230329
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303082135.njdx1bij-...@intel.com
https
Em Tue, Mar 28, 2023 at 09:21:49AM -0700, Ian Rogers escreveu:
> On Tue, Mar 28, 2023 at 4:30 AM Kajol Jain wrote:
> >
> > Commit 3c22ba524304 ("perf vendor events powerpc: Update POWER9 events")
> > added and updated power9 pmu json events. However some of the json
> > events which are part of
Nathan Lynch via B4 Relay
writes:
> From: Nathan Lynch
>
> The function name va_rtas_call_unlocked() is confusing: it may be
> called with or without rtas_lock held. Rename it to va_rtas_call().
I'm not sure about this one.
The "unlocked" is meant to convey that it doesn't do any locking. The
Nathan Lynch writes:
> Nathan Lynch writes:
>>
>> aside: does anyone know if the display_status() code is worth keeping?
>> It looks like it is used to drive the 16-character wide physical LCD I
>> remember seeing on P4-era and older machines. Is it a vestige of
>> non-LPAR pseries that should
It's not necessary to prefix every command in archhelp with "@" (to
supress echoing the command), because that is done by the top level
Makefile when it evaluates archhelp.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Makefile | 38 +++---
1 file changed, 19
Currently none of the generated defconfigs appear in the help output,
because the help text discovers defconfigs by looking for actual files
named "*_defconfig".
Collect the generated defconfig names into a variable and then print
those out in archhelp.
Output looks like eg:
65 matches
Mail list logo
