Christophe Leroy writes:
> Some SCC functions like the QMC requires an extended parameter RAM.
> On modern 8xx (ie 866 and 885), SPI area can already be relocated,
> allowing the use of those functions on SCC2. But SCC3 and SCC4
> parameter RAM collide with SMC1 and SMC2 parameter RAMs.
>
> This
> > > > --
> > > > v2:
> > > > Fixes based on Christophe Leroy's comments:
> > > > - Fix commit message formatting
> > > > - Move more DAWR code into dawr.c
> > > > ---
> > > >arch/powerpc/Kconfig | 5 ++
> > > >arch/powerpc/include/asm/hw_breakpoint.h | 20
Borislav Petkov writes:
> On Fri, May 10, 2019 at 04:13:20PM +0200, Borislav Petkov wrote:
>> On Fri, May 10, 2019 at 08:50:52PM +1000, Michael Ellerman wrote:
>> > Yeah that looks better to me. I didn't think about the case where EDAC
>> > core is modular.
>> >
>> > Do you want me to send a new
"Aneesh Kumar K.V" writes:
> This fix the below crash that arise due to not handling page table allocation
> failures while allocating hugetlb page table.
>
> BUG: Kernel NULL pointer dereference at 0x001c
> Faulting instruction address: 0xc1d1e58c
> Oops: Kernel access of bad area,
Avoids confusion when printing Oops message like below
Faulting instruction address: 0xc008bdb4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
Either ibm,pa-features or ibm,powerpc-cpu-features can be used to enable the
M
Now that we have switched the page table walk to use pmd_is_leaf we can now
revert commit 8adddf349fda ("powerpc/mm/radix: Make Radix require HUGETLB_PAGE")
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/Kconfig.cputype | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
large devmap usage is dependent on THP. Hence once check is sufficient.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/pgtable.c | 2 +-
arch/powerpc/mm/pgtable_64.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/pgtable.c
b/a
Even when we have HugeTLB and THP disabled, kernel linear map can still be
mapped with hugepages. This is only an issue with radix translation because hash
MMU doesn't map kernel linear range in linux page table and other kernel
map areas are not mapped using hugepage.
Add config independent helpe
On Mon, 2019-05-13 at 22:44 -0300, Shawn Landden wrote:
> +
> +/*
> + * Were we in user mode when we were
> + * interrupted?
> + *
> + * Doing kernel_altivec/vsx_begin/end() is ok if we are running
> + * in an interrupt context from user mode - we'll just
> + * save the FPU state as required.
> + *
Le 14/05/2019 à 06:47, Michael Neuling a écrit :
On Mon, 2019-05-13 at 11:08 +0200, Christophe Leroy wrote:
Le 13/05/2019 à 09:17, Michael Neuling a écrit :
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.
Hi Greg,
Could you please apply b45ba4a51cde29b2939365ef0c07ad34c8321789 to 4.9
since 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 was applied allthought
marked for #4.13+
Thanks
Christophe
Le 13/05/2019 à 22:18, bugzilla-dae...@bugzilla.kernel.org a écrit :
https://bugzilla.kernel.org/show_bug
On Mon, 2019-05-13 at 17:40 +, Roy Pledge wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 5/13/2019 12:40 PM, Joakim Tjernlund wrote:
> > On Mon, 2019-
On Mon, 2019-05-13 at 11:08 +0200, Christophe Leroy wrote:
>
> Le 13/05/2019 à 09:17, Michael Neuling a écrit :
> > If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
> > at linking with:
> >arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined
> > reference to `
On 5/14/19 9:42 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 9:05 PM Aneesh Kumar K.V
wrote:
On 5/14/19 9:28 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 261734
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC||christophe.le
On 5/14/19 9:59 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
wrote:
We already add the start_pad to the resource->start but fails to section
align the start. This make sure with altmap we compute the right first
pfn when start_pad is zero and we are doing an align d
On 5/14/19 9:45 AM, Dan Williams wrote:
[ add Keith who was looking at something similar ]
On Mon, May 13, 2019 at 7:54 PM Aneesh Kumar K.V
wrote:
When we initialize the namespace, if we support altmap, we don't initialize all
the
backing struct page where as while releasing the namespace we
On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
wrote:
>
> We already add the start_pad to the resource->start but fails to section
> align the start. This make sure with altmap we compute the right first
> pfn when start_pad is zero and we are doing an align down of start address.
>
> Signed-off
[ add Keith who was looking at something similar ]
On Mon, May 13, 2019 at 7:54 PM Aneesh Kumar K.V
wrote:
>
> When we initialize the namespace, if we support altmap, we don't initialize
> all the
> backing struct page where as while releasing the namespace we look at some of
> these uninitilize
On Mon, May 13, 2019 at 9:05 PM Aneesh Kumar K.V
wrote:
>
> On 5/14/19 9:28 AM, Dan Williams wrote:
> > On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> The nfpn related change is needed to fix the kernel message
> >>
> >> "number of pfns truncated from 2617344 to 163584"
> >
On 5/14/19 9:28 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 2617344 to 163584"
The change makes sure the nfpns stored in the superblock is right value.
Signed-off-b
On 05/14/2019 08:23 AM, Aneesh Kumar K.V wrote:
> When we initialize the namespace, if we support altmap, we don't initialize
> all the
> backing struct page where as while releasing the namespace we look at some of
> these uninitilized struct page. This results in a kernel crash as below.
Yes thi
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
>
> The nfpn related change is needed to fix the kernel message
>
> "number of pfns truncated from 2617344 to 163584"
>
> The change makes sure the nfpns stored in the superblock is right value.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> d
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 2617344 to 163584"
The change makes sure the nfpns stored in the superblock is right value.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/pfn_devs.c| 6 +++---
drivers/nvdimm/region_devs.c | 8 +
We already add the start_pad to the resource->start but fails to section
align the start. This make sure with altmap we compute the right first
pfn when start_pad is zero and we are doing an align down of start address.
Signed-off-by: Aneesh Kumar K.V
---
kernel/memremap.c | 4 ++--
1 file chang
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled by
When we initialize the namespace, if we support altmap, we don't initialize all
the
backing struct page where as while releasing the namespace we look at some of
these uninitilized struct page. This results in a kernel crash as below.
kernel BUG at include/linux/mm.h:1034!
cpu 0x2: Vector: 700 (P
On (05/14/19 11:07), Sergey Senozhatsky wrote:
> How about this:
>
> if ptr < PAGE_SIZE -> "(null)"
No, this is totally stupid. Forget about it. Sorry.
> if IS_ERR_VALUE(ptr)-> "(fault)"
But Steven's "(fault)" is nice.
-ss
This second patch is separate because it could be wrong,
like I am not sure about how kernel thread migration works,
and it is even allowing simd in preemptible kernel code.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/switch_to.h | 15 ++-
arch/powerpc/kernel/process.c|
Based off the x86 one.
WireGuard really wants to be able to do SIMD in interrupts,
so it can accelerate its in-bound path.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 10 ++
arch/powerpc/kernel/process.c | 30 ++
2 files changed, 40 i
On (05/13/19 14:42), Petr Mladek wrote:
> > The "(null)" is good enough by itself and already an established
> > practice..
>
> (efault) made more sense with the probe_kernel_read() that
> checked wide range of addresses. Well, I still think that
> it makes sense to distinguish a pure NULL. And it
This second patch is separate because it could be wrong,
like I am not sure about how kernel thread migration works,
and it is even allowing simd in preemptible kernel code.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 8 +
arch/powerpc/include/asm/switch_to.h | 1
Based off the x86 one.
WireGuard really wants to be able to do SIMD in interrupts,
so it can accelerate its in-bound path.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 13 +
arch/powerpc/kernel/process.c | 30 ++
2 files changed, 4
On 5/8/19 4:30 PM, Sachin Sant wrote:
While running LTP tests (specifically futex_wake04) against next-20199597
build with 4K page size on a POWER8 LPAR following crash is observed.
[ 4233.214876] BUG: Kernel NULL pointer dereference at 0x001c
[ 4233.214898] Faulting instruction address: 0xc
This fix the below crash that arise due to not handling page table allocation
failures while allocating hugetlb page table.
BUG: Kernel NULL pointer dereference at 0x001c
Faulting instruction address: 0xc1d1e58c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=4K MMU=Hash
https://bugzilla.kernel.org/show_bug.cgi?id=203597
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 282745
--> https://bugzilla.kernel.org/attachment.cgi?id=282745&action=edit
bisect.log
--
You are receiving this mail because:
You are watching the assignee of the bug
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Bug ID: 203597
Summary: kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at
early stage
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 4.9.175
Hardwa
Michael,
Any comments on this patch ? Should I repost with a shorter comment
as suggested by Alexey ?
Cheers,
--
Greg
On Mon, 29 Apr 2019 12:36:59 +0200
Greg Kurz wrote:
> On Mon, 29 Apr 2019 16:01:29 +1000
> Alexey Kardashevskiy wrote:
>
> > On 20/04/2019 01:34, Greg Kurz wrote:
> > > Si
On Mon, 13 May 2019 11:14:58 +, Rasmus Villemoes wrote:
> Reading table 4-30, and its footnotes, of the QUICC Engine Block
> Reference Manual shows that the set of snum _values_ is not
> necessarily just a function of the _number_ of snums, as given in the
> fsl,qe-num-snums property.
>
> As a
On 5/13/2019 12:40 PM, Joakim Tjernlund wrote:
> On Mon, 2019-05-13 at 16:09 +, Roy Pledge wrote:
>> The index value should be passed to the of_parse_phandle()
>> function to ensure the correct property is read.
> Is this a bug fix? Maybe for stable too?
>
> Jocke
Yes this could go to stable.
On Mon, 2019-05-13 at 16:09 +, Roy Pledge wrote:
>
> The index value should be passed to the of_parse_phandle()
> function to ensure the correct property is read.
Is this a bug fix? Maybe for stable too?
Jocke
>
> Signed-off-by: Roy Pledge
> ---
> drivers/soc/fsl/qbman/dpaa_sys.c | 2 +-
"Naveen N. Rao" writes:
> When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is enabled, we always initialize
> DTL enable mask to DTL_LOG_PREEMPT (0x2). There are no other places
> where the mask is changed. As such, when reading the DTL log buffer
> through debugfs, there is no need to save and restore the
When using the reserved memory node in the device tree there are
two options - dynamic or static. If a dynamic allocation was
selected (where the kernel selects the address for the allocation)
convert it to a static allocation by inserting the reg property.
This will ensure the same memory is reuse
When shutting down a FQ on a dedicated channel only the
SW portal associated with that channel can dequeue from it.
Make sure the correct portal is use.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 53 +++-
1 file changed, 42 insertions(+),
Disable the QBMan interrupts during recovery.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 22 +++---
drivers/soc/fsl/qbman/qman_ccsr.c | 1 +
drivers/soc/fsl/qbman/qman_priv.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/s
If the QMan device was previously initialized make sure all the
frame queues are out of service once all the portals are probed.
This handles the case where the kernel is restarted without the
SoC being reset (kexec for example)
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c|
The drain_mr_fqni() function may be called fron uninterruptable
context so convert the msleep() to an mdelay(). Also ensure that
the valid bit is updated while polling.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --gi
The index value should be passed to the of_parse_phandle()
function to ensure the correct property is read.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/dpaa_sys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.c b/drivers/soc/fsl/qbman/
Clean the BMan buffer pools if the device had been initialized
previously. This will ensure a consistent state if the kernel
was soft restarted (kexec for example)
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/bman.c| 17 +
drivers/soc/fsl/qbman/bman_ccsr.c | 10
Rework QBMan private memory setup so that the areas are not
zeroed if the device was previously initialized
If the QMan private memory was already initialized skip the PFDR
initialization.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/bman_ccsr.c | 26 --
drivers/soc/f
Most DPAA1 devices do not support a soft reset which is an issue if
Kexec starts a new kernel. This patch series allows Kexec to function
by detecting that the QBMan device was previously initialized.
The patches fix some issues with device cleanup as well as ensuring
that the location of the QBMa
"Naveen N. Rao" writes:
> Introduce macros to encode the DTL enable mask fields and use those
> instead of hardcoding numbers.
This is a good cleanup on its own.
Acked-by: Nathan Lynch
Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
with -j 1") was also wrong.
The correct dependency is:
$(obj)/serial.o: $(obj)/autoconf.h
However, I do not see the reason why we need to copy autoconf.
On Mon, 13 May 2019 14:42:20 +0200
Petr Mladek wrote:
> > The "(null)" is good enough by itself and already an established
> > practice..
>
> (efault) made more sense with the probe_kernel_read() that
> checked wide range of addresses. Well, I still think that
> it makes sense to distinguish a
On 2019/5/8 17:42, John Garry wrote:
> On 18/04/2019 14:57, Zhen Lei wrote:
>> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
>> opportunity to set {lazy|strict} mode as default at build time. Then put
>> the three config options in an choice, make people can only choos
On Mon, May 13, 2019 at 11:56 PM Masahiro Yamada
wrote:
>
> On Mon, May 13, 2019 at 9:33 PM Masahiro Yamada
> wrote:
> >
> > Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> > was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> > with -j 1") was also w
On Mon, May 13, 2019 at 9:23 PM Masahiro Yamada
wrote:
>
> Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> with -j 1") was also wrong.
>
> Check-in source files never ever depend on build artifacts.
>
On Mon, May 13, 2019 at 9:33 PM Masahiro Yamada
wrote:
>
> Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> with -j 1") was also wrong.
>
> Check-in source files never ever depend on build artifacts.
>
On Mon 2019-05-13 12:13:20, Andy Shevchenko wrote:
> On Mon, May 13, 2019 at 08:52:41AM +, David Laight wrote:
> > From: christophe leroy
> > > Sent: 10 May 2019 18:35
> > > Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > > > On Fri, 10 May 2019 10:42:13 +0200
> > > > Petr Mladek wrote:
>
https://bugzilla.kernel.org/show_bug.cgi?id=203571
--- Comment #2 from Shawn Landden (sland...@gmail.com) ---
X86 manages to allow SIMD in interrupts through some very careful code in
arch/x86/kernel/fpu/core.c (starting with irq_fpu_usable())
PowerPC can do the same.
--
You are receiving this
On Fri 2019-05-10 12:40:58, Steven Rostedt wrote:
> On Fri, 10 May 2019 18:32:58 +0200
> Martin Schwidefsky wrote:
>
> > On Fri, 10 May 2019 12:24:01 -0400
> > Steven Rostedt wrote:
> >
> > > On Fri, 10 May 2019 10:42:13 +0200
> > > Petr Mladek wrote:
> > >
> > > > static const char *check
On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > toolchain, and switching endian without running `make clean` also works.
>
> For
Shawn Landden writes:
> It is safe to do SIMD in an interrupt on PowerPC.
No it's not sorry :)
> Only disable when there is no SIMD available
> (and this is a static branch).
>
> Tested and works with the WireGuard (Zinc) patch I wrote that needs this.
> Also improves performance of the crypto s
Herbert Xu writes:
> On Mon, May 06, 2019 at 08:53:17AM -0700, Eric Biggers wrote:
>>
>> Any progress on this? Someone just reported this again here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=203515
>
> Guys if I don't get a fix for this soon I'll have to disable CTR
> in vmx.
No objection
On Mon, 2019-05-13 at 11:14 +, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Reading table 4-30, and its footnotes, of the QUICC Engine
"Naveen N. Rao" writes:
> Michael Ellerman wrote:
>> Nicholas Piggin writes:
>>> The new mprofile-kernel mcount sequence is
>>>
>>> mflr r0
>>> bl_mcount
>>>
>>> Dynamic ftrace patches the branch instruction with a noop, but leaves
>>> the mflr. mflr is executed by the branch uni
Dmitry Vyukov writes:
> From: Arnd Bergmann
> Date: Sat, May 11, 2019 at 2:51 AM
> To: Dmitry Vyukov
> Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> linux-arch, Linux Kernel Mailing List, linuxppc-dev
>
>> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov wrote:
>> > >
>>
Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
with -j 1") was also wrong.
Check-in source files never ever depend on build artifacts.
The correct dependency is:
$(obj)/serial.o: $(obj)/autoconf.h
H
The local variable snum_init has no reason to have static storage duration.
Reviewed-by: Christophe Leroy
Reviewed-by: Qiang Zhao
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/so
The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the
MPC8309 has 14. The code path returning -EINVAL is also a recipe for
instant disaster, since the caller (qe_snums_init) uncritically
assigns the return value to the unsigned qe_num_of_snum, and would
thus proceed to attempt to copy
Add driver support for the newly introduced fsl,qe-snums property.
Conveniently, of_property_read_variable_u8_array does exactly what we
need: If the property fsl,qe-snums is found (and has an allowed size),
the array of values get copied to snums, and the return value is the
number of snums - we
Reading table 4-30, and its footnotes, of the QUICC Engine Block
Reference Manual shows that the set of snum _values_ is not
necessarily just a function of the _number_ of snums, as given in the
fsl,qe-num-snums property.
As an alternative, to make it easier to add support for other variants
of th
The 'try of_find_compatible_node(NULL, NULL, "fsl,qe"), fall back to
of_find_node_by_type(NULL, "qe")' pattern is repeated five
times. Factor it into a common helper.
Reviewed-by: Christophe Leroy
Reviewed-by: Qiang Zhao
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 71
The current array of struct qe_snum use 256*4 bytes for just keeping
track of the free/used state of each index, and the struct layout
means there's another 768 bytes of padding. If we just unzip that
structure, the array of snum values just use 256 bytes, while the
free/inuse state can be tracked
This small series consists of some small cleanups and simplifications
of the QUICC engine driver, and introduces a new DT binding that makes
it much easier to support other variants of the QUICC engine IP block
that appears in the wild: There's no reason to expect in general that
the number of vali
On 5/13/19 2:26 PM, Peter Zijlstra wrote:
> On Mon, May 13, 2019 at 09:42:13AM +0200, Peter Zijlstra wrote:
>> On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
>>> Add a check for sample_period value sent from userspace. Negative
>>> value does not make sense. And in powerpc arch c
The entire code in ldstfp.o is enclosed into #ifdef CONFIG_PPC_FPU,
so there is no point in building it when this config is not selected.
Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/Makefile | 3 ++-
arch/powerpc/lib/ldstfp.S | 4
quad.o is only for PPC64, and already included in obj64-y,
so it doesn't have to be in obj-y
Fixes: 31bfdb036f12 ("powerpc: Use instruction emulation infrastructure to
handle alignment faults")
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/Makefile | 2 +-
1 file changed, 1 insertion(+),
On 05/08/2019 10:29 AM, Nicholas Piggin wrote:
Abhishek Goel's on April 22, 2019 4:32 pm:
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, ther
On Mon, May 13, 2019 at 08:52:41AM +, David Laight wrote:
> From: christophe leroy
> > Sent: 10 May 2019 18:35
> > Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > > On Fri, 10 May 2019 10:42:13 +0200
> > > Petr Mladek wrote:
> > >> -if (probe_kernel_address(ptr, byte))
> > >> +
Le 13/05/2019 à 09:17, Michael Neuling a écrit :
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference
to `dawr_force_enable'
This was caused by commit c1fe190c0672 ("powerpc: Add
On Mon, May 13, 2019 at 09:42:13AM +0200, Peter Zijlstra wrote:
> On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
> > Add a check for sample_period value sent from userspace. Negative
> > value does not make sense. And in powerpc arch code this could cause
> > a recursive PMI leading
From: christophe leroy
> Sent: 10 May 2019 18:35
> Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > On Fri, 10 May 2019 10:42:13 +0200
> > Petr Mladek wrote:
> >
> >> static const char *check_pointer_msg(const void *ptr)
> >> {
> >> - char byte;
> >> -
> >>if (!ptr)
> >>ret
On 13.05.19 09:48, David Hildenbrand wrote:
> On 07.05.19 23:02, Dan Williams wrote:
>> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>>
>>> Let's prepare for better error handling while adding memory by allowing
>>> to use arch_remove_memory() and __remove_pages() even if
>>> CONFIG_M
On 07.05.19 23:02, Dan Williams wrote:
> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>
>> Let's prepare for better error handling while adding memory by allowing
>> to use arch_remove_memory() and __remove_pages() even if
>> CONFIG_MEMORY_HOTREMOVE is not set. CONFIG_MEMORY_HOTREMOVE
On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
> Add a check for sample_period value sent from userspace. Negative
> value does not make sense. And in powerpc arch code this could cause
> a recursive PMI leading to a hang (reported when running perf-fuzzer).
>
> Signed-off-by: Ravi
On 5/13/19 7:39 AM, Michael Neuling wrote:
> commit 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE
> interrupt controller") added an option to turn off Linux native XIVE
> usage via the xive=off kernel command line option.
>
> This documents this option.
>
> Signed-off-by: Michael N
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference to
`dawr_force_enable'
This was caused by commit c1fe190c0672 ("powerpc: Add force enable of
DAWR on P9 option").
This puts more of
On Fri, 2019-05-10 at 17:34 +0300, andriy.shevche...@linux.intel.com wrote:
> [External]
>
>
> On Fri, May 10, 2019 at 09:15:27AM +, Ardelean, Alexandru wrote:
> > On Wed, 2019-05-08 at 16:22 +0300, Alexandru Ardelean wrote:
> > > On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
> > > > On W
89 matches
Mail list logo
