Gautham R Shenoy's on May 16, 2019 3:36 pm:
> 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 cp
00
>> IO start = 0xc00a
>> vmemmap start = 0xc00c
>> -----
>>
>> Signed-off-by: Nicholas Piggin
>
> I fear your change defeats most of the purpose of commit
> https:
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 in
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,
>> 18.
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 ibm,pa-featur
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. G
= 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&am
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 optimisation
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, 45.57%@alignmask+18,
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
---
arch/powerpc/platforms/pseries/mobi
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 drc_ind
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
> > > (w
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 g
Radix boot looks like this:
-
phys_mem_size = 0x2
dcache_bsize = 0x80
icache_bsize = 0x80
cpu_features = 0xc06f8f5fb1a7
possible= 0xfbffcf5fb1a7
always = 0x0003800081a1
cpu_user_
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 inclu
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 th
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 si
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)
> return
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 10064
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 3
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 exe
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)
> > + retu
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 +452
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 earl
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
> [3.032673]
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, &null_brk, 0);
Since GCC 8 this triggers the following warning about incompatible
function types:
arch/powerpc/kernel/hw_breakpoint.c
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:
> >
> >smp_call_function((smp_
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 differ
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
b/arch/powerpc/include/as
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 b/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, &null_brk, 0);
>
> Since GCC 8 this trigger the following war
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, patch_inst
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
> referen
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
Sig
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 change
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
- u
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 bee
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
Signed-of
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
---
arch/powerpc/kernel/setup_32.c
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 (wr
"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 a
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 __find_linu
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, &null_brk, 0);
Since GCC 8 this trigger the following warning about incompatible
function types:
arch/powerpc/kernel/hw_breakpoint.c:
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 top-po
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
architectu
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!
v5.
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
Signed-off-b
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 = pidfd_send_si
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 th
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 xive
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 reference
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: 3937
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 11:09:23
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 earl
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
> b/arch
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 would
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 acquires
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
inde
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
b/arch/arm64/boot/dts/freescal
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
b/Documentation/devicetree/bindings/pci/
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 abou
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 strin
80 matches
Mail list logo
