"Gautham R. Shenoy" writes:
> From: "Gautham R. Shenoy"
>
> During a memory hotplug operations involving resizing of the HPT, we
> invoke a stop_machine() to perform the resizing. In this code path, we
> end up recursively taking the cpu_hotplug_lock, first in
> memory_hotplug_begin() and then su
"Gautham R. Shenoy" writes:
> From: "Gautham R. Shenoy"
>
> Subject: Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition
> in resize_hpt
ps. A "RESEND" implies the patch is unchanged and you're just resending
it because it was ignored.
In this case it should have just been "PA
On Tue, May 14, 2019 at 06:56:03AM +0200, Christophe Leroy wrote:
> Hi Greg,
>
> Could you please apply b45ba4a51cde29b2939365ef0c07ad34c8321789 to 4.9 since
> 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 was applied allthought marked for
> #4.13+
It does not apply there (nor to the 4.4.y queue, whic
Le 14/05/2019 à 08:55, Michael Neuling a écrit :
[...]
+
+static ssize_t dawr_write_file_bool(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct arch_hw_breakpoint null_brk
Guenter Roeck writes:
> On Fri, May 10, 2019 at 12:31:05AM +1000, Michael Ellerman wrote:
>> Greg Kroah-Hartman writes:
>> > On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>> >> I see multiple instances of:
>> >>
>> >> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>> >> atte
On Mon, 2019-05-13 at 23:23 -0300, Shawn Landden wrote:
> 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
> ---
Hi Shawn,
This patch
> And I like Steven's "(fault)" idea.
> How about this:
>
> if ptr < PAGE_SIZE -> "(null)"
> if IS_ERR_VALUE(ptr)-> "(fault)"
>
> -ss
Or:
if (ptr < PAGE_SIZE)
return ptr ? "(null+)" : "(null)";
if IS_ERR_VALUE(ptr)
On Tue, May 14, 2019 at 04:50:49PM +1000, Michael Ellerman wrote:
> Looks good. I even booted it :)
Cool, thanks!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Le 14/05/2019 à 08:56, Michael Ellerman a écrit :
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 coll
Michael Ellerman wrote:
"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 unit that can
Le 14/05/2019 à 10:31, Christophe Leroy a écrit :
Le 14/05/2019 à 08:56, Michael Ellerman a écrit :
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 fun
> On 14-May-2019, at 7:00 AM, Aneesh Kumar K.V
> wrote:
>
> 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 de
On Tue, May 14, 2019 at 10:29 AM David Laight wrote:
> > And I like Steven's "(fault)" idea.
> > How about this:
> >
> > if ptr < PAGE_SIZE -> "(null)"
> > if IS_ERR_VALUE(ptr)-> "(fault)"
> >
> > -ss
>
> Or:
> if (ptr < PAGE_SIZE)
>
PPC32 also have flush_dcache_range() so it can also support
ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kcon
On most arches having function flush_dcache_range(), including PPC32,
this function does a writeback and invalidation of the cache bloc.
On PPC64, flush_dcache_range() only does a writeback while
flush_inval_dcache_range() does the invalidation in addition.
In addition it looks like within arch/p
This patch drops the assembly PPC64 version of flush_dcache_range()
and re-uses the PPC32 static inline version.
With GCC 8.1, the following code is generated:
void flush_test(unsigned long start, unsigned long stop)
{
flush_dcache_range(start, stop);
}
0130 <.flush_test>:
1
This patch defines C helpers to retrieve the size of
cache blocks and uses them in the cacheflush functions.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cache.h | 16 ++--
arch/powerpc/include/asm/cacheflush.h | 24 +++-
2 files changed, 29 i
> On 14-May-2019, at 12:10 PM, Michael Ellerman wrote:
>
> "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 instruc
[Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
On powerpc32, patch_instruction() is called by apply_feature_fixups()
which is called from early_init()
There is the following note in front of early_init():
* Note that the kernel may be running at an address which is differ
Christophe Leroy writes:
> [Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
>
> On powerpc32, patch_instruction() is called by apply_feature_fixups()
> which is called from early_init()
>
> There is the following note in front of early_init():
> * Note that the kernel may be
Hi Michael,
On Tue, May 14, 2019 at 05:00:19PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> > From: "Gautham R. Shenoy"
> >
> > During a memory hotplug operations involving resizing of the HPT, we
> > invoke a stop_machine() to perform the resizing. In this code path, we
> > en
On Tue, May 14, 2019 at 05:02:16PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> > From: "Gautham R. Shenoy"
> >
> > Subject: Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock
> > acquisition in resize_hpt
>
> ps. A "RESEND" implies the patch is unchanged and you're just
Sachin Sant writes:
>> On 14-May-2019, at 7:00 AM, Aneesh Kumar K.V
>> wrote:
>>
>> 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] BU
Le 14/05/2019 à 10:57, Sachin Sant a écrit :
On 14-May-2019, at 7:00 AM, Aneesh Kumar K.V wrote:
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.21
Greg Kurz writes:
> Michael,
>
> Any comments on this patch ? Should I repost with a shorter comment
> as suggested by Alexey ?
No the longer comment seems fine to me.
I'm not a big fan of the patch, it's basically a hack :)
But for a backportable fix I guess it is OK.
I would be happier thoug
> On 14-May-2019, at 4:35 PM, Christophe Leroy wrote:
>
>
>
> Le 14/05/2019 à 10:57, Sachin Sant a écrit :
>>> On 14-May-2019, at 7:00 AM, Aneesh Kumar K.V
>>> wrote:
>>>
>>> On 5/8/19 4:30 PM, Sachin Sant wrote:
While running LTP tests (specifically futex_wake04) against next-201995
Hi Thiago,
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
>
> @@ -326,6 +356,10 @@ int ima_appraise_measurement(enum ima_hooks func,
> case INTEGRITY_UNKNOWN:
> break;
> case INTEGRITY_NOXATTRS:/* No EVM protected xattrs. */
> +
On Tue, 14 May 2019 21:13:40 +1000
Michael Ellerman wrote:
> Greg Kurz writes:
> > Michael,
> >
> > Any comments on this patch ? Should I repost with a shorter comment
> > as suggested by Alexey ?
>
> No the longer comment seems fine to me.
>
> I'm not a big fan of the patch, it's basically
ARM does this, so we might as well too.
I am a bit confused however as CONFIG_ALTIVEC does not select
CONFIG_PPC_FPU. Would you ever have altivec without a fpu?
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerp
Christophe Leroy writes:
> Le 14/05/2019 à 10:57, Sachin Sant a écrit :
>>> On 14-May-2019, at 7:00 AM, Aneesh Kumar K.V
>>> wrote:
>>> 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 LP
Le 14/05/2019 à 15:06, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 14/05/2019 à 10:57, Sachin Sant a écrit :
On 14-May-2019, at 7:00 AM, Aneesh Kumar K.V wrote:
On 5/8/19 4:30 PM, Sachin Sant wrote:
While running LTP tests (specifically futex_wake04) against next-20199597
build
https://bugzilla.kernel.org/show_bug.cgi?id=203161
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
The recent commit to cleanup ifdefs in the hugepage initialisation led
to crashes when using 4K pages as reported by Sachin:
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
Le 14/05/2019 à 15:43, Michael Ellerman a écrit :
The recent commit to cleanup ifdefs in the hugepage initialisation led
to crashes when using 4K pages as reported by Sachin:
BUG: Kernel NULL pointer dereference at 0x001c
Faulting instruction address: 0xc1d1e58c
Oops: Ker
The procedure to detect hardlockups is independent of the underlying
mechanism that generates the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.
For this purpo
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Group and wrap in #ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF a
When there are more than one implementation of the NMI watchdog, there may
be situations in which switching from one to another is needed (e.g., if
the time-stamp counter becomes unstable, the HPET-based NMI watchdog can
no longer be used.
The perf-based implementation of the hardlockup detector m
On 4/30/19 9:00 AM, Oliver O'Halloran wrote:
> On Mon, 2019-03-11 at 14:52 +0300, Sergey Miroshnichenko wrote:
>
>> When called within pcibios_sriov_enable(), the pci_sriov_get_totalvfs(pdev)
>> returns zero, because the device is yet preparing to enable the VFs.
>
> I don't think this is correct
This fixes the below crash that arises due to not handling page table allocation
failures while allocating hugetlb page table.
Fixes: e2b3d202d1db ("powerpc: Switch 16GB and 16MB explicit hugepages to a
different page table format")
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hugetlbpag
We only check for hugetlb allocations, because with hugetlb we do conditional
registration. For PGD/PUD/PMD levels we register them always in
pgtable_cache_init.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hugetlbpage.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --
This makes sure we don't enable HugeTLB if the cache is not configured.
I am still not sure about this. IMHO hugetlb support should be a hardware
support derivative and any cache allocation failure should be handled as I did
in the earlier patch. But then if we were not able to create hugetlb page
Michael Ellerman writes:
> The recent commit to cleanup ifdefs in the hugepage initialisation led
> to crashes when using 4K pages as reported by Sachin:
>
> BUG: Kernel NULL pointer dereference at 0x001c
> Faulting instruction address: 0xc1d1e58c
> Oops: Kernel access of bad ar
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 | 17 +
arch/powerpc/kernel/process.c | 30 ++
2 files change
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|
This is a note to let you know that I've just added the patch titled
[PATCH 69/76] cpu/speculation: Add 'mitigations=' cmdline option
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
[PATCH 70/76] x86/speculation: Support 'mitigations=' cmdline option
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the p
This is a note to let you know that I've just added the patch titled
[PATCH 25/32] cpu/speculation: Add 'mitigations=' cmdline option
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
[PATCH 26/32] x86/speculation: Support 'mitigations=' cmdline option
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
[PATCH 28/32] s390/speculation: Support 'mitigations=' cmdline option
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
[PATCH 23/30] cpu/speculation: Add 'mitigations=' cmdline option
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
[PATCH 24/30] x86/speculation: Support 'mitigations=' cmdline option
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
[PATCH 25/30] powerpc/speculation: Support 'mitigations=' cmdline
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the pat
This is a note to let you know that I've just added the patch titled
[PATCH 26/30] s390/speculation: Support 'mitigations=' cmdline option
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
[PATCH 21/27] x86/speculation: Support 'mitigations=' cmdline option
to the 5.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the p
This is a note to let you know that I've just added the patch titled
[PATCH 22/27] powerpc/speculation: Support 'mitigations=' cmdline
to the 5.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
[PATCH 23/27] s390/speculation: Support 'mitigations=' cmdline option
to the 5.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
[PATCH 20/27] cpu/speculation: Add 'mitigations=' cmdline option
to the 5.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
[PATCH 20/27] cpu/speculation: Add 'mitigations=' cmdline option
to the 5.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
[PATCH 22/27] powerpc/speculation: Support 'mitigations=' cmdline
to the 5.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
This is a note to let you know that I've just added the patch titled
[PATCH 23/27] s390/speculation: Support 'mitigations=' cmdline option
to the 5.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
[PATCH 21/27] x86/speculation: Support 'mitigations=' cmdline option
to the 5.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the p
This is a note to let you know that I've just added the patch titled
[PATCH 27/32] powerpc/speculation: Support 'mitigations=' cmdline
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the pat
Michael Ellerman writes:
> 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 d
On Tue, May 14, 2019 at 09:49:18AM -0300, Shawn Landden wrote:
> ARM does this, so we might as well too.
> I am a bit confused however as CONFIG_ALTIVEC does not select
> CONFIG_PPC_FPU. Would you ever have altivec without a fpu?
There is no hardware like that, none supported anyway. It does not
[ Purple is a nice shade on the bike shed. ;-) ]
On Tue, 14 May 2019 11:02:17 +0200
Geert Uytterhoeven wrote:
> On Tue, May 14, 2019 at 10:29 AM David Laight wrote:
> > > And I like Steven's "(fault)" idea.
> > > How about this:
> > >
> > > if ptr < PAGE_SIZE -> "(null)"
>
This is a note to let you know that I've just added the patch titled
cpu/speculation: Add 'mitigations=' cmdline option
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cpu-
This is a note to let you know that I've just added the patch titled
x86/speculation: Support 'mitigations=' cmdline option
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Hi Steve,
On Tue, May 14, 2019 at 8:37 PM Steven Rostedt wrote:
> On Tue, 14 May 2019 11:02:17 +0200
> Geert Uytterhoeven wrote:
> > On Tue, May 14, 2019 at 10:29 AM David Laight
> > wrote:
> > > > And I like Steven's "(fault)" idea.
> > > > How about this:
> > > >
> > > > if ptr < PAGE_
On Tue, 14 May 2019 21:13:06 +0200
Geert Uytterhoeven wrote:
> > > Do we care about the value? "(-E%u)"?
> >
> > That too could be confusing. What would (-E22) be considered by a user
> > doing an sprintf() on some string. I know that would confuse me, or I
> > would think that it was what the
On 05/14/2019 07:50 AM, Aneesh Kumar K.V wrote:
> This fixes the below crash that arises due to not handling page table
> allocation
> failures while allocating hugetlb page table.
Was there supposed to be a oops stack trace attached here in the commit log?
-Tyrel
>
> Fixes: e2b3d202d1db ("pow
On Tue, May 14, 2019 at 2:22 AM Russell Currey wrote:
>
> On Mon, 2019-05-13 at 23:23 -0300, Shawn Landden wrote:
> > 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
On Tue, May 14, 2019 at 12:43 AM Benjamin Herrenschmidt
wrote:
>
> 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 interru
Wireguard is not in the kernel (yet) and uses these symbols. (It is
IS_ENABLED so doesn't need it, but I think it is reasonable) I think these
enable/disable symbols should not be marked GPL-only.
El mar., 14 may. 2019 13:06, Segher Boessenkool
escribió:
> On Tue, May 14, 2019 at 09:49:18AM -030
Hi Shawn,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.1 next-20190514]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Strict module RWX is just like strict kernel RWX, but for modules - so
loadable modules aren't marked both writable and executable at the same
time. This is handled by the generic code in kernel/module.c, and
simply requires the architecture to implement the set_memory() set of
functions, declared
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 | 17 +
arch/powerpc/kernel/process.c | 30 ++
2 files change
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 | 17 +
arch/powerpc/kernel/process.c | 30 ++
2 files change
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.
v4: fix build without CONFIG_AVX
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/switch_to.h | 15 +---
arch/p
On Wed, May 15, 2019 at 03:35:51AM +1000, Daniel Axtens wrote:
>
> By all means disable vmx ctr if I don't get an answer to you in a
> timeframe you are comfortable with, but I am going to at least try to
> have a look.
I'm happy to give you guys more time. How much time do you think
you will nee
On Mon, May 13, 2019 at 11:24 PM Oliver wrote:
>
> 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.
> >
This fixes a build break introduced in with the recent round of CPU
bug patches.
arch/powerpc/kernel/security.c: In function ‘setup_barrier_nospec’:
arch/powerpc/kernel/security.c:59:21: error: implicit declaration of
function ‘cpu_mitigations_off’ [-Werror=implicit-function-declaration]
On Wed, May 15, 2019 at 02:22:06PM +0930, Joel Stanley wrote:
> This fixes a build break introduced in with the recent round of CPU
> bug patches.
>
> arch/powerpc/kernel/security.c: In function ‘setup_barrier_nospec’:
> arch/powerpc/kernel/security.c:59:21: error: implicit declaration of
>
On Wed, May 15, 2019 at 07:18:30AM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 15, 2019 at 02:22:06PM +0930, Joel Stanley wrote:
> > This fixes a build break introduced in with the recent round of CPU
> > bug patches.
> >
> > arch/powerpc/kernel/security.c: In function ‘setup_barrier_nospec’:
Strict module RWX is just like strict kernel RWX, but for modules - so
loadable modules aren't marked both writable and executable at the same
time. This is handled by the generic code in kernel/module.c, and
simply requires the architecture to implement the set_memory() set of
functions, declared
On (05/14/19 21:13), Geert Uytterhoeven wrote:
> I would immediately understand there's a missing IS_ERR() check in a
> function that can return -EINVAL, without having to add a new printk()
> to find out what kind of bogus value has been received, and without
> having to reboot, and trying to rep
Le 15/05/2019 à 03:30, Russell Currey a écrit :
Strict module RWX is just like strict kernel RWX, but for modules - so
loadable modules aren't marked both writable and executable at the same
time. This is handled by the generic code in kernel/module.c, and
simply requires the architecture to
Le 15/05/2019 à 03:37, Shawn Landden a écrit :
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
---
Could you please as usual list here the changes provided by each version
to ease the
Herbert Xu writes:
> On Wed, May 15, 2019 at 03:35:51AM +1000, Daniel Axtens wrote:
>>
>> By all means disable vmx ctr if I don't get an answer to you in a
>> timeframe you are comfortable with, but I am going to at least try to
>> have a look.
>
> I'm happy to give you guys more time. How much
[Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
On powerpc32, patch_instruction() is called by apply_feature_fixups()
which is called from early_init()
There is the following note in front of early_init():
* Note that the kernel may be running at an address which is differ
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
This license boilerplate should no
Oops, forgot to tell it's for 4.9. Resending with proper subject.
Le 15/05/2019 à 08:39, Christophe Leroy a écrit :
[Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
On powerpc32, patch_instruction() is called by apply_feature_fixups()
which is called from early_init()
The
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in RESEND V6
- change the Content-Transfer-Encoding to "q
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is [1/24, 8]. In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support f
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asr
> +static int change_page_ro(pte_t *ptep, pgtable_t token, unsigned long addr,
> void *data)
There are a couple way too long lines like this in the patch.
Le 15/05/2019 à 08:42, Christoph Hellwig a écrit :
+static int change_page_ro(pte_t *ptep, pgtable_t token, unsigned long addr,
void *data)
There are a couple way too long lines like this in the patch.
powerpc arch accepts 90 chars per line, see arch/powerpc/tools/checkpatch.pl
Christop
On Mon, May 13, 2019 at 2:04 PM Christoph Hellwig wrote:
>
> 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, an
98 matches
Mail list logo
