On 6/23/21 4:46 PM, Michael Ellerman wrote:
> Peter Zijlstra writes:
>> On Wed, Jun 23, 2021 at 01:40:38PM +0530, kajoljain wrote:
>>>
>>> On 6/22/21 6:44 PM, Peter Zijlstra wrote:
On Thu, Jun 17, 2021 at 06:56:13PM +0530, Kajol Jain wrote:
> ---
> Kajol Jain (4):
> drivers/n
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 99fad093f43e..d6267
Patch #1, #2 are simple cleanup patches. Patch #3 adds
BPF_PROBE_MEM support with PowerPC 64bit JIT compiler.
Patch #4 adds explicit addr > TASK_SIZE_MAX check to
handle bad userspace pointers.
Ravi Bangoria (4):
bpf powerpc: Remove unused SEEN_STACK
bpf powerpc: Remove extra_pass from bpf_jit
In case of extra_pass, we always skips usual JIT passes. Thus
extra_pass is always false while calling bpf_jit_build_body()
and thus it can be removed.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit.h| 2 +-
arch/powerpc/net/bpf_jit_comp.c | 6 +++---
arch/powerpc/net/bpf_ji
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on PowerPC follows the generic PowerPC
exception table de
On PowerPC with KUAP enabled, any kernel code which wants to
access userspace needs to be surrounded by disable-enable KUAP.
But that is not happening for BPF_PROBE_MEM load instruction.
So, when BPF program tries to access invalid userspace address,
page-fault handler considers it as bad KUAP faul
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20210701]
[cannot apply to v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as doc
Adds a generic interface to represent the energy and frequency related
PAPR attributes on the system using the new H_CALL
"H_GET_ENERGY_SCALE_INFO".
H_GET_EM_PARMS H_CALL was previously responsible for exporting this
information in the lparcfg, however the H_GET_EM_PARMS H_CALL
will be deprecated
RFC: https://lkml.org/lkml/2021/6/4/791
PATCH v1: https://lkml.org/lkml/2021/6/16/805
Changelog v1 --> v2
Based on comments from Fabiano and Gautham, the following changes
were made:
1. Added flag attributes to fetch either single or all attributes from
the H_GET_ENERGY_SCALE_INFO HCALL
2. Sepe
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Can you do the same for 32bit ?
Unlike other archs which uses extable 'fixup' field to pass dest_re
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
On PowerPC with KUAP enabled, any kernel code which wants to
access userspace needs to be surrounded by disable-enable KUAP.
But that is not happening for BPF_PROBE_MEM load instruction.
So, when BPF program tries to access invalid userspace addre
On Tue, 06 Jul 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
Hi Everyone,
I'm trying to set up my (virtual) environment to test an old bug in the
PPC32 ptrace() code. I came across a completely different problem,
which seems to make gdb pretty much unusable on PPC32. I'm not sure if
this is a real kernel bug
On 06/07/2021 12:36, Lee Jones wrote:
> On Tue, 06 Jul 2021, Uwe Kleine-König wrote:
>
>> The driver core ignores the return value of this callback because there
>> is only little it can do when a device disappears.
>>
>> This is the final bit of a long lasting cleanup quest where several
>> buses
On Thu, 1 Jul 2021 17:24:12 +0200, Cédric Le Goater wrote:
> This is a smatch warning:
>
> arch/powerpc/sysdev/xive/common.c:1161 xive_request_ipi() warn: unsigned
> 'xid->irq' is never less than zero.
Applied to powerpc/fixes.
[1/1] powerpc/xive: Fix error handling when allocating an IPI
On Thu, 1 Jul 2021 11:17:08 + (UTC), Christophe Leroy wrote:
> The powerpc kernel is not prepared to handle exec faults from kernel.
> Especially, the function is_exec_fault() will return 'false' when an
> exec fault is taken by kernel, because the check is based on reading
> current->thread.re
On Thu, 1 Jul 2021 20:38:57 +0530, Naveen N. Rao wrote:
> The first patch fixes an issue that causes a soft lockup on ppc64 with
> the BPF_ATOMIC bounds propagation verifier test. The second one updates
> ppc32 JIT to reject atomic operations properly.
>
> - Naveen
>
> Naveen N. Rao (2):
> powe
On Tue, 6 Jul 2021 15:13:10 +1000, Nicholas Piggin wrote:
> BookE does not have mtmsrd, switch to use wrteei to enable MSR[EE].
Applied to powerpc/fixes.
[1/1] powerpc/64e: Fix system call illegal mtmsrd instruction
https://git.kernel.org/powerpc/c/1df3af6dc3cfe643f43d46f202bd44861ccbdb99
From: Lijun Pan
[ Upstream commit 73214a690c50a134bd364e1a4430e0e7ac81a8d8 ]
Fix the following kernel build warnings:
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member
'skb' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Fun
From: Lijun Pan
[ Upstream commit 73214a690c50a134bd364e1a4430e0e7ac81a8d8 ]
Fix the following kernel build warnings:
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member
'skb' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Fun
On 6/29/21 12:39 PM, kajoljain wrote:
>
>
> On 6/28/21 8:19 PM, Paul A. Clarke wrote:
>> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
>>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>>> to event handler dict") added functionality to report fields like
>>> weigh
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
> Le 04/07/2021 à 23:38, Radu Rendec a écrit :
> > I'm trying to set up my (virtual) environment to test an old bug in the
> > PPC32 ptrace() code. I came across a completely different problem,
> > which seems to make gdb pretty much unusab
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also re
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Tue, Jul 6, 2021 at 5:54 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tuesday 06 July 2021 11:50:37 Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
Em Tue, 6 Jul 2021 11:50:37 +0200
Uwe Kleine-König escreveu:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also retu
On 06-07-21, 11:50, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their r
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also re
On Tue, Jul 06 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their
On 06/07/2021 11:50:37+0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void fro
On 7/6/2021 3:20 PM, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remov
On Tue, Jul 06 2021, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Uwe Kleine-König wrote:
>
>> The driver core ignores the return value of this callback because there
>> is only little it can do when a device disappears.
>>
>> This is the final bit of a long lasting cleanup quest where several
>>
On 7/6/21 11:50 AM, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove ca
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also re
On Tue, Jul 06, 2021 at 01:17:37PM +0200, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Cornelia Huck wrote:
>
> > On Tue, Jul 06 2021, Uwe Kleine-König
> > wrote:
> >
> >> The driver core ignores the return value of this callback because there
> >> is only little it can do when a device disappea
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual) environment to test an old bug in the
PPC32 ptrace() code. I came across a completely different problem,
whic
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
> > So at this point, the AMD IOMMU driver does:
> >
> > swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
> >
> > where 'swiotlb' is a global
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
>Le 06/07/2021 à 13:56, Radu Rendec a écrit :
>> On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
>>> Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual) environment to test an old bug in the
P
Le 06/07/2021 à 15:50, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual) env
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
w
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> FWIW I was pondering the question of whether to do something along those
> lines or just scrap the default assignment entirely, so since I hadn't got
> round to saying that I've gone ahead and hacked up the alternative
> (similarly
On Tue, 2021-07-06 at 15:53 +0200, Christophe Leroy wrote:
>Le 06/07/2021 à 15:50, Radu Rendec a écrit :
>> On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
>>> Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
> Le 04/07/2021
Le 06/07/2021 à 16:05, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:53 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 15:50, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Ch
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > FWIW I was pondering the question of whether to do something along those
> > lines or just scrap the default assignment entirely, so since I hadn't got
> > round
Hi Nick,
Your patch works (see patch below)! Many thanks for your help! We tested
it on an A-EON AmigaOne X5000/20 and in a virtual e5500 QEMU machine today.
Screenshots:
-
http://www.skateman.nl/wp-content/uploads/2021/07/Screenshot-at-2021-07-06-113237.png
- https://i.ibb.co/h813RRp/Kerne
Hi Nirmoy,
This patch works! Thanks a lot! We tested it on an A-EON AmigaOne
X5000/20 today.
Screenshot:
http://www.skateman.nl/wp-content/uploads/2021/07/Screenshot-at-2021-07-06-113237.png
Cheers,
Christian
On 05 July 2021 at 06:48 pm, Christian Zigotzky wrote:
Hi Nirmoy,
Many thanks f
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead and
On 06.07.21 11:50, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove cal
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > FWIW I was pondering the question of whether to do something along those
> > > lines o
Happy to help, Christian :)
Nirmoy
On 7/6/2021 5:33 PM, Christian Zigotzky wrote:
Hi Nirmoy,
This patch works! Thanks a lot! We tested it on an A-EON AmigaOne
X5000/20 today.
Screenshot:
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.skateman.nl%2Fwp-content%2Fupload
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > > FWIW I was ponderi
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
> On 2021-07-06 15:05, Christoph Hellwig wrote:
> > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > FWIW I was pondering the question of whether to do something along those
> > > lines or just scrap the default assign
On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void f
Hello Bjorn,
On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index c1404d3dae2c..7f6fac618ab2 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/
Hi Will and Robin,
On 7/6/2021 10:06 AM, Will Deacon wrote:
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something al
Em Tue, Jul 06, 2021 at 05:26:12PM +0530, kajoljain escreveu:
>
>
> On 6/29/21 12:39 PM, kajoljain wrote:
> >
> >
> > On 6/28/21 8:19 PM, Paul A. Clarke wrote:
> >> On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
> >>> Commit 48a1f565261d ("perf script python: Add more PMU fields
>
On Tue 06 Jul 13:43 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> > On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > > index c1404d3dae2c..
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also re
On 7/6/21 2:50 AM, Uwe Kleine-König wrote:
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -381,7 +381,7 @@ static int ps3_system_bus_probe(struct device *_dev)
> return result;
> }
>
> -static int ps3_system_bus_remove(struct device *_
On Tue, Jul 6, 2021 at 12:50 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return voi
On Tue, 6 Jul 2021 at 03:56, Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void f
Uwe Kleine-König writes:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their remove callback.
>
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
On Tue, Jul 06 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their
Hello,
compared to (implicit) v1 that I sent earlier today
(https://lore.kernel.org/r/20210706095037.1425211-1-u.kleine-koe...@pengutronix.de)
the following is changed:
- Add three more patches preparing some s390 specific busses
and adapt them in the last patch. Thanks to Cornelia Huck for
On Tue, Jul 6, 2021 at 5:53 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tue, 2021-07-06 at 17:48 +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because
> there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
Hello,
v1 was acked by some more after I stopped looking in my mailbox while
preparing v2:
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is
On Tue, Jul 6, 2021 at 8:51 AM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
allnoconfig
i386 randconfig-a004-20210706
i386 randconfig-a006-20210706
i386 randconfig-a001-20210706
i386 randconfig-a003-20210706
i386 randconfig-a005-20210706
i386 randconfig-a002
ig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20210706
i386 randconfig-a006-20210706
i386 randconfig-a001-20210706
i386 randconfig-a00
On 7/6/21 3:23 PM, Christophe Leroy wrote:
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Can you do the same for 32bit ?
Sure. But before that,
@@ -763,6 +771,14 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
/* dst = *(u16 *)(ul) (src + off) */
case BPF_LDX | BPF_MEM | BPF_H:
case BPF_LDX | BPF_PROBE_MEM | BPF_H:
+ if (BPF_MODE(code) == BPF_PROBE_MEM) {
+
Currently it is vm-$currentpid which works as long as there is just one
VM per the userspace (99.99% cases) but produces a bunch
of "debugfs: Directory 'vm16679' with parent 'kvm' already present!"
when syzkaller (syscall fuzzer) is running so only one VM is present in
the debugfs for a given proce
On 7/7/21 12:45 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 06, 2021 at 05:26:12PM +0530, kajoljain escreveu:
>>
>>
>> On 6/29/21 12:39 PM, kajoljain wrote:
>>>
>>>
>>> On 6/28/21 8:19 PM, Paul A. Clarke wrote:
On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
> Commit 4
32 bits BOOKE have special interrupts for debug and other
critical events.
When handling those interrupts, dedicated registers are saved
in the stack frame in addition to the standard registers, leading
to a shift of the pt_regs struct.
Since commit db297c3b07af ("powerpc/32: Don't save thread.re
From: Athira Rajeev
Power10 performance monitoring unit (PMU) driver uses performance
monitor counter 5 (PMC5) and performance monitor counter 6 (PMC6)
for counting instructions and cycles. Event used for cycles is
PM_RUN_CYC and instructions is PM_RUN_INST_CMPL. But counting of these
events in w
79 matches
Mail list logo
