This trades verification complexity for runtime overheads due to the
nospec inserted because of the EINVAL.
With increased limits this allows applying mitigations to large BPF
progs such as the Parca Continuous Profiler's prog. However, this
requires a jump-seq limit of 256k. In any case, the same
On Thu, 13 Mar 2025 22:35:47 +0100, J. Neuschäfer wrote:
> Convert the Freescale localbus controller bindings from text form to
> YAML. Compared to the .txt version, the YAML binding contains a new
> usage example with FCM NAND flash, and a full list of compatible strings
> based on current usage
This is an effort to make the code simpler by making use of lock
guards which were introduced in [1], which works by using __cleanup
attributes. More details in v1 cover letter
This series aims mainly at simplifying code around mutex with goto
statements. If it makes sense, there are more code si
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161...@infradead.org/T/#u
Signed-off-by: Shrikanth Hegde
---
arch/powerpc/platforms/p
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161...@infradead.org/T/#u
Signed-off-by: Shrikanth Hegde
---
arch/powerpc/kernel/eeh.
Le 13/03/2025 à 14:49, Mike Rapoport a écrit :
From: "Mike Rapoport (Microsoft)"
max_mapnr is essentially the size of the memory map for systems that use
FLATMEM. There is no reason to calculate it in each and every architecture
when it's anyway calculated in alloc_node_mem_map().
Drop sett
On 3/14/25 11:15, Shrikanth Hegde wrote:
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161...@infradead.org/T/#u
Signed-off-by:
Similar to x86 the ppc boot code does not build with GCC 15.
Copy the fix from
commit ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
Signed-off-by: Michal Suchanek
---
v2: Move the fix outside of ifdef to apply to all subarchitectures
---
arch/powerpc/boot/Makefile | 2 ++
From: Guenter Roeck
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad parameters to
the tested functions. What is tested is the return value, not the existence
of a warning backtrace. Suppress the backtraces to avoid c
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 dealing with uapi hea
__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 completely mechanical patch
use scoped_guard for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161...@infradead.org/T/#u
Signed-off-by: Shrikanth Hegde
---
arch/powerpc/kernel/fadu
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161...@infradead.org/T/#u
Signed-off-by: Shrikanth Hegde
---
arch/powerpc/kernel/rtas
On Fri, 2025-03-14 at 11:15 +0530, Shrikanth Hegde wrote:
> use guard(mutex) for scope based resource management of mutex.
> This would make the code simpler and easier to maintain.
>
> More details on lock guards can be found at
> https://lore.kernel.org/all/20230612093537.614161...@infradead.org
use guard(mutex) for scope based resource management of mutex
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161...@infradead.org/T/#u
Signed-off-by: Shrikanth Hegde
---
arch/powerpc/sysdev/fsl_m
On 3/14/25 15:00, Shrikanth Hegde wrote:
On 3/14/25 11:15, Shrikanth Hegde wrote:
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.6
On Fri, Mar 14, 2025 at 05:38:18AM +0200, Wei Fang wrote:
> > > + __le16 update_act;
> > > + u8 dbg_opt;
> > > + u8 tblv_qact;
> > > +#define NTMP_QUERY_ACT GENMASK(3, 0)
> > > +#define NTMP_TBL_VER GENMASK(7, 0)
> > > +#define NTMP_TBLV_QACT(v, a) (FIELD_PREP(NTMP_TBL_VER
On Fri, Mar 14, 2025 at 11:15:41AM +0530, Shrikanth Hegde wrote:
> use guard(mutex) for scope based resource management of mutex.
> This would make the code simpler and easier to maintain.
>
> More details on lock guards can be found at
> https://lore.kernel.org/all/20230612093537.614161...@infrad
Best Regards,
Wei Fang
> -Original Message-
> From: Vladimir Oltean
> On Fri, Mar 14, 2025 at 05:38:18AM +0200, Wei Fang wrote:
> > > > + __le16 update_act;
> > > > + u8 dbg_opt;
> > > > + u8 tblv_qact;
> > > > +#define NTMP_QUERY_ACT GENMASK(3, 0)
> > > > +#d
Support starting of Hardware Trace Macro (HTM) function
via debugfs interface. Under debugfs folder
"/sys/kernel/debug/powerpc/htmdump", add file "htmstart".
The interface allows starting of htm via this file by
writing value "1". Also allows stopping of htm tracing by
writing value "0" to this fil
H_HTM (Hardware Trace Macro) hypervisor call is an HCALL to export data
from Hardware Trace Macro (HTM) function. The debugfs interface to
export the HTM function data in an lpar currently supports only dumping
of HTM data in an lpar. To add support for setup, configuration and
control of HTM funct
Support dumping status of Hardware Trace Macro (HTM) function
via debugfs interface. Under debugfs folder
"/sys/kernel/debug/powerpc/htmdump", add file "htmstatus”.
The interface allows only read of this file which will present the
content of HTM status buffer from the hcall. The 16th offset of HTM
H_HTM (Hardware Trace Macro) hypervisor call is an HCALL to export
data from Hardware Trace Macro (HTM) function. The debugfs interface
to export the HTM function data in a partition currently supports only
dumping of HTM data in an lpar. Patchset add support for configuration
and control of HTM fu
Support configuring of Hardware Trace Macro (HTM) function
via debugfs interface. Under debugfs folder
"/sys/kernel/debug/powerpc/htmdump", add file "htmconfigure".
The interface allows configuring of htm via this file
by writing value "1". Allow deconfiguring of htm via this file
by writing value
Documentation for HTM (Hardware Trace Macro) debugfs interface
and how it can be used to configure/control the HTM operations.
Signed-off-by: Athira Rajeev
---
Documentation/arch/powerpc/htm.rst | 104 +
1 file changed, 104 insertions(+)
create mode 100644 Documentat
> On Fri, Mar 14, 2025 at 06:51:06AM +0200, Wei Fang wrote:
> > > I don't understand the need for si->ops->setup_cbdr() and
> > > si->ops->teardown_cbdr()?
> > > Doesn't every call site know which kind of SI it is dealing with, and
> > > thus it
> can
> > > appropriately call the direct symbol?
>
Under debugfs folder, "/sys/kernel/debug/powerpc/htmdump", add file
"htmflags". Currently supported flag value is to enable/disable
HTM buffer wrap. wrap is used along with "configure" to prevent
HTM buffer from wrapping. Writing 1 will set noWrap while
configuring HTM
Signed-off-by: Athira Rajeev
Support dumping HTM capabilities information from Hardware
Trace Macro (HTM) function via debugfs interface. Under
debugfs folder "/sys/kernel/debug/powerpc/htmdump", add
file "htmcaps”.
The interface allows only read of this file which will present the
content of HTM buffer from the hcall.
Signe
After the first printk in __die() there is show_regs() ->
show_regs_print_info() which prints the current
preemption model.
Remove the preempion model from the arch code.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Naveen N Rao
Cc: linuxppc-dev@l
On Tue, 04 Feb 2025 21:05:26 +0530, Vaibhav Jain wrote:
> Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa
> counters") introduced 'vpa_pmu' to expose Book3s-HV nested APIv2 provided
> L1<->L2 context switch latency counters to L1 user-space via
> perf-events. However the newly
On Tue, 11 Mar 2025 15:51:39 +0800, Yicong Yang wrote:
> The core CPU control framework supports runtime SMT control which
> is not yet supported on arm64. Besides the general vulnerabilities
> concerns we want this runtime control on our arm64 server for:
>
> - better single CPU performance in so
13.2.0
arc allnoconfiggcc-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250314gcc-13.2.0
arc randconfig-001-20250315gcc-13.2.0
arc randconfig-002-20250314gcc-13.2.0
arc rand
On 3/14/25 13:55, Peter Zijlstra wrote:
On Fri, Mar 14, 2025 at 11:15:42AM +0530, Shrikanth Hegde wrote:
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org
Add htm setup support to htmdump module. To use the
HTM (Hardware Trace Macro), HTM buffer has to be allocated.
Support setup of HTM buffers via debugfs interface. Under
debugfs folder, "/sys/kernel/debug/powerpc/htmdump", add file
"htmsetup". The interface allows setup of HTM buffer by writing
siz
On Thu, 06 Mar 2025 11:24:28 +0100, Christophe Leroy wrote:
> In relocate_32.S, function clear_utlb_entry() goes into real mode. To
> do so, it has to calculate the physical address based on the virtual
> address. To get the virtual address it uses 'bl' which is problematic
> (see commit c974809a26
On Fri, Mar 14, 2025 at 11:15:42AM +0530, Shrikanth Hegde wrote:
> use guard(mutex) for scope based resource management of mutex.
> This would make the code simpler and easier to maintain.
>
> More details on lock guards can be found at
> https://lore.kernel.org/all/20230612093537.614161...@infrad
On 3/14/25 13:52, Peter Zijlstra wrote:
Thanks Peter for taking a look.
On Fri, Mar 14, 2025 at 11:15:41AM +0530, Shrikanth Hegde wrote:
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can b
37 matches
Mail list logo
