Naveen N. Rao's on May 14, 2019 6:32 pm:
> Michael Ellerman wrote:
>> "Naveen N. Rao" writes:
>>> Michael Ellerman wrote:
Nicholas Piggin writes:
> The new mprofile-kernel mcount sequence is
>
> mflrr0
> bl _mcount
>
> Dynamic ftrace patches the branch
Hello Nicholas,
On Thu, May 16, 2019 at 02:55:42PM +1000, Nicholas Piggin wrote:
> Abhishek's on May 13, 2019 7:49 pm:
> > 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
Eric Biggers writes:
> On Thu, May 16, 2019 at 12:12:48PM +1000, Daniel Axtens wrote:
>>
>> I'm also seeing issues with ghash with the extended tests:
>>
>> [7.582926] alg: hash: p8_ghash test failed (wrong result) on test vector
>> 0, cfg="random: use_final src_divs=[9.72%@+39832,
>>
Aneesh Kumar K.V's on May 14, 2019 4:02 pm:
> 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
Abhishek's on May 13, 2019 7:49 pm:
> 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.
= 0xc00a
vmemmap start = 0xc00c
-
Signed-off-by: Nicholas Piggin
I fear your change defeats most of the purpose of commit
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20190515
Paul Mackerras's on May 13, 2019 4:42 pm:
> On Sun, Apr 28, 2019 at 09:45:15PM +1000, Nicholas Piggin wrote:
>> This is the KVM update to the new idle code. A few improvements:
>>
>> - Idle sleepers now always return to caller rather than branch out
>> to KVM first.
>> - This allows
On Thu, May 16, 2019 at 12:12:48PM +1000, Daniel Axtens wrote:
>
> I'm also seeing issues with ghash with the extended tests:
>
> [7.582926] alg: hash: p8_ghash test failed (wrong result) on test vector
> 0, cfg="random: use_final src_divs=[9.72%@+39832,
> 18.2%@+65504,
Memory affintiy updates as currently implemented have proved unstable.
This patch comments out the PRRN hook for the time being while we
investigate how to either stablize the current implementation or find a
better approach.
Signed-off-by: Tyrel Datwyler
---
When we receive a PRRN event through the event-scan interface we call
pseries_devicetree_update() to update the affinty properties in our
device tree via RTAS. Following this our implemenation attempts to both
frob the existing kernel cpu numa affinities of the live system with the
new device tree
The current dlpar_cpu_readd() takes in a cpu_id and uses that to look up
the cpus device_node so that we can get at the ibm,my-drc-index
property. The only user of cpu readd is an OF notifier call back. This
call back already has a reference to the device_node and therefore can
retrieve the
On Wed, May 15, 2019 at 08:49:48PM +0200, Christophe Leroy wrote:
>
>
> Le 15/05/2019 à 16:05, Horia Geanta a écrit :
> > On 5/15/2019 3:29 PM, Christophe Leroy wrote:
> > > Selftests report the following:
> > >
> > > [2.984845] alg: skcipher: cbc-aes-talitos encryption test failed
> > >
Daniel Axtens writes:
> 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
Radix boot looks like this:
-
phys_mem_size = 0x2
dcache_bsize = 0x80
icache_bsize = 0x80
cpu_features = 0xc06f8f5fb1a7
possible= 0xfbffcf5fb1a7
always = 0x0003800081a1
On Wed, May 15, 2019 at 1:27 AM Christophe Leroy
wrote:
> Could you please as usual list here the changes provided by each version
> to ease the review ?
A bunch of embarrassing stuff that caused it not to build on some
set-ups (the functions were under the wrong include guards), and I
added
On Wed, 2019-05-15 at 06:20 +, Christophe Leroy wrote:
> 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
On Tue, 2019-05-14 at 23:41 -0700, Christoph Hellwig wrote:
> > + * 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
>
On 2019-05-15, Christian Brauner wrote:
> On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote:
> > Would it be possible to create file descriptor with "restricted"
> > operation ?
> >
> > - O_RDONLY: waiting for process completion allowed (for example)
> > - O_WRONLY: sending process
Hi,
Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit :
>
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 20881598bdfa..237d18d6ecb8 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct
> pid_namespace *ns)
>
Hi,
Le mercredi 15 mai 2019 à 16:16 +0200, Christian Brauner a écrit :
> On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote:
> > Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit :
> > > diff --git a/kernel/pid.c b/kernel/pid.c
> > > index 20881598bdfa..237d18d6ecb8
Le 15/05/2019 à 16:05, Horia Geanta a écrit :
On 5/15/2019 3:29 PM, Christophe Leroy wrote:
Selftests report the following:
[2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong output IV) on
test vector 0, cfg="in-place"
[2.995377] : 3d af ba 42 9d 9e b4
On Wed, May 15, 2019 at 05:35:15PM +0200, Oleg Nesterov wrote:
> On 05/15, Oleg Nesterov wrote:
> >
> > On 05/15, Christian Brauner wrote:
> > >
> > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags)
> > > +{
> > > + int fd, ret;
> > > + struct pid *p;
> > > + struct task_struct *tsk;
On 05/15, Oleg Nesterov wrote:
>
> On 05/15, Christian Brauner wrote:
> >
> > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags)
> > +{
> > + int fd, ret;
> > + struct pid *p;
> > + struct task_struct *tsk;
> > +
> > + if (flags)
> > + return -EINVAL;
> > +
> > + if
On Wed, May 15, 2019 at 05:19:13PM +0200, Oleg Nesterov wrote:
> On 05/15, Christian Brauner wrote:
> >
> > On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote:
> > >
> > > it seems that you can do a single check
> > >
> > > tsk = pid_task(p, PIDTYPE_TGID);
> > > if (!tsk)
> > >
On 05/15, Christian Brauner wrote:
>
> On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote:
> >
> > it seems that you can do a single check
> >
> > tsk = pid_task(p, PIDTYPE_TGID);
> > if (!tsk)
> > ret = -ESRCH;
> >
> > this even looks more correct if we race with
Le 15/05/2019 à 16:16, Greg KH a écrit :
On Wed, May 15, 2019 at 01:30:42PM +, Christophe Leroy wrote:
[Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
On powerpc32, patch_instruction() is called by apply_feature_fixups()
which is called from early_init()
There is
On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote:
> On 05/15, Christian Brauner wrote:
> >
> > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags)
> > +{
> > + int fd, ret;
> > + struct pid *p;
> > + struct task_struct *tsk;
> > +
> > + if (flags)
> > +
On 05/15, Christian Brauner wrote:
>
> +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags)
> +{
> + int fd, ret;
> + struct pid *p;
> + struct task_struct *tsk;
> +
> + if (flags)
> + return -EINVAL;
> +
> + if (pid <= 0)
> + return -EINVAL;
>
On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote:
> Hi,
>
> Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit :
> >
> > diff --git a/kernel/pid.c b/kernel/pid.c
> > index 20881598bdfa..237d18d6ecb8 100644
> > --- a/kernel/pid.c
> > +++ b/kernel/pid.c
> > @@ -451,6
On Wed, May 15, 2019 at 01:30:42PM +, Christophe Leroy wrote:
> [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
On 5/15/2019 3:29 PM, Christophe Leroy wrote:
> Selftests report the following:
>
> [2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong
> output IV) on test vector 0, cfg="in-place"
> [2.995377] : 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
> [
In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") the following piece of code was added:
smp_call_function((smp_call_func_t)set_dawr, _brk, 0);
Since GCC 8 this triggers the following warning about incompatible
function types:
Hi Christoph,
On Wed, May 15, 2019 at 3:14 PM Christoph Hellwig wrote:
>
> On Wed, May 15, 2019 at 02:09:42PM +0200, Mathieu Malaterre wrote:
> > In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> > option") the following piece of code was added:
> >
> >
https://bugzilla.kernel.org/show_bug.cgi?id=203609
Bug ID: 203609
Summary: Build error: implicit declaration of function
'cpu_mitigations_off'
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 4.19.43 and 4.14.119
Le 15/05/2019 à 15:08, Greg KH a écrit :
On Wed, May 15, 2019 at 02:35:36PM +0200, Christophe Leroy wrote:
Le 15/05/2019 à 10:29, Greg KH a écrit :
On Wed, May 15, 2019 at 06:40:47AM +, Christophe Leroy wrote:
[Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
On
[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
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 8 +++
arch/powerpc/mm/pgtable_64.c | 54 +---
2 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
This does not actually enable huge vmap mappings, because powerpc/64
ioremap does not call ioremap_page_range, but it is required before
implementing huge mappings in ioremap, because the generic vunmap code
needs to cope with them.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Kconfig
This appears to help cached git diff performance by about 5% on a
POWER9 (with 32MB dentry cache hash).
Profiling git diff dTLB misses with a vanilla kernel:
81.75% git [kernel.vmlinux][k] __d_lookup_rcu
7.21% git [kernel.vmlinux][k] strncpy_from_user
1.77% git
hashdist currently always uses vmalloc when hashdist is true. When
there is only 1 online node and size <= MAX_ORDER, vmalloc can be
avoided.
Signed-off-by: Nicholas Piggin
---
mm/page_alloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c
The kernel currently clamps large system hashes to MAX_ORDER when
hashdist is not set, which is rather arbitrary.
vmalloc space is limited on 32-bit machines, but this shouldn't
result in much more used because of small physical memory.
Signed-off-by: Nicholas Piggin
---
mm/page_alloc.c | 8
On Wed, May 15, 2019 at 02:09:42PM +0200, Mathieu Malaterre wrote:
> In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> option") the following piece of code was added:
>
>smp_call_function((smp_call_func_t)set_dawr, _brk, 0);
>
> Since GCC 8 this trigger the following warning
On Wed, May 15, 2019 at 02:35:36PM +0200, Christophe Leroy wrote:
>
>
> Le 15/05/2019 à 10:29, Greg KH a écrit :
> > On Wed, May 15, 2019 at 06:40:47AM +, Christophe Leroy wrote:
> > > [Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
> > >
> > > On powerpc32,
Le 15/05/2019 à 10:29, Greg KH a écrit :
On Wed, May 15, 2019 at 06:40:47AM +, Christophe Leroy wrote:
[Backport of upstream commit b45ba4a51cde29b2939365ef0c07ad34c8321789]
On powerpc32, patch_instruction() is called by apply_feature_fixups()
which is called from early_init()
There is
On Wed, May 15, 2019 at 12:04 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls that is only
>
From: Diana Craciun
commit 039daac5526932ec731e4499613018d263af8b3e upstream.
Fixed the following build warning:
powerpc-linux-gnu-ld: warning: orphan section `__btb_flush_fixup' from
`arch/powerpc/kernel/head_44x.o' being placed in section
`__btb_flush_fixup'.
Signed-off-by: Diana Craciun
From: Diana Craciun
commit c28218d4abbf4f2035495334d8bfcba64bda4787 upstream.
Used barrier_nospec to sanitize the syscall table.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/entry_32.S | 10 ++
1 file
From: Diana Craciun
commit 7fef436295bf6c05effe682c8797dfcb0deb112a upstream.
In order to protect against speculation attacks on
indirect branches, the branch predictor is flushed at
kernel entry to protect for the following situations:
- userspace process attacking another userspace process
-
From: Diana Craciun
commit 98518c4d8728656db349f875fcbbc7c126d4c973 upstream.
In order to flush the branch predictor the guest kernel performs
writes to the BUCSR register which is hypervisor privilleged. However,
the branch predictor is flushed at each KVM entry, so the branch
predictor has
From: Diana Craciun
commit e7aa61f47b23afbec41031bc47ca8d6cb6516abc upstream.
Switching from the guest to host is another place
where the speculative accesses can be exploited.
Flush the branch predictor when entering KVM.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
From: Diana Craciun
commit 3bc8ea8603ae4c1e09aca8de229ad38b8091fcb3 upstream.
If the user choses not to use the mitigations, replace
the code sequence with nops.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
Selftests report the following:
[2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong
output IV) on test vector 0, cfg="in-place"
[2.995377] : 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
[3.032673] alg: skcipher: cbc-des-talitos encryption test failed
"Naveen N. Rao" writes:
> Michael Ellerman wrote:
>> "Naveen N. Rao" writes:
>>> Michael Ellerman wrote:
Nicholas Piggin writes:
> The new mprofile-kernel mcount sequence is
>
> mflrr0
> bl _mcount
>
> Dynamic ftrace patches the branch instruction with
Make sure to include to provide the following prototype:
__find_linux_pte.
Remove the following warning treated as error (W=1):
arch/powerpc/mm/pgtable.c:316:8: error: no previous prototype for
'__find_linux_pte' [-Werror=missing-prototypes]
Fixes: 0caed4de502c ("powerpc/mm: move
In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") the following piece of code was added:
smp_call_function((smp_call_func_t)set_dawr, _brk, 0);
Since GCC 8 this trigger the following warning about incompatible
function types:
On Wed, May 15, 2019 at 11:26:03AM +0200, Christophe Leroy wrote:
> kobject_put() released index_dir->kobj
Yes, but what is that kobject enclosed in?
> but who will release 'index' ?
The final kobject_put() will do that, see cacheinfo_create_index_dir()
for the details.
And please do not
From: Josh Poimboeuf
commit d68be4c4d31295ff6ae34a8ddfaa4c1a8ff42812 upstream.
Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'mitigations=' cmdline option. This affects Meltdown, Spectre v2,
Speculative Store Bypass, and L1TF.
The default behavior is unchanged.
From: Josh Poimboeuf
commit 98af8452945c55652de68536afdde3b520fec429 upstream.
Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users. It's getting more and more
complicated to decide which mitigations are needed for a given
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: eac1e731b59e powerpc/xive: guest exploitation of the XIVE
interrupt controller.
The bot has tested the following trees: v5.1.1, v5.0.15, v4.19.42, v4.14.118.
v5.1.1: Build OK!
This adds testing for the new pidfd_open() syscalls. Specifically, we test:
- that no invalid flags can be passed to pidfd_open()
- that no invalid pid can be passed to pidfd_open()
- that a pidfd can be retrieved with pidfd_open()
- that the retrieved pidfd references the correct pid
This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
process that is created via traditional fork()/clone() calls that is only
referenced by a PID:
int pidfd = pidfd_open(1234, 0);
ret =
The kernel self-tests picked up an issue with CTR mode:
alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector
3, cfg="uneven misaligned splits, may sleep"
Test vector 3 has an IV of FFFD, so
after 3 increments it should wrap around to 0.
In
On 5/15/19 12:05 PM, Greg Kurz wrote:
> On POWER9, if the hypervisor supports XIVE exploitation mode, the guest OS
> will unconditionally requests for the XIVE interrupt mode even if XIVE was
> deactivated with the kernel command line xive=off. Later on, when the spapr
> XIVE init code handles
Hi,
Le 15/05/2019 à 12:09, Christian Zigotzky a écrit :
Hi All,
I got the following error messages with the latest Git kernel today:
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x302a): Section mismatch in
On POWER9, if the hypervisor supports XIVE exploitation mode, the guest OS
will unconditionally requests for the XIVE interrupt mode even if XIVE was
deactivated with the kernel command line xive=off. Later on, when the spapr
XIVE init code handles xive=off, it disables XIVE and tries to fall back
We can call get_region_id without validating the ea value. That means
with a wrong ea value we hit the BUG as below.
kernel BUG at arch/powerpc/include/asm/book3s/64/hash.h:129!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
CPU: 0 PID:
kobject_put() released index_dir->kobj
but who will release 'index' ?
Christophe
Le 15/05/2019 à 11:07, Tobin C. Harding a écrit :
kfree() after kobject_put(). Who ever wrote this was on crack.
Fixes: 7e8039795a80 ("powerpc/cacheinfo: Fix kobject memleak")
Signed-off-by: Tobin C. Harding
kfree() after kobject_put(). Who ever wrote this was on crack.
Fixes: 7e8039795a80 ("powerpc/cacheinfo: Fix kobject memleak")
Signed-off-by: Tobin C. Harding
---
FTR
git log --pretty=format:"%h%x09%an%x09%ad%x09%s" | grep 7e8039795a80
7e8039795a80Tobin C. HardingTue Apr 30
From: Petr Mladek
> Sent: 15 May 2019 08:36
> On Tue 2019-05-14 14:37:51, Steven Rostedt wrote:
> >
> > [ 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:
On Wed, May 15, 2019 at 06:40:47AM +, Christophe Leroy wrote:
> [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
On Wed, May 15, 2019 at 9:36 AM Xiaowei Bao wrote:
> Signed-off-by: Xiaowei Bao
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52
>
> 1 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
>
On Wed 2019-05-15 09:23:05, Geert Uytterhoeven wrote:
> Hi Steve,
>
> On Tue, May 14, 2019 at 9:35 PM Steven Rostedt wrote:
> > 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
From: "Gautham R. Shenoy"
The calls to arch_add_memory()/arch_remove_memory() are always made
with the read-side cpu_hotplug_lock acquired via
memory_hotplug_begin(). On pSeries,
arch_add_memory()/arch_remove_memory() eventually call resize_hpt()
which in turn calls stop_machine() which
Add support for the LS1028a PCIe controller.
Signed-off-by: Xiaowei Bao
---
drivers/pci/controller/dwc/pci-layerscape.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
b/drivers/pci/controller/dwc/pci-layerscape.c
LS1028a implements 2 PCIe 3.0 controllers.
Signed-off-by: Xiaowei Bao
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao
---
.../devicetree/bindings/pci/layerscape-pci.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
On Tue 2019-05-14 14:37:51, Steven Rostedt wrote:
>
> [ 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
Hi Steve,
On Tue, May 14, 2019 at 9:35 PM Steven Rostedt wrote:
> 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
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,
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
> +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.
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
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
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
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
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()
> + * 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
[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
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
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
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
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
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,
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
94 matches
Mail list logo
