On Sat, 2017-07-08 at 14:59 -0500, Benjamin Herrenschmidt wrote:
> On Thu, 2017-06-29 at 16:54 +1000, Cyril Bur wrote:
> > The OPAL calls performed in this driver shouldn't be using
> > opal_async_wait_response() as this performs a wait_event() which, on
> > long running OPAL calls could result in
Signed-off-by: Cyril Bur
---
drivers/mtd/devices/powernv_flash.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/devices/powernv_flash.c
b/drivers/mtd/devices/powernv_flash.c
index d50b5f200f73..d7243b72ba6e 100644
--- a/drivers/mtd/devices/power
BUG_ON() should be reserved in situations where we can not longer
guarantee the integrity of the system. In the case where
powernv_flash_async_op() receives an impossible op, we can still
guarantee the integrity of the system.
Signed-off-by: Cyril Bur
---
drivers/mtd/devices/powernv_flash.c | 3
Hello,
Version one of this series ignored that OPAL may continue to use
buffers passed to it after Linux kfree()s the buffer. This version
addresses this, not in a particularly nice way - future work could
make this better. This version also includes a few cleanups and fixups
to powernv_flash driv
The OPAL calls performed in this driver shouldn't be using
opal_async_wait_response() as this performs a wait_event() which, on
long running OPAL calls could result in hung task warnings. wait_event()
prevents timely signal delivery which is also undesirable.
This patch also attempts to quieten do
From: Stewart Smith
Parallel sensor reads could run out of async tokens due to
opal_get_sensor_data grabbing tokens but then doing the sensor
read behind a mutex, essentially serializing the (possibly
asynchronous and relatively slow) sensor read.
It turns out that the mutex isn't needed at all,
There are no callers of both __opal_async_get_token() and
__opal_async_release_token().
This patch also removes the possibility of "emergency through
synchronous call to __opal_async_get_token()" as such it makes more
sense to initialise opal_sync_sem for the maximum number of async
tokens.
Signe
Signed-off-by: Cyril Bur
---
arch/powerpc/platforms/powernv/opal.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 59684b4af4d1..f87e000e7c28 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powe
This patch adds an _interruptible version of opal_async_wait_response().
This is useful when a long running OPAL call is performed on behalf of a
userspace thread, for example, the opal_flash_{read,write,erase}
functions performed by the powernv-flash MTD driver.
It is foreseeable that these funct
Future work will add an opal_async_wait_response_interruptible()
which will call wait_event_interruptible(). This work requires extra
token state to be tracked as wait_event_interruptible() can return and
the caller could release the token before OPAL responds.
Currently token state is tracked wit
While this driver expects to interact asynchronously, OPAL is well
within its rights to return OPAL_SUCCESS to indicate that the operation
completed without the need for a callback. We shouldn't treat
OPAL_SUCCESS as an error rather we should wrap up and return promptly to
the caller.
Signed-off-b
OPAL can only manage one flash access at a time and will return an
OPAL_BUSY error for each concurrent access to the flash. The simplest
way to prevent this from happening is with a mutex.
Signed-off-by: Cyril Bur
---
drivers/mtd/devices/powernv_flash.c | 18 +++---
1 file changed, 1
Hi Al,
After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:612:18: error: 'struct dentry' has no
member named 'i_uid'
if (!uid_eq(
On Mon, Jul 10, 2017 at 12:15:11PM +1000, Stephen Rothwell wrote:
> Hi Al,
> Caused by commit
>
> 4f9365d9e2e7 ("spufs: Implement show_options")
Obvious incremental follows, will fold and push
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c
b/arch/powerpc/platforms/cell/spufs/inode.c
On 07/06/2017 02:52 AM, Ram Pai wrote:
> Add documentation updates that capture PowerPC specific changes.
>
> Signed-off-by: Ram Pai
> ---
> Documentation/vm/protection-keys.txt | 85
> ++
> 1 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/D
On 07/06/2017 02:52 AM, Ram Pai wrote:
> Display the pkey number associated with the vma in smaps of a task.
> The key will be seen as below:
>
> ProtectionKey: 0
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/kernel/setup_64.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-
On 07/06/2017 02:52 AM, Ram Pai wrote:
> The value of the AMR register at the time of exception
> is made available in gp_regs[PT_AMR] of the siginfo.
>
> The value of the pkey, whose protection got violated,
> is made available in si_pkey field of the siginfo structure.
>
> Signed-off-by: Ram Pa
On 07/06/2017 02:52 AM, Ram Pai wrote:
> Capture the protection key that got violated in paca.
> This value will be used by used to inform the signal
> handler.
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/paca.h |1 +
> arch/powerpc/kernel/asm-offsets.c |1 +
> arch/pow
On 07/06/2017 02:52 AM, Ram Pai wrote:
> get_pte_pkey() helper returns the pkey associated with
> a address corresponding to a given mm_struct.
>
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/book3s/64/mmu-hash.h |5
> arch/powerpc/mm/hash_utils_64.c | 28
>
Benjamin Herrenschmidt writes:
> On radix, the process table entry we want to clear when
> destroying a context is entry 0, not entry 1
.. but has no real world consequence? Or causes the system to instantly
catch fire?
I'll tag it:
Fixes: 7e381c0ff618 ("powerpc/mm/radix: Add mmu context hand
On Mon, 2017-07-10 at 13:51 +1000, Michael Ellerman wrote:
> Benjamin Herrenschmidt writes:
>
> > On radix, the process table entry we want to clear when
> > destroying a context is entry 0, not entry 1
>
> .. but has no real world consequence? Or causes the system to instantly
> catch fire?
It
Simplify return logic to avoid unnecessary variable assignment.
This issue was detected using Coccinelle and the following
semantic patch:
@@
local idexpression ret;
expression e;
@@
-ret =
+return
e;
-return ret;
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/gadget/udc/fsl_udc_core
On Sat, 08 Jul 2017 07:45:32 -0500
Benjamin Herrenschmidt wrote:
> On radix, the process table entry we want to clear when
> destroying a context is entry 0, not entry 1
>
> Signed-off-by: Benjamin Herrenschmidt
This looks obviously correct to me.
Nicholas Piggin writes:
> On Fri, 7 Jul 2017 20:34:16 +0530
> Gautham R Shenoy wrote:
>> On Fri, Jul 07, 2017 at 01:16:09AM +1000, Nicholas Piggin wrote:
>> >
>> > Speaking of which... core_idle_state and thread_sibling_pacas are
>> > allocated with kmalloc_node... What happens if we take an SLB
On Fri, 07 Jul 2017 16:12:16 -0500
Benjamin Herrenschmidt wrote:
> When writing to the process table, we need to ensure the store is
> visible to a subsequent access by the MMU. We assume we never have
> the PID active while doing the update, so a ptesync/isync pair
> should hopefully be a big en
Benjamin Herrenschmidt writes:
> On radix, the process table entry we want to clear when
> destroying a context is entry 0, not entry 1
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Aneesh Kumar K.V
> ---
> arch/powerpc/mm/mmu_context_book3s64.c | 12 +---
> 1 file changed,
Peter Zijlstra writes:
> PPC folks, maddy, does this work for you guys?
It think it works for us, but I have some comments, I'll reply to the original.
cheers
> On Thu, Apr 20, 2017 at 08:07:49PM +0800, Jin Yao wrote:
>> It is often useful to know the branch types while analyzing branch
>> dat
On 07/06/2017 02:51 AM, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.
>
> The overall idea:
>
> A process allocates a key and associates it with
> an address range withinits address s
On 07/06/2017 11:26 PM, Nicholas Piggin wrote:
> On Wed, 5 Jul 2017 14:04:19 +1000
> Nicholas Piggin wrote:
>
>> Unrecovered MCE and HMI errors are sent through a special restart
>> OPAL call to log the platform error. The downside is that they don't
>> go through normal crash paths, so they don
On Mon, Jul 10, 2017 at 08:40:19AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > Capture the protection key that got violated in paca.
> > This value will be used by used to inform the signal
> > handler.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/incl
On Mon, Jul 10, 2017 at 08:41:30AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > get_pte_pkey() helper returns the pkey associated with
> > a address corresponding to a given mm_struct.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/include/asm/book3s/64/m
On Mon, Jul 10, 2017 at 08:37:04AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > Add documentation updates that capture PowerPC specific changes.
> >
> > Signed-off-by: Ram Pai
> > ---
> > Documentation/vm/protection-keys.txt | 85
> > ++-
On Mon, Jul 10, 2017 at 08:37:28AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > Display the pkey number associated with the vma in smaps of a task.
> > The key will be seen as below:
> >
> > ProtectionKey: 0
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc
Hi Jin Yao,
Sorry I haven't commented until now, but it got lost in the flood of
patches.
Just a few nit-picks below ...
Jin Yao writes:
> It is often useful to know the branch types while analyzing branch
> data. For example, a call is very different from a conditional branch.
>
> Currently w
On Mon, Jul 10, 2017 at 11:13:23AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:51 AM, Ram Pai wrote:
> > Memory protection keys enable applications to protect its
> > address space from inadvertent access or corruption from
> > itself.
> >
> > The overall idea:
> >
> > A process allocates
POWER9 DD2 can see spurious PMU interrupts after state-loss idle in
some conditions.
A solution is to save and reload MMCR0 over state-loss idle.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/idle_book3s.S | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --gi
On Mon, 2017-07-10 at 14:40 +1000, Nicholas Piggin wrote:
> On Fri, 07 Jul 2017 16:12:16 -0500
> Benjamin Herrenschmidt wrote:
>
> > When writing to the process table, we need to ensure the store is
> > visible to a subsequent access by the MMU. We assume we never have
> > the PID active while do
37 matches
Mail list logo
