Re: [PATCH 02/79] spufs: switch to new ctime accessors

[Jeremy Kerr]

Hi Jeff,

> In later patches, we're going to change how the ctime.tv_nsec field is
> utilized. Switch to using accessor functions instead of raw accesses
> of inode->i_ctime.

s/utilized/used/ :D

All looks good on the spufs change:

Acked-by: Jeremy Kerr 

(also, thanks for including the accessors patch on the wider list, made
it much easier to review in context)

Cheers,


Jeremy

Re: [PATCH] Documentation: spufs: correct a duplicate word typo

[Jeremy Kerr]

Hi Randy,

> Fix a typo of "or" which should be "of".

Nice, people are still reading the spufs docs! :D

Looks good to me, thanks for the patch.

Reviewed-by: Jeremy Kerr 

Cheers,


Jeremy

Re: [PATCH 6/6] i2c: Make remove callback return void

[Jeremy Kerr]

 Nicolas Ferre 
, Robert Foss , Krzysztof 
Kozlowski , Daniel Vetter , 
Alvin =?UTF-8?Q?Šipraga?= , Luca Ceresoli 
, =?ISO-8859-1?Q?Jos�_Exp�sito?= 
, Johannes Berg , Colin 
Ian King , Maximilian Luz , Helge Deller , Lucas Stach 
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


Hi Uwe,

Looks good - just one minor change for the mctp-i2c driver, but only
worthwhile if you end up re-rolling this series for other reasons:

> -static int mctp_i2c_remove(struct i2c_client *client)
> +static void mctp_i2c_remove(struct i2c_client *client)
>  {
> struct mctp_i2c_client *mcli = i2c_get_clientdata(client);
> struct mctp_i2c_dev *midev = NULL, *tmp = NULL;
> @@ -1000,7 +1000,6 @@ static int mctp_i2c_remove(struct i2c_client *client)
> mctp_i2c_free_client(mcli);
> mutex_unlock(_clients_lock);
> /* Callers ignore return code */
> -   return 0;
>  }

The comment there no longer makes much sense, I'd suggest removing that
too. Either way:

Reviewed-by: Jeremy Kerr 

Cheers,


Jeremy

Re: [PATCH v2] sched: Use BUG_ON

[Jeremy Kerr]

Hi Jason,

> The BUG_ON macro simplifies the if condition followed by BUG, so that
> we can use BUG_ON instead of if condition followed by BUG.

[...]

> -   if (spu_acquire(ctx))
> -   BUG();  /* a kernel thread never has signals pending */
> +   /* a kernel thread never has signals pending */
> +   BUG_ON(spu_acquire(ctx));

I'm not convinced that this is an improvement; you've combined the
acquire and the BUG into a single statement, and now it's no longer
clear what the comment applies to.

If you really wanted to use BUG_ON, something like this would be more
clear:

rc = spu_acquire(ctx);
/* a kernel thread never has signals pending */
BUG_ON(rc);

but we don't have a suitable rc variable handy, so we'd need one of
those declared too. You could avoid that with:

if (spu_acquire(ctx))
BUG_ON(1); /* a kernel thread never has signals pending */

but wait: no need for the constant there, so this would be better:

if (spu_acquire(ctx))
BUG(); /* a kernel thread never has signals pending */

wait, what are we doing again?

To me, this is a bit of shuffling code around, for no real benefit.

Regards,


Jeremy

Re: [PATCH] powerpc/spufs: add CONFIG_COREDUMP dependency

[Jeremy Kerr]

Hi Arnd,

> The kernel test robot pointed out a slightly different error message
> after recent commit 5456ffdee666 ("powerpc/spufs: simplify spufs core
> dumping") to spufs for a configuration that never worked:
> 
>powerpc64-linux-ld: arch/powerpc/platforms/cell/spufs/file.o: in
> function `.spufs_proxydma_info_dump':
> > > file.c:(.text+0x4c68): undefined reference to `.dump_emit'
>powerpc64-linux-ld: arch/powerpc/platforms/cell/spufs/file.o: in
> function `.spufs_dma_info_dump':
>file.c:(.text+0x4d70): undefined reference to `.dump_emit'
>powerpc64-linux-ld: arch/powerpc/platforms/cell/spufs/file.o: in
> function `.spufs_wbox_info_dump':
>file.c:(.text+0x4df4): undefined reference to `.dump_emit'
> 
> Add a Kconfig dependency to prevent this from happening again.
> 
> Reported-by: kernel test robot 
> Signed-off-by: Arnd Bergmann 

Looks good to me, thanks.

Acked-by: Jeremy Kerr 

Cheers,


Jeremy

Re: [PATCH] powerpc/spufs: adjust list element pointer type

[Jeremy Kerr]

Hi Julia,

> Other uses of >aff_list_head, eg in spufs_assert_affinity, indicate
> that the list elements have type spu_context, not spu as used here.  Change
> the type of tmp accordingly.

Looks good to me; we could even use ctx there, rather than the separate
tmp variable.

Reviewed-by: Jeremy Kerr 

Cheers,


Jeremy

Re: [PATCH 2/2] powerpc/spufs: stop using access_ok

[Jeremy Kerr]

Hi Christophe,

> > Just use the proper non __-prefixed get/put_user variants where
> > that is not done yet.
> 
> But it means you are doing the access_ok() check everytime, which is 
> what is to be avoided by doing the access_ok() once then using the 
> __-prefixed variant.

5 out of 8 of these are just a access_ok(); simple_read_from_buffer().

For the cases where it's multiple __put/get_user()s, the max will be 5.
(for the mbox access). Is that worth optimising the access_ok() checks?

Cheers,


Jeremy

[PATCH 1/2] powerpc/spufs: fix copy_to_user while atomic

[Jeremy Kerr]

Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.

This change uses a temporary buffer for the context save area data,
which we then pass to simple_read_from_buffer.

Includes changes from Christoph Hellwig .

Fixes: bf1ab978be23 ("[POWERPC] coredump: Add SPU elf notes to coredump.")
Signed-off-by: Jeremy Kerr 
Reviewed-by: Arnd Bergmann 
Reviewed-by: Christoph Hellwig 
---
 arch/powerpc/platforms/cell/spufs/file.c | 113 +++
 1 file changed, 75 insertions(+), 38 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index c0f950a3f4e1..b4e1ef650b40 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1978,8 +1978,9 @@ static ssize_t __spufs_mbox_info_read(struct spu_context 
*ctx,
 static ssize_t spufs_mbox_info_read(struct file *file, char __user *buf,
   size_t len, loff_t *pos)
 {
-   int ret;
struct spu_context *ctx = file->private_data;
+   u32 stat, data;
+   int ret;
 
if (!access_ok(buf, len))
return -EFAULT;
@@ -1988,11 +1989,16 @@ static ssize_t spufs_mbox_info_read(struct file *file, 
char __user *buf,
if (ret)
return ret;
spin_lock(>csa.register_lock);
-   ret = __spufs_mbox_info_read(ctx, buf, len, pos);
+   stat = ctx->csa.prob.mb_stat_R;
+   data = ctx->csa.prob.pu_mb_R;
spin_unlock(>csa.register_lock);
spu_release_saved(ctx);
 
-   return ret;
+   /* EOF if there's no entry in the mbox */
+   if (!(stat & 0xff))
+   return 0;
+
+   return simple_read_from_buffer(buf, len, pos, , sizeof(data));
 }
 
 static const struct file_operations spufs_mbox_info_fops = {
@@ -2019,6 +2025,7 @@ static ssize_t spufs_ibox_info_read(struct file *file, 
char __user *buf,
   size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
+   u32 stat, data;
int ret;
 
if (!access_ok(buf, len))
@@ -2028,11 +2035,16 @@ static ssize_t spufs_ibox_info_read(struct file *file, 
char __user *buf,
if (ret)
return ret;
spin_lock(>csa.register_lock);
-   ret = __spufs_ibox_info_read(ctx, buf, len, pos);
+   stat = ctx->csa.prob.mb_stat_R;
+   data = ctx->csa.priv2.puint_mb_R;
spin_unlock(>csa.register_lock);
spu_release_saved(ctx);
 
-   return ret;
+   /* EOF if there's no entry in the ibox */
+   if (!(stat & 0xff))
+   return 0;
+
+   return simple_read_from_buffer(buf, len, pos, , sizeof(data));
 }
 
 static const struct file_operations spufs_ibox_info_fops = {
@@ -2041,6 +2053,11 @@ static const struct file_operations spufs_ibox_info_fops 
= {
.llseek  = generic_file_llseek,
 };
 
+static size_t spufs_wbox_info_cnt(struct spu_context *ctx)
+{
+   return (4 - ((ctx->csa.prob.mb_stat_R & 0x00ff00) >> 8)) * sizeof(u32);
+}
+
 static ssize_t __spufs_wbox_info_read(struct spu_context *ctx,
char __user *buf, size_t len, loff_t *pos)
 {
@@ -2049,7 +2066,7 @@ static ssize_t __spufs_wbox_info_read(struct spu_context 
*ctx,
u32 wbox_stat;
 
wbox_stat = ctx->csa.prob.mb_stat_R;
-   cnt = 4 - ((wbox_stat & 0x00ff00) >> 8);
+   cnt = spufs_wbox_info_cnt(ctx);
for (i = 0; i < cnt; i++) {
data[i] = ctx->csa.spu_mailbox_data[i];
}
@@ -2062,7 +2079,8 @@ static ssize_t spufs_wbox_info_read(struct file *file, 
char __user *buf,
   size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
-   int ret;
+   u32 data[ARRAY_SIZE(ctx->csa.spu_mailbox_data)];
+   int ret, count;
 
if (!access_ok(buf, len))
return -EFAULT;
@@ -2071,11 +2089,13 @@ static ssize_t spufs_wbox_info_read(struct file *file, 
char __user *buf,
if (ret)
return ret;
spin_lock(>csa.register_lock);
-   ret = __spufs_wbox_info_read(ctx, buf, len, pos);
+   count = spufs_wbox_info_cnt(ctx);
+   memcpy(, >csa.spu_mailbox_data, sizeof(data));
spin_unlock(>csa.register_lock);
spu_release_saved(ctx);
 
-   return ret;
+   return simple_read_from_buffer(buf, len, pos, ,
+   count * sizeof(u32));
 }
 
 static const struct file_operations spufs_wbox_info_fops = {
@@ -2084,27 +2104,33 @@ static const struct file_operations 
spufs_wbox_info_fops = {
.llseek  = generic_file_llseek,
 };
 
-static ssize_t __spufs_dma_info_read(struct spu_context *ctx,
-   char __user *buf, size_t len, loff_t *pos)
+static void ___spufs_dma_

[PATCH 2/2] powerpc/spufs: stop using access_ok

[Jeremy Kerr]

From: Christoph Hellwig 

Just use the proper non __-prefixed get/put_user variants where that is
not done yet.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jeremy Kerr 
---
 arch/powerpc/platforms/cell/spufs/file.c | 42 +---
 1 file changed, 8 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index b4e1ef650b40..cd7d10f27fad 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -590,17 +590,12 @@ static ssize_t spufs_mbox_read(struct file *file, char 
__user *buf,
size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
-   u32 mbox_data, __user *udata;
+   u32 mbox_data, __user *udata = (void __user *)buf;
ssize_t count;
 
if (len < 4)
return -EINVAL;
 
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
-   udata = (void __user *)buf;
-
count = spu_acquire(ctx);
if (count)
return count;
@@ -616,7 +611,7 @@ static ssize_t spufs_mbox_read(struct file *file, char 
__user *buf,
 * but still need to return the data we have
 * read successfully so far.
 */
-   ret = __put_user(mbox_data, udata);
+   ret = put_user(mbox_data, udata);
if (ret) {
if (!count)
count = -EFAULT;
@@ -698,17 +693,12 @@ static ssize_t spufs_ibox_read(struct file *file, char 
__user *buf,
size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
-   u32 ibox_data, __user *udata;
+   u32 ibox_data, __user *udata = (void __user *)buf;
ssize_t count;
 
if (len < 4)
return -EINVAL;
 
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
-   udata = (void __user *)buf;
-
count = spu_acquire(ctx);
if (count)
goto out;
@@ -727,7 +717,7 @@ static ssize_t spufs_ibox_read(struct file *file, char 
__user *buf,
}
 
/* if we can't write at all, return -EFAULT */
-   count = __put_user(ibox_data, udata);
+   count = put_user(ibox_data, udata);
if (count)
goto out_unlock;
 
@@ -741,7 +731,7 @@ static ssize_t spufs_ibox_read(struct file *file, char 
__user *buf,
 * but still need to return the data we have
 * read successfully so far.
 */
-   ret = __put_user(ibox_data, udata);
+   ret = put_user(ibox_data, udata);
if (ret)
break;
}
@@ -836,17 +826,13 @@ static ssize_t spufs_wbox_write(struct file *file, const 
char __user *buf,
size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
-   u32 wbox_data, __user *udata;
+   u32 wbox_data, __user *udata = (void __user *)buf;
ssize_t count;
 
if (len < 4)
return -EINVAL;
 
-   udata = (void __user *)buf;
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
-   if (__get_user(wbox_data, udata))
+   if (get_user(wbox_data, udata))
return -EFAULT;
 
count = spu_acquire(ctx);
@@ -873,7 +859,7 @@ static ssize_t spufs_wbox_write(struct file *file, const 
char __user *buf,
/* write as much as possible */
for (count = 4, udata++; (count + 4) <= len; count += 4, udata++) {
int ret;
-   ret = __get_user(wbox_data, udata);
+   ret = get_user(wbox_data, udata);
if (ret)
break;
 
@@ -1982,9 +1968,6 @@ static ssize_t spufs_mbox_info_read(struct file *file, 
char __user *buf,
u32 stat, data;
int ret;
 
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
ret = spu_acquire_saved(ctx);
if (ret)
return ret;
@@ -2028,9 +2011,6 @@ static ssize_t spufs_ibox_info_read(struct file *file, 
char __user *buf,
u32 stat, data;
int ret;
 
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
ret = spu_acquire_saved(ctx);
if (ret)
return ret;
@@ -2082,9 +2062,6 @@ static ssize_t spufs_wbox_info_read(struct file *file, 
char __user *buf,
u32 data[ARRAY_SIZE(ctx->csa.spu_mailbox_data)];
int ret, count;
 
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
ret = spu_acquire_saved(ctx);
if (ret)
return ret;
@@ -2143,9 +2120,6 @@ static ssize_t spufs_dma_info_read(struct file *file, 
char __user *buf,
struct spu_dma_info info;
int ret;
 
-   if (!access_ok(buf, len))
-   return -EFAULT;
-
ret = spu_acquire_sav

Re: [RFC PATCH] powerpc/spufs: fix copy_to_user while atomic

[Jeremy Kerr]

Hi Christoph,

> And another one that should go on top of this one to address Al's other
> compaint:

Yeah, I was pondering that one. The access_ok() is kinda redundant, but
it does avoid forcing a SPU context save on those errors.

However, it's not like we really need to optimise for the case of
invalid addresses from userspace. So, I'll include this change in the
submission to Michael's tree. Arnd - let me know if you have any
objections.

Cheers,


Jeremy

Re: [RFC PATCH] powerpc/spufs: fix copy_to_user while atomic

[Jeremy Kerr]

Hi Christoph,

> FYI, these little hunks reduce the difference to my version, maybe
> you can fold them in?

Sure, no problem.

How do you want to coordinate these? I can submit mine through mpe, but
that may make it tricky to synchronise with your changes. Or, you can
include this change in your series if you prefer.

Cheers,


Jeremy

[RFC PATCH] powerpc/spufs: fix copy_to_user while atomic

[Jeremy Kerr]

Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.

This change uses a temporary buffers for the context save area data,
which we then pass to simple_read_from_buffer.

Signed-off-by: Jeremy Kerr 
---

Christoph - this fixes the copy_to_user while atomic, hopefully with
only minimal distruption to your series.

---
 arch/powerpc/platforms/cell/spufs/file.c | 110 +++
 1 file changed, 74 insertions(+), 36 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index c0f950a3f4e1..c62d77ddaf7d 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1978,8 +1978,9 @@ static ssize_t __spufs_mbox_info_read(struct spu_context 
*ctx,
 static ssize_t spufs_mbox_info_read(struct file *file, char __user *buf,
   size_t len, loff_t *pos)
 {
-   int ret;
struct spu_context *ctx = file->private_data;
+   u32 stat, data;
+   int ret;
 
if (!access_ok(buf, len))
return -EFAULT;
@@ -1988,11 +1989,16 @@ static ssize_t spufs_mbox_info_read(struct file *file, 
char __user *buf,
if (ret)
return ret;
spin_lock(>csa.register_lock);
-   ret = __spufs_mbox_info_read(ctx, buf, len, pos);
+   stat = ctx->csa.prob.mb_stat_R;
+   data = ctx->csa.prob.pu_mb_R;
spin_unlock(>csa.register_lock);
spu_release_saved(ctx);
 
-   return ret;
+   /* EOF if there's no entry in the mbox */
+   if (!(stat & 0xff))
+   return 0;
+
+   return simple_read_from_buffer(buf, len, pos, , sizeof(data));
 }
 
 static const struct file_operations spufs_mbox_info_fops = {
@@ -2019,6 +2025,7 @@ static ssize_t spufs_ibox_info_read(struct file *file, 
char __user *buf,
   size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
+   u32 stat, data;
int ret;
 
if (!access_ok(buf, len))
@@ -2028,11 +2035,16 @@ static ssize_t spufs_ibox_info_read(struct file *file, 
char __user *buf,
if (ret)
return ret;
spin_lock(>csa.register_lock);
-   ret = __spufs_ibox_info_read(ctx, buf, len, pos);
+   stat = ctx->csa.prob.mb_stat_R;
+   data = ctx->csa.priv2.puint_mb_R;
spin_unlock(>csa.register_lock);
spu_release_saved(ctx);
 
-   return ret;
+   /* EOF if there's no entry in the ibox */
+   if (!(stat & 0xff))
+   return 0;
+
+   return simple_read_from_buffer(buf, len, pos, , sizeof(data));
 }
 
 static const struct file_operations spufs_ibox_info_fops = {
@@ -2041,6 +2053,11 @@ static const struct file_operations spufs_ibox_info_fops 
= {
.llseek  = generic_file_llseek,
 };
 
+static size_t spufs_wbox_info_cnt(struct spu_context *ctx)
+{
+   return (4 - ((ctx->csa.prob.mb_stat_R & 0x00ff00) >> 8)) * sizeof(u32);
+}
+
 static ssize_t __spufs_wbox_info_read(struct spu_context *ctx,
char __user *buf, size_t len, loff_t *pos)
 {
@@ -2049,7 +2066,7 @@ static ssize_t __spufs_wbox_info_read(struct spu_context 
*ctx,
u32 wbox_stat;
 
wbox_stat = ctx->csa.prob.mb_stat_R;
-   cnt = 4 - ((wbox_stat & 0x00ff00) >> 8);
+   cnt = spufs_wbox_info_cnt(ctx);
for (i = 0; i < cnt; i++) {
data[i] = ctx->csa.spu_mailbox_data[i];
}
@@ -2062,7 +2079,8 @@ static ssize_t spufs_wbox_info_read(struct file *file, 
char __user *buf,
   size_t len, loff_t *pos)
 {
struct spu_context *ctx = file->private_data;
-   int ret;
+   u32 data[ARRAY_SIZE(ctx->csa.spu_mailbox_data)];
+   int ret, count;
 
if (!access_ok(buf, len))
return -EFAULT;
@@ -2071,11 +2089,13 @@ static ssize_t spufs_wbox_info_read(struct file *file, 
char __user *buf,
if (ret)
return ret;
spin_lock(>csa.register_lock);
-   ret = __spufs_wbox_info_read(ctx, buf, len, pos);
+   count = spufs_wbox_info_cnt(ctx);
+   memcpy(, >csa.spu_mailbox_data, sizeof(data));
spin_unlock(>csa.register_lock);
spu_release_saved(ctx);
 
-   return ret;
+   return simple_read_from_buffer(buf, len, pos, ,
+   count * sizeof(u32));
 }
 
 static const struct file_operations spufs_wbox_info_fops = {
@@ -2084,20 +2104,19 @@ static const struct file_operations 
spufs_wbox_info_fops = {
.llseek  = generic_file_llseek,
 };
 
-static ssize_t __spufs_dma_info_read(struct spu_context *ctx,
-   char __user *buf, size_t len, loff_t *pos)
+static void ___spufs_dma_info_read(struct spu_context *ctx,
+   struct spu_dma_info *info)
 

Re: [PATCH 1/5] powerpc/spufs: simplify spufs core dumping

[Jeremy Kerr]

Hi Al & Christoph,

> Again, this really needs fixing.  Preferably - as a separate commit
> preceding this series, so that it could be
> backported.  simple_read_from_buffer() is a blocking operation.

I'll put together a patch that fixes this.

Christoph: I'll do it in a way that matches your changes to the _read
functions, so hopefully those hunks would just drop from your change,
leaving only the _dump additions. Would that work?

Cheers,


Jeremy

Re: [PATCH 1/6] powerpc/spufs: simplify spufs core dumping

[Jeremy Kerr]

Hi Christoph,

> Replace the coredump ->read method with a ->dump method that must call
> dump_emit itself.  That way we avoid a buffer allocation an messing with
> set_fs() to call into code that is intended to deal with user buffers.
> For the ->get case we can now use a small on-stack buffer and avoid
> memory allocations as well.

That looks much better, thanks!

Reviewed-by: Jeremy Kerr 

However, I no longer have access to hardware to test this on. Michael,
are the coredump tests in spufs-testsuite still alive?

Cheers,


Jeremy

Re: [PATCH] powerpc/powernv/prd: Validate whether address to be mapped is part of system RAM

[Jeremy Kerr]

Hi Vaidy,


The current topic is who owns setting up the ATT bits for that piece
of memory.  It is the kernel today.  Kernel decides to set this up as
normal memory or I/O memory and sets the bits in page table entry.


Or, what if there's a range of address-space that isn't backed by system
RAM (say, some MMIO-mapped hardware) that we want to expose to a future
HBRT implementation? This change will block that.

The kernel doesn't know what is and is not valid for a HBRT mapping, so
it has no reason to override what's specified in the device tree. We've
designed this so that the kernel provides the mechanism for mapping
pages, and not the policy of which pages can be mapped.


The features altered are cache inhibit and guarding which affects
ability to fetch instructions.  If we allow HBRT to reside in an I/O
memory, the we need to tell kernel that it is ok to allow caching and
instruction execution in that region and accordingly change the ATT
bits.


But this isn't only about the HBRT range itself (ie., the memory 
containing the HBRT binary). Everything that HBRT needs to map will come 
through this path. We may not need to fetch instructions from those ranges.



This patch does not block a working function, but actually makes
debugging a failed case easier.  The failing scenario without this
check is such that HBRT cannot fetch from the region of memory and
loops in minor page faults doing nothing.


Yep, that's not great, but the alternative means applying this kernel 
policy, which we can't guarantee is correct.


That is, unless the page protection bits mean that this won't work 
anyway, but we can probably fix that without a kernel policy, by 
applying the appropriate pgprot_t, perhaps.



As Vasant mentioned hostboot team will add code to relocate the HBRT
to the right place.  Addressing your concern, if we end up allowing
HBRT in non system-RAM area


Not just HBRT, but anything that HBRT maps too.


we need to add some more flags in device
tree to instruct the driver to force change the page protection bits
as page_prot = pgprot_cached(page_prot);


Doesn't phys_mem_access_prot() handle that for us? Or do I have my 
_noncached/_cached logic inverted?


Cheers,


Jeremy

Re: [PATCH] powerpc/powernv/prd: Validate whether address to be mapped is part of system RAM

[Jeremy Kerr]

Hi Vasant,

> > OK. How about we just don't do that?
> 
> Yes. Hostboot will fix that. It will make sure that HBRT is loaded
> into regular memory.

Super.

> > It sounds like we're just trying to work around an invalid
> > representation of the mappings.
> 
> Its not workaround. Its additional check.

The issue is that you've added a check for stuff that the kernel doesn't
(and shouldn't) know about, and assumed that the kernel knows better
than the device tree. It may be the correct thing to do in this case,
but we can't guarantee that it's always correct.

For example, what if there is a future HBRT range that is fine to go
into NVRAM? With this change, that's not possible.

Or, what if there's a range of address-space that isn't backed by system
RAM (say, some MMIO-mapped hardware) that we want to expose to a future
HBRT implementation? This change will block that.

The kernel doesn't know what is and is not valid for a HBRT mapping, so
it has no reason to override what's specified in the device tree. We've
designed this so that the kernel provides the mechanism for mapping
pages, and not the policy of which pages can be mapped.

Regards,


Jeremy

Re: [PATCH] powerpc/powernv/prd: Validate whether address to be mapped is part of system RAM

[Jeremy Kerr]

Hi Vasant,

> Correct. We will have `ibm,prd-label` property. That's not the issue. 

It sure sounds like the issue - someone has represented a range that
should be mapped by HBRT, but isn't appropriate for mapping by HBRT.

> Here issueis HBRT is loaded into NVDIMM memory.

OK. How about we just don't do that?

It sounds like we're just trying to work around an invalid
representation of the mappings.

Cheers,


Jeremy

Re: [PATCH] powerpc/powernv/prd: Validate whether address to be mapped is part of system RAM

[Jeremy Kerr]

Hi Vasant,

> Add check to validate whether requested page is part of system RAM
> or not before mmap() and error out if its not part of system RAM.

opal_prd_range_is_valid() will return false if the reserved memory range
does not have an ibm,prd-label property. If this you're getting invalid
memory mapped through the PRD interface, that means the device tree is
incorrectly describing those ranges.

Or am I missing something?

Cheers,


Jeremy

Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES

[Jeremy Kerr]

Hi Jon,


Signed-off-by: Colin Ian King 
---
  Documentation/filesystems/spufs.txt | 2 +-
  Documentation/gpu/drm-uapi.rst  | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)


Applied, thanks.

This is the first patch to spufs.txt since 2006...I wonder if that stuff
is being used by anybody...


Anyone who is using the vector processors on the Cell BE processors will
be using it. However, that hardware is becoming pretty rare now.

We'll want to remove the spufs bits if/when we drop support for the cell
platforms (IBM QSxx, PS3, celleb). mpe: any ides on that? Do you have a 
policy for dropping platform support?


Cheers,


Jeremy

Re: [PATCH] ipmi/powernv: Fix spurious warnings at boot

[Jeremy Kerr]

Hi William,


Sometimes we have stale messages showing up in the recv queue that are
being processed by the pollers. We don't want to print out warnings for
these messages not having an outstanding request as they can be expected
when doing a kexec from the petitroot environment or from another
running kernel.


OK, makes sense to do. The in_drain state partially shadows the value of
!smi->cur_msg; we may be able to use that instead.

This means that we'll no longer warn when getting an IPMI message after
the first successful send occurs, but do we really care about that
anyway? We could just drop those silently...

Cheers,


Jeremy

Re: [PATCH] [RESEND] spufs: use timespec64 for timestamps

[Jeremy Kerr]

Hi Arnd,

> The switch log prints the tv_sec portion of timespec as a 32-bit
> number, while overflows in 2106. It also uses the timespec type,
> which is safe on 64-bit architectures, but deprecated because
> it causes overflows in 2038 elsewhere.
> 
> This changes it to timespec64 and printing a 64-bit number for
> consistency.

If we still have spufs in the tree in 2038 I'd be worried :) But good
to keep things consistent.

Acked-by: Jeremy Kerr <j...@ozlabs.org>

Michael: want to take this directly through your tree?

Cheers,


Jeremy

[PATCH] powerpc: Fix action argument for cpufeatures-based TLB flush

[Jeremy Kerr]

Commit 41d0c2ecde introduced calls to __flush_tlb_power[89] from the
cpufeatures code, specifying the number of sets to flush.

However, these functions take an action argument, not a number of sets.
This means we hit the BUG() in __flush_tlb_{206,300} when using
cpufeatures-style configuration.

This change passes TLB_INVAL_SCOPE_GLOBAL instead.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
CC: Nicholas Piggin <npig...@gmail.com>
---
 arch/powerpc/kernel/dt_cpu_ftrs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1df770e..7275fed 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -102,10 +102,10 @@ static void cpufeatures_flush_tlb(void)
case PVR_POWER8:
case PVR_POWER8E:
case PVR_POWER8NVL:
-   __flush_tlb_power8(POWER8_TLB_SETS);
+   __flush_tlb_power8(TLB_INVAL_SCOPE_GLOBAL);
break;
case PVR_POWER9:
-   __flush_tlb_power9(POWER9_TLB_SETS_HASH);
+   __flush_tlb_power9(TLB_INVAL_SCOPE_GLOBAL);
break;
default:
pr_err("unknown CPU version for boot TLB flush\n");
-- 
2.7.4

Re: [PATCH] powerpc/spufs: Fix coredump of SPU contexts

[Jeremy Kerr]

Hi Michael,

> So fix it by setting rc = 0 before returning in the success case.
> 
> Fixes: 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers")
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>

Looks good to me, thanks.

Acked-by: Jeremy Kerr <j...@ozlabs.org>

Cheers,


Jeremy

[PATCH] powerpc/spufs: Fix hash faults for kernel regions

[Jeremy Kerr]

Change ac29c64089b7 swapped _PAGE_USER for _PAGE_PRIVILEGED, and
introduced check_pte_access() which denied kernel access to
non-_PAGE_PRIVILEGED pages.

However, it didn't add _PAGE_PRIVILEGED to the hash fault handler for
spufs' kernel accesses, so the DMAs required to establish SPE memory
no longer work.

This change adds _PAGE_PRIVILEGED to the hash fault handler for
kernel accesses.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
Reported-by: Sombat Tragolgosol <sombat3...@gmail.com>
CC: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com>
---
 arch/powerpc/platforms/cell/spu_base.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spu_base.c 
b/arch/powerpc/platforms/cell/spu_base.c
index 96c2b8a..0c45cdb 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -197,7 +197,9 @@ static int __spu_trap_data_map(struct spu *spu, unsigned 
long ea, u64 dsisr)
(REGION_ID(ea) != USER_REGION_ID)) {
 
spin_unlock(>register_lock);
-   ret = hash_page(ea, _PAGE_PRESENT | _PAGE_READ, 0x300, dsisr);
+   ret = hash_page(ea,
+   _PAGE_PRESENT | _PAGE_READ | _PAGE_PRIVILEGED,
+   0x300, dsisr);
spin_lock(>register_lock);
 
if (!ret) {
-- 
2.7.4

Re: SPU not working for kernel 4.9, 4.10, 4.11a and 4.12

[Jeremy Kerr]

Hi all,


> Looks like this also happens with the simple spu_run test:
> 
>  
> https://github.com/jk-ozlabs/spufs-testsuite/blob/master/tests/03-spu_run/01-spu_run.c
> 
> ... might need some debugging here, I'll update if I find anything.

And it appears we're stuck in the POLL_WHILE_FALSE() loop in
wait_tag_complete() called from restore_lscsa().

Because spufs itself has been fairly static, I suspect some other change
has meant that MFC DMAs aren't working; so at this point, a bisect might
be the best way forward. Do you see the exact same behaviour on 4.9 (but
4.8 works?)

Cheers,


Jeremy

Re: SPU not working for kernel 4.9, 4.10, 4.11a and 4.12

[Jeremy Kerr]

Hi all,

> I'd like to report that SPU not working for kernel > 4.9. The problem
> caused by spe_context_run function, when call , it never return back.

Looks like this also happens with the simple spu_run test:

 
https://github.com/jk-ozlabs/spufs-testsuite/blob/master/tests/03-spu_run/01-spu_run.c

... might need some debugging here, I'll update if I find anything.

Cheers,


Jeremy

Re: [PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler

[Jeremy Kerr]

Hi Mukesh,

>> Unless I'm mistaken, there are two things I can see happening with the
>> old code: if we hit the IRQ_NONE path enough, we'll report a "nobody
>> cared" error (see __report_bad_irq) and disable the interrupt, or for
>> the -1 case, we'll immediately log a "bogus return value" error (and, it
>> looks like a "no thread function available" error too, from
>> warn_no_thread).
> 
> bogus return value" error will not come as
> 
> action_ret <= (IRQ_HANDLED | IRQ_WAKE_THREAD)
> i.e
> 0/-1 <= 3 (true)

Well, no. irqreturn_t is an enum, and is being treated as an unsigned
value (the signed/unsigned behaviour of an enum is
implementation-defined), and:

  0x > 3

so we will *probably* see the bogus return value warning here (based on
some brief experimentation with gcc), but that does depend on the
compiler.

I've submitted a patch to make that comparison more obvious and
explicit:

  https://marc.info/?l=linux-kernel=148721917302673

Cheers,


Jeremy

Re: [PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler

[Jeremy Kerr]

Hi Mukesh,

> The return value of an interrupt handler is the special type
> irqreturn_t. An interrupt handler can return two special values,
> IRQ_NONE or IRQ_HANDLED.

Yep, you can assume that the reader knows that level of the interrupt
handler API :) What we want to know is how that change in behaviour of
the handler code interacts with the core irq handler code.

The change you're proposing always returns IRQ_HANDLED, whereas the
previous code had cases where it returned:

  - IRQ_NONE, or
  - the (invalid) value -1.

Unless I'm mistaken, there are two things I can see happening with the
old code: if we hit the IRQ_NONE path enough, we'll report a "nobody
cared" error (see __report_bad_irq) and disable the interrupt, or for
the -1 case, we'll immediately log a "bogus return value" error (and, it
looks like a "no thread function available" error too, from
warn_no_thread).

So, it would be nice to mention that this change will fix errors that
result in those log messages. This means that someone debugging those
log messages in futures can find your patch, and see that it addresses
the issue.

> No, this is not user visible issue..

I consider the kernel log output to be user-visible.

> and also here it does not matter what we return from here as we
> are not handling the return value of the handler. 

*We* are not handling the return value of the handler, but the core IRQ
code is.

Regards,


Jeremy

Re: [PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler

[Jeremy Kerr]

Hi Mukesh,

> Converts all the return explicit number to a more proper IRQ_HANDLED,
> which looks proper incase of interrupt handler returning case.

This looks good to me, but can you describe the effects of those changes
to the interrupt handler's return code? ie, what happened in the
erroneous case where we returned 0 (== IRQ_NONE) - does this fix a
user-visible issue?

Cheers,


Jeremy

Re: [PATCH 1/2] powerpc/powernv/opal-dump : Handles opal_dump_info properly

[Jeremy Kerr]

Hi Mukesh,

> Moves the return value check of 'opal_dump_info' to a proper place which
> was previously unnecessarily filling all the dump info even on failure.

Acked-by: Jeremy Kerr <j...@ozlabs.org>

Thanks!


Jeremy

Re: [Openipmi-developer] [PATCH 3/4] ipmi: allow dynamic BMC version information

[Jeremy Kerr]

Hi Corey,

> In all, this looks good.  I have two minor nits inline below, and
> two more major comments here:
> 
> I would prefer if it always queried the data, even if the device id
> information is provided by the lower level driver.

OK, can do. I was concerned that the SMI driver may want to provide its
own device identification details (and not want to override those with
the ones provided by Get Device Id), but if that's not the case then it
makes sense to store the original values but allow requery.

> Since the values can change while you are querying them, do
> we need some sort of mutex on them?

Which values are you referring to here? The device ID, or the members of
struct bmc_device?

If it's the latter, I'd be happy to take your guidance on the locking
protocol there. Is there an existing mutex that would be suitable for
that?

>From the comments inline:

> > +/* Do we have enough data to parse the device ID details? This doesn't
> > + * inclde the optional auxilliary version data. */
> 
> Minor nit: include is misspelled. 

D'oh, will fix in v2.

> > @@ -2450,6 +2590,8 @@ static int ipmi_bmc_register(ipmi_smi_t intf, int 
> > ifnum)
> >   
> > mutex_lock(_mutex);
> >   
> > +   bmc_update_device_id(bmc);
> > +
> 
> What happens if this fails?  You can return an error from this function.
> It's also probably not necessary to have this inside the mutex.

I didn't think we'd want to fail registration on query failure there; it
could be a transient error.

Cheers,


Jeremy

[PATCH 0/4] ipmi: Allow dynamic device IDs

[Jeremy Kerr]

This series implements a more dynamic method of reporting BMC version &
identification. The current method of registering versions and IDs
during ipmi_register_smi means that if a BMC is upgraded during a boot,
the IPMI core code will report old version information.

We do this by querying the BMC (using a Get Device ID request) at smi
registration in the IPMI core code, and when the sysfs version & id
attributes are accessed.

The core of the change is in patch 3/4. Patches 1 and 2 implement a
couple of minor API changes leading up to this.

Patch 4 converts the powernv IPMI driver to use the dynamic IDs; the
behaviour of the other SMIs is not changed by this series. However,
if there's interest, I'm happy to alter the existing SMIs too, in a
follow-up series.

Questions & comments most welcome.

Cheers,


Jeremy
---

Jeremy Kerr (4):
  ipmi: Add a reference from BMC devices to their interfaces
  ipmi: Make ipmi_demangle_device_id more generic
  ipmi: allow dynamic BMC version information
  ipmi/powernv: Use dynamic device ids

 drivers/char/ipmi/ipmi_msghandler.c | 160 ++--
 drivers/char/ipmi/ipmi_powernv.c|   5 +-
 drivers/char/ipmi/ipmi_si_intf.c|   3 +-
 drivers/char/ipmi/ipmi_ssif.c   |   3 +-
 include/linux/ipmi_smi.h|  16 ++--
 5 files changed, 169 insertions(+), 18 deletions(-)

-- 
2.7.4

[PATCH 4/4] ipmi/powernv: Use dynamic device ids

[Jeremy Kerr]

We don't currently provide any device ID info in the SMI registration,
so use the dynamic ID infrastructure instead.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 drivers/char/ipmi/ipmi_powernv.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
index 6e658aa..10e69d6 100644
--- a/drivers/char/ipmi/ipmi_powernv.c
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -23,7 +23,6 @@
 
 struct ipmi_smi_powernv {
u64 interface_id;
-   struct ipmi_device_id   ipmi_id;
ipmi_smi_t  intf;
unsigned intirq;
 
@@ -265,9 +264,7 @@ static int ipmi_powernv_probe(struct platform_device *pdev)
goto err_unregister;
}
 
-   /* todo: query actual ipmi_device_id */
-   rc = ipmi_register_smi(_powernv_smi_handlers, ipmi,
-   >ipmi_id, dev, 0);
+   rc = ipmi_register_smi(_powernv_smi_handlers, ipmi, NULL, dev, 0);
if (rc) {
dev_warn(dev, "IPMI SMI registration failed (%d)\n", rc);
goto err_free_msg;
-- 
2.7.4

[PATCH 3/4] ipmi: allow dynamic BMC version information

[Jeremy Kerr]

Currently, it's up to the IPMI SMIs to provide the product & version
details of BMCs behind registered IPMI SMI interfaces. This device ID is
provided on SMI regsitration, and kept around for all future queries.

However, this version information isn't always static. For example, a
BMC may be upgraded at runtime, making the old version information
stale.

This change allows querying the BMC device ID & version information
dynamically. If no static device_id argument is provided to
ipmi_register_smi, then the IPMI core code will perform a Get Device ID
IPMI command to query the version information when needed. We keep a
short-term cache of this information so we don't need to re-query
for every attribute access.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 drivers/char/ipmi/ipmi_msghandler.c | 158 ++--
 1 file changed, 153 insertions(+), 5 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 41990bb..55feba0 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -90,6 +90,9 @@ static struct proc_dir_entry *proc_ipmi_root;
  */
 #define IPMI_REQUEST_EV_TIME   (1000 / (IPMI_TIMEOUT_TIME))
 
+/* How long should we cache dynamic device IDs? */
+#define IPMI_DYN_DEV_ID_EXPIRY (10 * HZ)
+
 /*
  * The main "user" data structure.
  */
@@ -192,10 +195,19 @@ struct ipmi_proc_entry {
 };
 #endif
 
+enum bmc_dyn_device_id_state {
+   BMC_DEVICE_DYN_ID_STATE_DISABLED,
+   BMC_DEVICE_DYN_ID_STATE_QUERYING,
+   BMC_DEVICE_DYN_ID_STATE_VALID,
+   BMC_DEVICE_DYN_ID_STATE_INVALID,
+};
+
 struct bmc_device {
struct platform_device pdev;
struct ipmi_device_id  id;
ipmi_smi_t intf;
+   intdyn_id;
+   unsigned long  dyn_id_expiry;
unsigned char  guid[16];
intguid_set;
char   name[16];
@@ -1997,6 +2009,108 @@ int ipmi_request_supply_msgs(ipmi_user_t  user,
 }
 EXPORT_SYMBOL(ipmi_request_supply_msgs);
 
+static void bmc_device_id_handler(ipmi_smi_t intf, struct ipmi_recv_msg *msg)
+{
+   int rc;
+
+   if ((msg->addr.addr_type != IPMI_SYSTEM_INTERFACE_ADDR_TYPE)
+   || (msg->msg.netfn != IPMI_NETFN_APP_RESPONSE)
+   || (msg->msg.cmd != IPMI_GET_DEVICE_ID_CMD))
+   return;
+
+   /* Do we have a success completion code? */
+   if (msg->msg.data[0] != 0) {
+   intf->bmc->dyn_id = BMC_DEVICE_DYN_ID_STATE_INVALID;
+   goto out;
+   }
+
+   /* Do we have enough data to parse the device ID details? This doesn't
+* inclde the optional auxilliary version data. */
+   if (msg->msg.data_len < 12) {
+   intf->bmc->dyn_id = BMC_DEVICE_DYN_ID_STATE_INVALID;
+   goto out;
+   }
+
+   rc = ipmi_demangle_device_id(msg->msg.netfn, msg->msg.cmd,
+   msg->msg.data, msg->msg.data_len, >bmc->id);
+   if (rc) {
+   intf->bmc->dyn_id = BMC_DEVICE_DYN_ID_STATE_INVALID;
+   goto out;
+   }
+
+   intf->ipmi_version_major = ipmi_version_major(>bmc->id);
+   intf->ipmi_version_minor = ipmi_version_minor(>bmc->id);
+
+   /* All good! mark the dynamic ID as valid, and set its expiration
+* time */
+   intf->bmc->dyn_id = BMC_DEVICE_DYN_ID_STATE_VALID;
+   intf->bmc->dyn_id_expiry = jiffies + IPMI_DYN_DEV_ID_EXPIRY;
+out:
+   wake_up(>waitq);
+}
+
+
+static int bmc_update_device_id(struct bmc_device *bmc)
+{
+   struct ipmi_system_interface_addr si;
+   ipmi_smi_t intf = bmc->intf;
+   struct kernel_ipmi_msg msg;
+   int rc;
+
+   if (bmc->dyn_id == BMC_DEVICE_DYN_ID_STATE_DISABLED)
+   return 0;
+
+   if (bmc->dyn_id == BMC_DEVICE_DYN_ID_STATE_VALID &&
+   time_is_after_jiffies(bmc->dyn_id_expiry))
+   return 0;
+
+   /* do we have a request in progress? Just wait for that. */
+   if (bmc->dyn_id == BMC_DEVICE_DYN_ID_STATE_QUERYING)
+   return wait_event_timeout(intf->waitq,
+   bmc->dyn_id != BMC_DEVICE_DYN_ID_STATE_QUERYING,
+   IPMI_DYN_DEV_ID_EXPIRY);
+
+   /* send Get Device ID request */
+   si.addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE;
+   si.channel = IPMI_BMC_CHANNEL;
+   si.lun = 0;
+
+   msg.netfn = IPMI_NETFN_APP_REQUEST;
+   msg.cmd = IPMI_GET_DEVICE_ID_CMD;
+   msg.data = NULL;
+   msg.data_len = 0;
+
+   intf->null_user_handler = bmc_device_id_handler;
+
+   bmc->dyn_id = BMC_DEVICE_DYN_ID_STATE_QUERYING;
+
+   rc = i_ipmi_request(NULL,
+ intf,
+ 

[PATCH 2/4] ipmi: Make ipmi_demangle_device_id more generic

[Jeremy Kerr]

Currently, ipmi_demagle_device_id requires a full response buffer in its
data argument. This means we can't use it to parse a response in a
struct ipmi_recv_msg, which has the netfn and cmd as separate bytes.

This change alters the definition and users of ipmi_demangle_device_id
to use a split netfn, cmd and data buffer, so it can be used with
non-sequential responses.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 drivers/char/ipmi/ipmi_si_intf.c |  3 ++-
 drivers/char/ipmi/ipmi_ssif.c|  3 ++-
 include/linux/ipmi_smi.h | 16 +---
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index a112c01..745368d 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2951,7 +2951,8 @@ static int try_get_dev_id(struct smi_info *smi_info)
  resp, IPMI_MAX_MSG_LENGTH);
 
/* Check and record info from the get device id, in case we need it. */
-   rv = ipmi_demangle_device_id(resp, resp_len, _info->device_id);
+   rv = ipmi_demangle_device_id(msg[0], msg[1],
+   resp+2, resp_len-2, _info->device_id);
 
 out:
kfree(resp);
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 5673fff..29bbcaf 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -1461,7 +1461,8 @@ static int ssif_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
if (rv)
goto out;
 
-   rv = ipmi_demangle_device_id(resp, len, _info->device_id);
+   rv = ipmi_demangle_device_id(msg[0], msg[1],
+   resp+2, len-2, _info->device_id);
if (rv)
goto out;
 
diff --git a/include/linux/ipmi_smi.h b/include/linux/ipmi_smi.h
index f8cea14..bf2f489 100644
--- a/include/linux/ipmi_smi.h
+++ b/include/linux/ipmi_smi.h
@@ -167,22 +167,24 @@ struct ipmi_device_id {
netfn << 2, the data should be of the format:
   netfn << 2, cmd, completion code, data
as normally comes from a device interface. */
-static inline int ipmi_demangle_device_id(const unsigned char *data,
+static inline int ipmi_demangle_device_id(uint8_t netfn, uint8_t cmd,
+ const unsigned char *data,
  unsigned int data_len,
  struct ipmi_device_id *id)
 {
-   if (data_len < 9)
+   if (data_len < 7)
return -EINVAL;
-   if (data[0] != IPMI_NETFN_APP_RESPONSE << 2 ||
-   data[1] != IPMI_GET_DEVICE_ID_CMD)
+   if (netfn != IPMI_NETFN_APP_RESPONSE << 2 ||
+   cmd != IPMI_GET_DEVICE_ID_CMD)
/* Strange, didn't get the response we expected. */
return -EINVAL;
-   if (data[2] != 0)
+   if (data[0] != 0)
/* That's odd, it shouldn't be able to fail. */
return -EINVAL;
 
-   data += 3;
-   data_len -= 3;
+   data++;
+   data_len--;
+
id->device_id = data[0];
id->device_revision = data[1];
id->firmware_revision_1 = data[2];
-- 
2.7.4

[PATCH 1/4] ipmi: Add a reference from BMC devices to their interfaces

[Jeremy Kerr]

In an upcoming change, we'll want to grab a reference to the ipmi_smi_t
from a struct bmc_device. This change adds a pointer to allow this.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 drivers/char/ipmi/ipmi_msghandler.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index d8619998..41990bb 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -195,6 +195,7 @@ struct ipmi_proc_entry {
 struct bmc_device {
struct platform_device pdev;
struct ipmi_device_id  id;
+   ipmi_smi_t intf;
unsigned char  guid[16];
intguid_set;
char   name[16];
@@ -2796,6 +2797,7 @@ int ipmi_register_smi(const struct ipmi_smi_handlers 
*handlers,
}
intf->intf_num = -1; /* Mark it invalid for now. */
kref_init(>refcount);
+   intf->bmc->intf = intf;
intf->bmc->id = *device_id;
intf->si_dev = si_dev;
for (j = 0; j < IPMI_MAX_CHANNELS; j++) {
-- 
2.7.4

Re: [RFC 0/3] extend kexec_file_load system call

[Jeremy Kerr]

Hi Thiago,

> So even if not ideal, the solution above is desirable for powerpc. We would 
> like to preserve the ability of allowing userspace to pass parameters to the 
> OS via the DTB, even if secure boot is enabled.
> 
> I would like to turn the above into a proposal:
> 
> Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead of 
> accepting a complete DTB from userspace, the syscall accepts a DTB 
> containing only a /chosen node. If the DTB contains any other node, the 
> syscall fails with EINVAL. If the DTB contains any subnode in /chosen, or if 
> there's a compatible or device_type property in /chosen, the syscall fails 
> with EINVAL as well.

This works for me. We could even have it as just a DTB fragment that is
merged *at* the /chosen/ node of the kernel-device tree - so would not
contain a /chosen node itself, and it would be impossible to provide
nodes outside of /chosen. Either is fine.

Thanks!


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: mailman From rewriting [was perf jit: genelf makes assumptions about endian]

[Jeremy Kerr]

Hi Stephen,

>> Do you know why mailman would be re-writing From: there? It's confusing
>> patchwork, as multiple mails are now coming from that address.
> 
> Yep, Anton posts from samba.org.  They publish a DMARC policy that
> breaks mailing lists.

(╯°□°)╯︵ ┻━━┻

This also breaks git-am:

  [jk@pudge linux]$ git am incoming.eml
  Applying: perf jit: genelf makes assumptions about endian
  [jk@pudge linux]$ git log --format='format:%an <%ae>' -1
  Anton Blanchard via Linuxppc-dev 

> The best thing we can do is to do the above rewrite of the From header.

OK, it looks like we're stuck either way with DMARC. Could we make this
a little more tolerable by stashing the original From: value in a new
header? I know it's already in Reply-To, but that could also be set by
arbitrary other (non-mailman-DMARC-rewrite) sources.

Alternatively, if there's some other way to tell that this a mail has
been rewritten, we can know to use Reply-To in preference to From.

Otherwise, I guess we could require that *all patch submitters* put
their From: line in the content of their mails, as git send-email does
when user != author. But that's a little less-than-optimal.

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

mailman From rewriting [was perf jit: genelf makes assumptions about endian]

[Jeremy Kerr]

Hi Stephen,

From the mail that Anton has sent to linuxppc-dev:

> From: Anton Blanchard via Linuxppc-dev 
> Reply-To: Anton Blanchard 

Do you know why mailman would be re-writing From: there? It's confusing
patchwork, as multiple mails are now coming from that address.

Anton: did you do anything special when sending that mail?

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/3] powerpc/powernv: Add powernv firmware interface drivers to powernv_defconfig

[Jeremy Kerr]

There are a few firmware-provided interfaces for OpenPOWER platforms:
the PRD infrastructure, IPMI support, and MTD access to the PNOR flash.

This change adds these to powernv_defconfig

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 arch/powerpc/configs/powernv_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index ad0ad65..ed84b2b 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -37,6 +37,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_PARTITION_ADVANCED=y
+CONFIG_OPAL_PRD=y
 # CONFIG_PPC_PSERIES is not set
 # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
@@ -78,6 +79,8 @@ CONFIG_VLAN_8021Q=m
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_MTD=y
+CONFIG_MTD_POWERNV_FLASH=y
 CONFIG_PARPORT=m
 CONFIG_PARPORT_PC=m
 CONFIG_BLK_DEV_FD=m
@@ -178,6 +181,9 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_JSM=m
 CONFIG_VIRTIO_CONSOLE=m
+CONFIG_IPMI_HANDLER=y
+CONFIG_IPMI_DEVICE_INTERFACE=y
+CONFIG_IPMI_POWERNV=y
 CONFIG_RAW_DRIVER=y
 CONFIG_MAX_RAW_DEVS=1024
 CONFIG_FB=y
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3] powerpc/powernv: Add AST graphics driver to powernv_defconfig

[Jeremy Kerr]

Most current OpenPOWER platforms have an AST BMC, so add graphics
support via the AST DRM driver.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 arch/powerpc/configs/powernv_defconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index ed84b2b..0450310 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -186,7 +186,8 @@ CONFIG_IPMI_DEVICE_INTERFACE=y
 CONFIG_IPMI_POWERNV=y
 CONFIG_RAW_DRIVER=y
 CONFIG_MAX_RAW_DEVS=1024
-CONFIG_FB=y
+CONFIG_DRM=y
+CONFIG_DRM_AST=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_OF=y
 CONFIG_FB_MATROX=y
@@ -197,7 +198,6 @@ CONFIG_FB_RADEON=y
 CONFIG_FB_IBM_GXT4500=y
 CONFIG_LCD_PLATFORM=m
 # CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 CONFIG_HID_GYRATION=y
 CONFIG_HID_PANTHERLORD=y
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] powerpc/powernv: Add powernv_defconfig

[Jeremy Kerr]

This change adds a defconfig for the non-virtualised power platforms,
based on pseries_defconfig, but without pseries, and little-endian,
and no OF trampoline.

Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
---
 arch/powerpc/configs/powernv_defconfig | 307 +
 1 file changed, 307 insertions(+)
 create mode 100644 arch/powerpc/configs/powernv_defconfig

diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
new file mode 100644
index 000..ad0ad65
--- /dev/null
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -0,0 +1,307 @@
+CONFIG_PPC64=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2048
+CONFIG_CPU_LITTLE_ENDIAN=y
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
+CONFIG_AUDIT=y
+CONFIG_IRQ_DOMAIN_DEBUG=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_TASKSTATS=y
+CONFIG_TASK_DELAY_ACCT=y
+CONFIG_TASK_XACCT=y
+CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_NUMA_BALANCING=y
+CONFIG_CGROUPS=y
+CONFIG_MEMCG=y
+CONFIG_MEMCG_SWAP=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CPUSETS=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_CGROUP_PERF=y
+CONFIG_USER_NS=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=y
+CONFIG_KPROBES=y
+CONFIG_JUMP_LABEL=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_PPC_PSERIES is not set
+# CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_IDLE=y
+CONFIG_HZ_100=y
+CONFIG_BINFMT_MISC=m
+CONFIG_PPC_TRANSACTIONAL_MEM=y
+CONFIG_HOTPLUG_CPU=y
+CONFIG_KEXEC=y
+CONFIG_IRQ_ALL_CPUS=y
+CONFIG_NUMA=y
+CONFIG_MEMORY_HOTPLUG=y
+CONFIG_MEMORY_HOTREMOVE=y
+CONFIG_KSM=y
+CONFIG_TRANSPARENT_HUGEPAGE=y
+CONFIG_PPC_64K_PAGES=y
+CONFIG_PPC_SUBPAGE_PROT=y
+CONFIG_SCHED_SMT=y
+CONFIG_PM=y
+CONFIG_PCI_MSI=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=m
+CONFIG_NET_KEY=m
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_NET_IPIP=y
+CONFIG_SYN_COOKIES=y
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+# CONFIG_NETFILTER_ADVANCED is not set
+CONFIG_BRIDGE=m
+CONFIG_VLAN_8021Q=m
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_PARPORT=m
+CONFIG_PARPORT_PC=m
+CONFIG_BLK_DEV_FD=m
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_NBD=m
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=65536
+CONFIG_VIRTIO_BLK=m
+CONFIG_IDE=y
+CONFIG_BLK_DEV_IDECD=y
+CONFIG_BLK_DEV_GENERIC=y
+CONFIG_BLK_DEV_AMD74XX=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_BLK_DEV_SR_VENDOR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_FC_ATTRS=y
+CONFIG_SCSI_SRP_ATTRS=y
+CONFIG_SCSI_CXGB3_ISCSI=m
+CONFIG_SCSI_CXGB4_ISCSI=m
+CONFIG_SCSI_BNX2_ISCSI=m
+CONFIG_BE2ISCSI=m
+CONFIG_SCSI_MPT2SAS=m
+CONFIG_SCSI_SYM53C8XX_2=y
+CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
+CONFIG_SCSI_IPR=y
+CONFIG_SCSI_QLA_FC=m
+CONFIG_SCSI_QLA_ISCSI=m
+CONFIG_SCSI_LPFC=m
+CONFIG_SCSI_VIRTIO=m
+CONFIG_SCSI_DH=y
+CONFIG_SCSI_DH_RDAC=m
+CONFIG_SCSI_DH_ALUA=m
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+# CONFIG_ATA_SFF is not set
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=y
+CONFIG_MD_LINEAR=y
+CONFIG_MD_RAID0=y
+CONFIG_MD_RAID1=y
+CONFIG_MD_RAID10=m
+CONFIG_MD_RAID456=m
+CONFIG_MD_MULTIPATH=m
+CONFIG_MD_FAULTY=m
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_CRYPT=m
+CONFIG_DM_SNAPSHOT=m
+CONFIG_DM_THIN_PROVISIONING=m
+CONFIG_DM_MIRROR=m
+CONFIG_DM_ZERO=m
+CONFIG_DM_MULTIPATH=m
+CONFIG_DM_MULTIPATH_QL=m
+CONFIG_DM_MULTIPATH_ST=m
+CONFIG_DM_UEVENT=y
+CONFIG_BONDING=m
+CONFIG_DUMMY=m
+CONFIG_MACVLAN=m
+CONFIG_MACVTAP=m
+CONFIG_VXLAN=m
+CONFIG_NETCONSOLE=y
+CONFIG_TUN=m
+CONFIG_VETH=m
+CONFIG_VIRTIO_NET=m
+CONFIG_VHOST_NET=m
+CONFIG_VORTEX=y
+CONFIG_ACENIC=m
+CONFIG_ACENIC_OMIT_TIGON_I=y
+CONFIG_PCNET32=y
+CONFIG_TIGON3=y
+CONFIG_BNX2X=m
+CONFIG_CHELSIO_T1=m
+CONFIG_BE2NET=m
+CONFIG_S2IO=m
+CONFIG_E100=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
+CONFIG_IXGB=m
+CONFIG_IXGBE=m
+CONFIG_MLX4_EN=m
+CONFIG_MYRI10GE=m
+CONFIG_QLGE=m
+CONFIG_NETXEN_NIC=m
+CONFIG_PPP=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPPOE=m
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_SYNC_TTY=m
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=m
+CONFIG_INPUT_MISC=y
+# CONFIG_SERIO_SERPORT is not set
+CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_JSM=m
+CONFIG_VIRTIO_CONSOLE=m
+CONFIG_RAW_DRIVER=y
+CONFIG_MAX_RAW_DEVS=1024
+CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+CONFIG_FB_OF=y
+CONFIG_FB_MATROX=y
+CONFIG_FB_MATROX_MILLENIUM=y
+CONFIG_FB_MATROX_MYSTIQUE=y
+CONFIG_FB_MATROX_G=y
+CONFIG_FB_RADEON=y
+CONFIG_FB_IBM_GXT4500=y
+CONFIG_LCD_PLATFORM=m
+# CONFIG_VGA_CONSOLE is not set
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
+CONFIG_HID_GYRATION=y
+CONFIG_HID_PANTHERLORD=y
+CONFIG_HID_PETALYNX=y
+CONF

Re: [PATCH 2/5] powerpc/cell: Drop support for 64K local store on 4K kernels

[Jeremy Kerr]

Hi Michael,

 Back in the olden days we added support for using 64K pages to map the
 SPU (Synergistic Processing Unit) local store on Cell, when the main
 kernel was using 4K pages.
 
 This was useful at the time because distros were using 4K pages, but
 using 64K pages on the SPUs could reduce TLB pressure there.
 
 However these days the number of Cell users is approaching zero, and
 supporting this option adds unpleasant complexity to the memory
 management code.
 
 So drop the option, CONFIG_SPU_FS_64K_LS, and all related code.

Yep, I'd be happy to drop this - impact should be little to none.

Acked-by: Jeremy Kerr j...@ozlabs.org

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Fix crash due to processing memory-controller nodes as memory

[Jeremy Kerr]

Hi Anton,

 [PATCH] Fix crash due to processing memory-controller nodes as memory

Looks good to me. If you apply this to your kexec-lite repo, I'll update
op-build to use the new version, and send the merge requests for op-build.

I'd expect we'd have those changes upstream in the next couple of days.
Xilinx folks: how are you consuming op-build? Do you need a new PNOR
image, or are you constructing those yourself?

Regards,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RESEND PATCH] powerpc/powernv: Fix vma page prot flags in opal-prd driver

[Jeremy Kerr]

Hi Vaidy,

 opal-prd driver will mmap() firmware code/data area as private
 mapping to prd user space daemon.  Write to this page will
 trigger COW faults.  The new COW pages are normal kernel RAM
 pages accounted by the kernel and are not special.
 
 vma-vm_page_prot value will be used at page fault time
 for the new COW pages, while pgprot_t value passed in
 remap_pfn_range() is used for the initial page table entry.
 
 Hence:
 * Do not add _PAGE_SPECIAL in vma, but only for remap_pfn_range()
 * Also remap_pfn_range() will add the _PAGE_SPECIAL flag using
   pte_mkspecial() call, hence no need to specify in the driver
 
 This fix resolves the page accounting warning shown below:
 BUG: Bad rss-counter state mm:c007d34ac600 idx:1 val:19
 
 The above warning is triggered since _PAGE_SPECIAL was incorrectly
 being set for the normal kernel COW pages.
 
 Signed-off-by: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com

Acked-by: Jeremy Kerr j...@ozlabs.org

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/include: Add opal-prd to installed uapi headers

[Jeremy Kerr]

We'll want to build the opal-prd daemon with the prd headers, so include
this in the uapi headers list.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/include/uapi/asm/Kbuild |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/include/uapi/asm/Kbuild 
b/arch/powerpc/include/uapi/asm/Kbuild
index 79c4068..f44a0278 100644
--- a/arch/powerpc/include/uapi/asm/Kbuild
+++ b/arch/powerpc/include/uapi/asm/Kbuild
@@ -18,6 +18,7 @@ header-y += kvm_para.h
 header-y += mman.h
 header-y += msgbuf.h
 header-y += nvram.h
+header-y += opal-prd.h
 header-y += param.h
 header-y += perf_event.h
 header-y += poll.h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/powernv: fix construction of opal PRD messages

[Jeremy Kerr]

We currently have a bug in the PRD code, where the contents of an
incoming message (beyond the header) will be overwritten by the list
item manipulations when adding to to the prd_msg_queue.

This change reorders struct opal_prd_msg_queue_item, so that the
message body doesn't overlap the list_head.

We also clarify the memcpy of the message, as we're copying unnecessary
bytes at the end of the message data.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/platforms/powernv/opal-prd.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-prd.c 
b/arch/powerpc/platforms/powernv/opal-prd.c
index 64694dd..ba2e388 100644
--- a/arch/powerpc/platforms/powernv/opal-prd.c
+++ b/arch/powerpc/platforms/powernv/opal-prd.c
@@ -32,9 +32,13 @@
 #include asm/uaccess.h
 
 
+/**
+ * The msg member must be at the end of the struct, as it's followed by the
+ * message data.
+ */
 struct opal_prd_msg_queue_item {
-   struct opal_prd_msg_header  msg;
struct list_headlist;
+   struct opal_prd_msg_header  msg;
 };
 
 static struct device_node *prd_node;
@@ -351,22 +355,23 @@ static int opal_prd_msg_notifier(struct notifier_block 
*nb,
struct opal_prd_msg_queue_item *item;
struct opal_prd_msg_header *hdr;
struct opal_msg *msg = _msg;
+   int msg_size, item_size;
unsigned long flags;
-   int size;
 
if (msg_type != OPAL_MSG_PRD)
return 0;
 
-   /* Calculate total size of the item we need to store. The 'size' field
-* in the header includes the header itself. */
+   /* Calculate total size of the message and item we need to store. The
+* 'size' field in the header includes the header itself. */
hdr = (void *)msg-params;
-   size = (sizeof(*item) - sizeof(item-msg)) + be16_to_cpu(hdr-size);
+   msg_size = be16_to_cpu(hdr-size);
+   item_size = msg_size + sizeof(*item) - sizeof(item-msg);
 
-   item = kzalloc(size, GFP_ATOMIC);
+   item = kzalloc(item_size, GFP_ATOMIC);
if (!item)
return -ENOMEM;
 
-   memcpy(item-msg, msg-params, size);
+   memcpy(item-msg, msg-params, msg_size);
 
spin_lock_irqsave(opal_prd_msg_queue_lock, flags);
list_add_tail(item-list, opal_prd_msg_queue);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [3/3,v3] powerpc/powernv: Add opal-prd channel

[Jeremy Kerr]

Hi Michael,

 Sorry, I put this in but then hit the build break, I was going to fix it up 
 but
 would rather you did and tested it, so we may as well do another review :)

whee!

 @@ -0,0 +1,58 @@
 +/*
 + * OPAL Runtime Diagnostics interface driver
 + * Supported on POWERNV platform
 + *
 + * (C) Copyright IBM 2015
 
 Usual syntax is: Copyright IBM Corporation 2015

OK, fixed.

 + *
 + * Author: Vaidyanathan Srinivasan svaidy at linux.vnet.ibm.com
 + * Author: Jeremy Kerr j...@ozlabs.org
 
 I'd rather you dropped these, they'll just bit rot, but if you insist I don't
 care that much.

Yep, I'd rather remove them too.

 + *
 + * 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, or (at your option)
 + * any later version.
 
 As pointed out by Daniel, we should probably be using the version 2 only
 language on new files.

Fixed.

 +vma-vm_page_prot = phys_mem_access_prot(file, vma-vm_pgoff,
 + size, vma-vm_page_prot)
 +| _PAGE_SPECIAL;
 
 This doesn't build with CONFIG_STRICT_MM_TYPECHECKS=y:
 
   arch/powerpc/platforms/powernv/opal-prd.c:131:5: error: invalid operands to 
 binary | (have ‘pgprot_t’ and ‘int’)
   | _PAGE_SPECIAL;

OK, new patch coming with the proper pgprot macros.

 +switch(cmd) {
   ^
 space please

Fixed.


 +pr_devel(ioctl SCOM_READ: chip %llx addr %016llx 
 +data %016llx rc %lld\n,
 
 Don't split the string please.

OK, but this makes our lines 80 chars. Assuming that'll be okay.

 +struct file_operations opal_prd_fops = {
 
 This can be static const I think.

Indeed it can! Updated.

 +static struct miscdevice opal_prd_dev = {
 +.minor  = MISC_DYNAMIC_MINOR,
 +.name   = opal-prd,
 +.fops   = opal_prd_fops,
 
 White space is messed up here, should be leading tabs.

[tabs-spaces-both.png]

Thanks for the review, new patch coming soon.

Cheers,


Jeremy


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3 v4] powerpc/powernv: Add opal-prd channel

[Jeremy Kerr]

This change adds a char device to access the PRD (processor runtime
diagnostics) channel to OPAL firmware.

Includes contributions from Vaidyanathan Srinivasan, Neelesh Gupta 
Vishal Kulkarni.

Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Jeremy Kerr j...@ozlabs.org
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com

---

v4:
 - Address reviews from mpe:

 - GPLv2+ - GPLv2, fix copyrights, remove authors

 - fix pgprot manipulations

 - formatting  space fixes

 - constify opal_prd_fops

v3:
 - Add versioning description and reserved fields in opal_prd_info
   for future expansion

 - Fix node leak in opal_prd_range_is_valid

 - Explain open()  probe() semantics

 - Fix miscdev_register error path


---
 arch/powerpc/include/asm/opal-api.h|   21 
 arch/powerpc/include/asm/opal.h|1 
 arch/powerpc/include/uapi/asm/opal-prd.h   |   58 ++
 arch/powerpc/platforms/powernv/Kconfig |7 
 arch/powerpc/platforms/powernv/Makefile|1 
 arch/powerpc/platforms/powernv/opal-prd.c  |  445 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |1 
 arch/powerpc/platforms/powernv/opal.c  |4 
 8 files changed, 536 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..2407f12 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -153,7 +153,8 @@
 #define OPAL_FLASH_READ110
 #define OPAL_FLASH_WRITE   111
 #define OPAL_FLASH_ERASE   112
-#define OPAL_LAST  112
+#define OPAL_PRD_MSG   113
+#define OPAL_LAST  113
 
 /* Device tree flags */
 
@@ -352,6 +353,7 @@ enum opal_msg_type {
OPAL_MSG_SHUTDOWN,  /* params[0] = 1 reboot, 0 shutdown */
OPAL_MSG_HMI_EVT,
OPAL_MSG_DPO,
+   OPAL_MSG_PRD,
OPAL_MSG_TYPE_MAX,
 };
 
@@ -674,6 +676,23 @@ typedef struct oppanel_line {
__be64 line_len;
 } oppanel_line_t;
 
+enum opal_prd_msg_type {
+   OPAL_PRD_MSG_TYPE_INIT = 0, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_FINI, /* HBRT/kernel -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN_ACK, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_ERROR,/* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_RESET,/* HBRT -- OPAL */
+};
+
+struct opal_prd_msg_header {
+   uint8_t type;
+   uint8_t pad[1];
+   __be16  size;
+};
+
+struct opal_prd_msg;
+
 /*
  * SG entries
  *
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..93704af 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -193,6 +193,7 @@ int64_t opal_ipmi_recv(uint64_t interface, struct 
opal_ipmi_msg *msg,
uint64_t *msg_len);
 int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
 struct opal_i2c_request *oreq);
+int64_t opal_prd_msg(struct opal_prd_msg *msg);
 
 int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/include/uapi/asm/opal-prd.h 
b/arch/powerpc/include/uapi/asm/opal-prd.h
new file mode 100644
index 000..319ff4a
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-prd.h
@@ -0,0 +1,58 @@
+/*
+ * OPAL Runtime Diagnostics interface driver
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2015
+ *
+ * Author: Vaidyanathan Srinivasan svaidy at linux.vnet.ibm.com
+ * Author: Jeremy Kerr j...@ozlabs.org
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_PRD_H_
+#define _UAPI_ASM_POWERPC_OPAL_PRD_H_
+
+#include linux/types.h
+
+/**
+ * The version of the kernel interface of the PRD system. This describes the
+ * interface available for the /dev/opal-prd device. The actual PRD message
+ * layout and content is private to the firmware -- userspace interface, so
+ * is not covered by this versioning.
+ *
+ * Future interface versions are backwards-compatible; if a later kernel
+ * version is encountered, functionality provided in earlier versions
+ * will work.
+ */
+#define OPAL_PRD_KERNEL_VERSION1
+
+#define OPAL_PRD_GET_INFO  _IOR('o', 0x01, struct opal_prd_info)
+#define OPAL_PRD_SCOM_READ _IOR

[PATCH 3/3 v3] powerpc/powernv: Add opal-prd channel

[Jeremy Kerr]

This change adds a char device to access the PRD (processor runtime
diagnostics) channel to OPAL firmware.

Includes contributions from Vaidyanathan Srinivasan, Neelesh Gupta 
Vishal Kulkarni.

Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Jeremy Kerr j...@ozlabs.org
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com

-- 

v3:
 - Add versioning description and reserved fields in opal_prd_info
   for future expansion

 - Fix node leak in opal_prd_range_is_valid

 - Explain open()  probe() semantics

 - Fix miscdev_register error path

---
 arch/powerpc/include/asm/opal-api.h|   21 
 arch/powerpc/include/asm/opal.h|1 
 arch/powerpc/include/uapi/asm/opal-prd.h   |   58 ++
 arch/powerpc/platforms/powernv/Kconfig |7 
 arch/powerpc/platforms/powernv/Makefile|1 
 arch/powerpc/platforms/powernv/opal-prd.c  |  451 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |1 
 arch/powerpc/platforms/powernv/opal.c  |4 
 8 files changed, 542 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..2407f12 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -153,7 +153,8 @@
 #define OPAL_FLASH_READ110
 #define OPAL_FLASH_WRITE   111
 #define OPAL_FLASH_ERASE   112
-#define OPAL_LAST  112
+#define OPAL_PRD_MSG   113
+#define OPAL_LAST  113
 
 /* Device tree flags */
 
@@ -352,6 +353,7 @@ enum opal_msg_type {
OPAL_MSG_SHUTDOWN,  /* params[0] = 1 reboot, 0 shutdown */
OPAL_MSG_HMI_EVT,
OPAL_MSG_DPO,
+   OPAL_MSG_PRD,
OPAL_MSG_TYPE_MAX,
 };
 
@@ -674,6 +676,23 @@ typedef struct oppanel_line {
__be64 line_len;
 } oppanel_line_t;
 
+enum opal_prd_msg_type {
+   OPAL_PRD_MSG_TYPE_INIT = 0, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_FINI, /* HBRT/kernel -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN_ACK, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_ERROR,/* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_RESET,/* HBRT -- OPAL */
+};
+
+struct opal_prd_msg_header {
+   uint8_t type;
+   uint8_t pad[1];
+   __be16  size;
+};
+
+struct opal_prd_msg;
+
 /*
  * SG entries
  *
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..93704af 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -193,6 +193,7 @@ int64_t opal_ipmi_recv(uint64_t interface, struct 
opal_ipmi_msg *msg,
uint64_t *msg_len);
 int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
 struct opal_i2c_request *oreq);
+int64_t opal_prd_msg(struct opal_prd_msg *msg);
 
 int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/include/uapi/asm/opal-prd.h 
b/arch/powerpc/include/uapi/asm/opal-prd.h
new file mode 100644
index 000..319ff4a
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-prd.h
@@ -0,0 +1,58 @@
+/*
+ * OPAL Runtime Diagnostics interface driver
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2015
+ *
+ * Author: Vaidyanathan Srinivasan svaidy at linux.vnet.ibm.com
+ * Author: Jeremy Kerr j...@ozlabs.org
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_PRD_H_
+#define _UAPI_ASM_POWERPC_OPAL_PRD_H_
+
+#include linux/types.h
+
+/**
+ * The version of the kernel interface of the PRD system. This describes the
+ * interface available for the /dev/opal-prd device. The actual PRD message
+ * layout and content is private to the firmware -- userspace interface, so
+ * is not covered by this versioning.
+ *
+ * Future interface versions are backwards-compatible; if a later kernel
+ * version is encountered, functionality provided in earlier versions
+ * will work.
+ */
+#define OPAL_PRD_KERNEL_VERSION1
+
+#define OPAL_PRD_GET_INFO  _IOR('o', 0x01, struct opal_prd_info)
+#define OPAL_PRD_SCOM_READ _IOR('o', 0x02, struct opal_prd_scom)
+#define OPAL_PRD_SCOM_WRITE_IOW('o', 0x03, struct opal_prd_scom)
+
+#ifndef __ASSEMBLY__
+
+struct opal_prd_info

Re: [PATCH] drivers/mtd: add powernv flash MTD abstraction driver

[Jeremy Kerr]

Hi Brian,

 While I have Jeremy's attention, let me plug a friendly reminder for
 this unrelated comment:
 
 http://patchwork.ozlabs.org/patch/413355/
 
 Jeremy, you still haven't updated patchwork.git for your last round of
 supposed merges.

Ah, thanks for the reminder - I've just done the push.

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3 v2] powerpc/powernv: Add opal-prd channel

[Jeremy Kerr]

This change adds a char device to access the PRD (processor runtime
diagnostics) channel to OPAL firmware.

Includes contributions from Vaidyanathan Srinivasan, Neelesh Gupta 
Vishal Kulkarni.

Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/include/asm/opal-api.h|   21 
 arch/powerpc/include/asm/opal.h|1 
 arch/powerpc/include/uapi/asm/opal-prd.h   |   47 +
 arch/powerpc/platforms/powernv/Kconfig |7 
 arch/powerpc/platforms/powernv/Makefile|1 
 arch/powerpc/platforms/powernv/opal-prd.c  |  440 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |1 
 arch/powerpc/platforms/powernv/opal.c  |4 
 8 files changed, 520 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..2407f12 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -153,7 +153,8 @@
 #define OPAL_FLASH_READ110
 #define OPAL_FLASH_WRITE   111
 #define OPAL_FLASH_ERASE   112
-#define OPAL_LAST  112
+#define OPAL_PRD_MSG   113
+#define OPAL_LAST  113
 
 /* Device tree flags */
 
@@ -352,6 +353,7 @@ enum opal_msg_type {
OPAL_MSG_SHUTDOWN,  /* params[0] = 1 reboot, 0 shutdown */
OPAL_MSG_HMI_EVT,
OPAL_MSG_DPO,
+   OPAL_MSG_PRD,
OPAL_MSG_TYPE_MAX,
 };
 
@@ -674,6 +676,23 @@ typedef struct oppanel_line {
__be64 line_len;
 } oppanel_line_t;
 
+enum opal_prd_msg_type {
+   OPAL_PRD_MSG_TYPE_INIT = 0, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_FINI, /* HBRT/kernel -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN_ACK, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_ERROR,/* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_RESET,/* HBRT -- OPAL */
+};
+
+struct opal_prd_msg_header {
+   uint8_t type;
+   uint8_t pad[1];
+   __be16  size;
+};
+
+struct opal_prd_msg;
+
 /*
  * SG entries
  *
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..93704af 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -193,6 +193,7 @@ int64_t opal_ipmi_recv(uint64_t interface, struct 
opal_ipmi_msg *msg,
uint64_t *msg_len);
 int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
 struct opal_i2c_request *oreq);
+int64_t opal_prd_msg(struct opal_prd_msg *msg);
 
 int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/include/uapi/asm/opal-prd.h 
b/arch/powerpc/include/uapi/asm/opal-prd.h
new file mode 100644
index 000..86c5640
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-prd.h
@@ -0,0 +1,47 @@
+/*
+ * OPAL Runtime Diagnostics interface driver
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2015
+ *
+ * Author: Vaidyanathan Srinivasan svaidy at linux.vnet.ibm.com
+ * Author: Jeremy Kerr j...@ozlabs.org
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_PRD_H_
+#define _UAPI_ASM_POWERPC_OPAL_PRD_H_
+
+#include linux/types.h
+
+#define OPAL_PRD_KERNEL_VERSION1
+
+#define OPAL_PRD_GET_INFO  _IOR('o', 0x01, struct opal_prd_info)
+#define OPAL_PRD_SCOM_READ _IOR('o', 0x02, struct opal_prd_scom)
+#define OPAL_PRD_SCOM_WRITE_IOW('o', 0x03, struct opal_prd_scom)
+
+#ifndef __ASSEMBLY__
+
+struct opal_prd_info {
+   __u64   version;
+};
+
+struct opal_prd_scom {
+   __u64   chip;
+   __u64   addr;
+   __u64   data;
+   __s64   rc;
+};
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _UAPI_ASM_POWERPC_OPAL_PRD_H */
diff --git a/arch/powerpc/platforms/powernv/Kconfig 
b/arch/powerpc/platforms/powernv/Kconfig
index 4b044d8..604190c 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -19,3 +19,10 @@ config PPC_POWERNV
select CPU_FREQ_GOV_CONSERVATIVE
select PPC_DOORBELL
default y
+
+config OPAL_PRD
+   tristate 'OPAL PRD driver'
+   depends on PPC_POWERNV
+   help
+ This enables the opal-prd driver, a facility to run processor

[PATCH 2/3 v2] powerpc/powernv: Expose OPAL APIs required by PRD interface

[Jeremy Kerr]

The (upcoming) opal-prd driver needs to access the message notifier and
xscom code, so add EXPORT_SYMBOL_GPL macros for these.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/platforms/powernv/opal.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index b03ac9e..b40624d 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -317,6 +317,7 @@ int opal_message_notifier_register(enum opal_msg_type 
msg_type,
return atomic_notifier_chain_register(
opal_msg_notifier_head[msg_type], nb);
 }
+EXPORT_SYMBOL_GPL(opal_message_notifier_register);
 
 int opal_message_notifier_unregister(enum opal_msg_type msg_type,
 struct notifier_block *nb)
@@ -324,6 +325,7 @@ int opal_message_notifier_unregister(enum opal_msg_type 
msg_type,
return atomic_notifier_chain_unregister(
opal_msg_notifier_head[msg_type], nb);
 }
+EXPORT_SYMBOL_GPL(opal_message_notifier_unregister);
 
 static void opal_message_do_notify(uint32_t msg_type, void *msg)
 {
@@ -867,6 +869,8 @@ void opal_shutdown(void)
 
 /* Export this so that test modules can use it */
 EXPORT_SYMBOL_GPL(opal_invalid_call);
+EXPORT_SYMBOL_GPL(opal_xscom_read);
+EXPORT_SYMBOL_GPL(opal_xscom_write);
 EXPORT_SYMBOL_GPL(opal_ipmi_send);
 EXPORT_SYMBOL_GPL(opal_ipmi_recv);
 EXPORT_SYMBOL_GPL(opal_flash_read);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3 v2] powerpc/powernv: Merge common platform device initialisation

[Jeremy Kerr]

opal_ipmi_init and opal_flash_init are equivalent, except for the
compatbile string. Merge these two into a common opal_pdev_init
function.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/platforms/powernv/opal.c |   21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 2241565..b03ac9e 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -693,21 +693,13 @@ static void __init opal_dump_region_init(void)
rc = %d\n, rc);
 }
 
-static void opal_flash_init(struct device_node *opal_node)
+static void opal_pdev_init(struct device_node *opal_node,
+   const char *compatible)
 {
struct device_node *np;
 
for_each_child_of_node(opal_node, np)
-   if (of_device_is_compatible(np, ibm,opal-flash))
-   of_platform_device_create(np, NULL, NULL);
-}
-
-static void opal_ipmi_init(struct device_node *opal_node)
-{
-   struct device_node *np;
-
-   for_each_child_of_node(opal_node, np)
-   if (of_device_is_compatible(np, ibm,opal-ipmi))
+   if (of_device_is_compatible(np, compatible))
of_platform_device_create(np, NULL, NULL);
 }
 
@@ -835,10 +827,9 @@ static int __init opal_init(void)
opal_msglog_init();
}
 
-   /* Initialize OPAL IPMI backend */
-   opal_ipmi_init(opal_node);
-
-   opal_flash_init(opal_node);
+   /* Initialize platform devices: IPMI backend  flash interface */
+   opal_pdev_init(opal_node, ibm,opal-ipmi);
+   opal_pdev_init(opal_node, ibm,opal-flash);
 
return 0;
 }
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/powernv: Add opal-prd channel

[Jeremy Kerr]

Hi Ben,

 +static LIST_HEAD(opal_prd_msg_queue);
 +static DEFINE_SPINLOCK(opal_prd_msg_queue_lock);
 +static DECLARE_WAIT_QUEUE_HEAD(opal_prd_msg_wait);
 +static atomic_t usage;
 
 opal_prd_usage ... otherwise  it's a mess in the symbols map

OK, I'll change this.

 Also why limit the number of opens ? we might want to have tools using
 the opal prd for xscom :-) (in absence of debugfs). .. as long as not
 two people read() it should be ok. Or a tool to dump the regions etc...
 
 I don't see any reason to block multiple open's.

Simplicity, really. We can do a get exclusive, but there's no
(current) use-case for multiple openers on a PRD interface.

Pulling this thread a little, you've hit on a key decision point of the
prd design - I see there being two directions we could take with this:

 1) This interface is specifically for PRD functions, or

 2) This interface is a generic userspace interface to OPAL,
and PRD is a subset of that.

I've been aiming for (1) with the current code; and the nature of the
generic read()  write() operations being PRD-specific enforces that.

Allowing multiple openers will help with (2), but if we want to go in
that direction, I think we'd be better off doing a couple of other
changes too:

 * move the general functions (eg xscom, range mappings, OCC control)
   to a separate interface that isn't tied to PRD - say just /dev/opal

 * using this prd code for only the prd-event handling, possibly
   renamed to /dev/opal-prd-events. This would still need some
   method of enforcing exclusive access.

In this case, the actual PRD application would use both devices,
dequeueing events (and updating the ipoll mask) from the latter, and
using the former for helper functionality.

Other tools (eg generic xscom access) would just use the generic
interface, and not the PRD one, which wouldn't enforce exclusive access.

Regardless of the choice here, we could also remove the single-open
exclusion, and shift that responsibility to userspace (eg, flock() on
the PRD device node?). The main reason for the exclusion is to prevent
multiple prd daemons running, which may get messy when updating the
ipoll mask.

 Should we rely exclusively on userspace setting the right permissions or
 should we check CAP_SYSADMIN here ?

I'm okay with relying on userspace, is there any reason not to?


 +vma-vm_page_prot = phys_mem_access_prot(file, vma-vm_pgoff,
 + size, vma-vm_page_prot)
 +| _PAGE_SPECIAL;
 +
 +rc = remap_pfn_range(vma, vma-vm_start, vma-vm_pgoff, size,
 +vma-vm_page_prot);
 
 Do we still have the warnings of process exist about the map count or is
 that fixed ?

No, not fixed at present. I'll need to chat to you about that.


 +case OPAL_PRD_SCOM_READ:
 +rc = copy_from_user(scom, (void __user *)param, sizeof(scom));
 +if (rc)
 +return -EFAULT;
 +
 +rc = opal_xscom_read(scom.chip, scom.addr,
 +(__be64 *)scom.data);
 
 Are we exporting these for modules ?

No, but opal-prd isn't configurable as a module at the moment.

 
 +scom.data = be64_to_cpu(scom.data);
 +pr_debug(ioctl SCOM_READ: chip %llx addr %016llx 
 +data %016llx rc %d\n,
 +scom.chip, scom.addr, scom.data, rc);
 
 pr_devel ?

This removes the possibility of CONFIG_DYNAMIC_DEBUG, is that intentional?

 
 +if (rc)
 +return -EIO;
 
 Should we consider returning more info about the SCOM error ? HBRT might
 actually need that... Maybe opal_prd_scom needs a field for the OPAL rc
 which is currently not very descriptive but that's fixable.

Sounds good, I'll add that in. On error, we'll return -EIO and have the
OPAL error code in the struct for further detail.


 +nr_ranges = of_property_count_strings(np, reserved-names);
 +ranges_prop = of_get_property(np, reserved-ranges, NULL);
 +if (!ranges_prop) {
 +of_node_put(np);
 +return -ENODEV;
 +}
 
 Didn't we say we had a problem with using those properties due to
 coalescing ? Shouldn't we define specific ones for the HBRT regions ?

There's not a problem at the moment, but one day we will need to expand
the PRD's get_reserved_mem interface to allow per-chip ranges. This
would use a different device-tree representation.

However, I think it'd be better to remove this code entirely (ie, remove
the range member of struct opal_prd_info), and require userspace to do
the device-tree parsing.

 +static int __init opal_prd_init(void)
 +{
 +int rc;
 +
 +/* parse the code region information from the device tree */
 +rc = parse_regions();
 +if (rc) {
 +pr_err(Couldn't parse region information from DT\n);
 +return rc;
 +}
 
 Should we create a virtual device under the OPAL node in FW so we have
 something to attach to ? 

Re: [PATCH] powerpc/cell: Drop cbe-oss-dev mailing list from MAINTAINERS

[Jeremy Kerr]

Hi Michael,

 Traffic on the cbe-oss-dev list is more or less non-existent, other than
 CC's from linuxppc.

Plus all that spam that never makes it out of the moderation queue.

 It's seems like we may as well just send everyone to linuxppc and
 archive the list.

Acked-by: Jeremy Kerr j...@ozlabs.org

[This'll get a mention at our returning from prom_init-farewell party
too, right?]

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/2] Add a MTD driver for OpenPower PNOR flash

[Jeremy Kerr]

Hi all,

 If the mtd maintainers are happy with it this would be the easier approach in
 this instance.

OK, sounds good to me.

MTD folks: any objections to this process? If not, is this patch good to
go in, or any changes we should make?

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] powerpc/powernv: Add interfaces for flash device access

[Jeremy Kerr]

From: Cyril Bur cyril...@gmail.com

This change adds the OPAL interface definitions to allow Linux to read,
write and erase from system flash devices. We register platform devices
for the flash devices exported by firmware.

We clash with the existing opal_flash_init function, which is really for
the FSP flash update functionality, so we rename that initcall to
opal_flash_update_init().

A future change will add an mtd driver that uses this interface.

Changes from Joel Stanley and Jeremy Kerr.

Signed-off-by: Cyril Bur cyril...@gmail.com
Signed-off-by: Jeremy Kerr j...@ozlabs.org
Signed-off-by: Joel Stanley j...@jms.id.au

---
 arch/powerpc/include/asm/opal-api.h|5 -
 arch/powerpc/include/asm/opal.h|9 -
 arch/powerpc/platforms/powernv/opal-flash.c|2 +-
 arch/powerpc/platforms/powernv/opal-wrappers.S |3 +++
 arch/powerpc/platforms/powernv/opal.c  |   16 +++-
 5 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index e8a6baf..0321a90 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -150,7 +150,10 @@
 #define OPAL_IPMI_SEND 107
 #define OPAL_IPMI_RECV 108
 #define OPAL_I2C_REQUEST   109
-#define OPAL_LAST  109
+#define OPAL_FLASH_READ110
+#define OPAL_FLASH_WRITE   111
+#define OPAL_FLASH_ERASE   112
+#define OPAL_LAST  112
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index c08de77..7c6d7ea 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -194,6 +194,13 @@ int64_t opal_ipmi_recv(uint64_t interface, struct 
opal_ipmi_msg *msg,
 int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
 struct opal_i2c_request *oreq);
 
+int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
+   uint64_t size, uint64_t token);
+int64_t opal_flash_write(uint64_t id, uint64_t offset, uint64_t buf,
+   uint64_t size, uint64_t token);
+int64_t opal_flash_erase(uint64_t id, uint64_t offset, uint64_t size,
+   uint64_t token);
+
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
   int depth, void *data);
@@ -226,7 +233,7 @@ extern int opal_get_sensor_data(u32 sensor_hndl, u32 
*sensor_data);
 struct rtc_time;
 extern unsigned long opal_get_boot_time(void);
 extern void opal_nvram_init(void);
-extern void opal_flash_init(void);
+extern void opal_flash_update_init(void);
 extern void opal_flash_term_callback(void);
 extern int opal_elog_init(void);
 extern void opal_platform_dump_init(void);
diff --git a/arch/powerpc/platforms/powernv/opal-flash.c 
b/arch/powerpc/platforms/powernv/opal-flash.c
index 0ff07ff..4ec6219 100644
--- a/arch/powerpc/platforms/powernv/opal-flash.c
+++ b/arch/powerpc/platforms/powernv/opal-flash.c
@@ -546,7 +546,7 @@ static struct attribute_group image_op_attr_group = {
.attrs = image_op_attrs,
 };
 
-void __init opal_flash_init(void)
+void __init opal_flash_update_init(void)
 {
int ret;
 
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index b23fe7c..4e74037 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -292,3 +292,6 @@ OPAL_CALL(opal_tpo_read,OPAL_READ_TPO);
 OPAL_CALL(opal_ipmi_send,  OPAL_IPMI_SEND);
 OPAL_CALL(opal_ipmi_recv,  OPAL_IPMI_RECV);
 OPAL_CALL(opal_i2c_request,OPAL_I2C_REQUEST);
+OPAL_CALL(opal_flash_read, OPAL_FLASH_READ);
+OPAL_CALL(opal_flash_write,OPAL_FLASH_WRITE);
+OPAL_CALL(opal_flash_erase,OPAL_FLASH_ERASE);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index d403b2b..e95342b 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -693,6 +693,15 @@ static void __init opal_dump_region_init(void)
rc = %d\n, rc);
 }
 
+static void opal_flash_init(struct device_node *opal_node)
+{
+   struct device_node *np;
+
+   for_each_child_of_node(opal_node, np)
+   if (of_device_is_compatible(np, ibm,opal-flash))
+   of_platform_device_create(np, NULL, NULL);
+}
+
 static void opal_ipmi_init(struct device_node *opal_node)
 {
struct device_node *np;
@@ -817,7 +826,7 @@ static int __init opal_init(void)
/* Setup error log interface */
rc = opal_elog_init

[PATCH 0/2] Add a MTD driver for OpenPower PNOR flash

[Jeremy Kerr]

Hi all,

This series implements a simple mtd device to allow access to the PNOR
flash on OpenPower machines. The flash is accessed through firmware
calls.

Patch 1/2 adds the Linux interface to these calls. Patch 2/2 adds a mtd
driver that uses these calls.

Because there's two subsystems involved here, there are a couple of
methods to merge this:

 1) The powerpc folks take 1/2, and the mtd folks take 2/2, to be
applied once 1/2 is available (Michael has created a topic branch for
this in the past, which can make things a little easier), or

 2) One of the maintainers takes both patches, once the other has acked
their patch. I'd suggest that it goes through the powerpc tree in
this case, as that will be less likely to conflict.

Either way, I'm happy.

Cheers,


Jeremy

---
Cyril Bur (2):
  powerpc/powernv: Add interfaces for flash device access
  drivers/mtd: add powernv flash MTD abstraction driver

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Reword the returning from prom_init message

[Jeremy Kerr]

Hi Michael,

 Let's try something different.
 
 This prints:
 
   Quiescing Open Firmware ...
   Booting Linux via __start() ...

returning from prom_init has been an emblem of the powerpc kernel boot
since old times. I feel like we should give the old message a Viking
funeral and pick a date for a minute of silence.

(Wistfully-)Acked-by: Jeremy Kerr j...@ozlabs.org

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/powernv: Add opal-prd channel

[Jeremy Kerr]

This change adds a char device to access the PRD (processor runtime
diagnostics) channel to OPAL firmware.

Includes contributions from Vaidyanathan Srinivasan, Neelesh Gupta 
Vishal Kulkarni.

Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/include/asm/opal-api.h|   40 +
 arch/powerpc/include/asm/opal.h|1 
 arch/powerpc/include/uapi/asm/opal-prd.h   |   57 ++
 arch/powerpc/platforms/powernv/Makefile|2 
 arch/powerpc/platforms/powernv/opal-prd.c  |  440 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |1 
 6 files changed, 539 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..b787b95 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -153,7 +153,8 @@
 #define OPAL_FLASH_READ110
 #define OPAL_FLASH_WRITE   111
 #define OPAL_FLASH_ERASE   112
-#define OPAL_LAST  112
+#define OPAL_PRD_MSG   113
+#define OPAL_LAST  113
 
 /* Device tree flags */
 
@@ -352,6 +353,7 @@ enum opal_msg_type {
OPAL_MSG_SHUTDOWN,  /* params[0] = 1 reboot, 0 shutdown */
OPAL_MSG_HMI_EVT,
OPAL_MSG_DPO,
+   OPAL_MSG_PRD,
OPAL_MSG_TYPE_MAX,
 };
 
@@ -674,6 +676,42 @@ typedef struct oppanel_line {
__be64 line_len;
 } oppanel_line_t;
 
+enum opal_prd_msg_type {
+   OPAL_PRD_MSG_TYPE_INIT = 0, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_FINI, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_ATTN_ACK, /* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_ERROR,/* HBRT -- OPAL */
+   OPAL_PRD_MSG_TYPE_OCC_RESET,/* HBRT -- OPAL */
+};
+
+struct opal_prd_msg {
+   uint8_t type;
+   uint8_t pad[3];
+   __be32  token;
+   union {
+   struct {
+   __be64  version;
+   __be64  ipoll;
+   } init;
+   struct {
+   __be64  proc;
+   __be64  ipoll_status;
+   __be64  ipoll_mask;
+   } attn;
+   struct {
+   __be64  proc;
+   __be64  ipoll_ack;
+   } attn_ack;
+   struct {
+   __be64  chip;
+   } occ_error;
+   struct {
+   __be64  chip;
+   } occ_reset;
+   };
+};
+
 /*
  * SG entries
  *
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 7c6d7ea..4375cb4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -193,6 +193,7 @@ int64_t opal_ipmi_recv(uint64_t interface, struct 
opal_ipmi_msg *msg,
uint64_t *msg_len);
 int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
 struct opal_i2c_request *oreq);
+int64_t opal_prd_msg(struct opal_prd_msg *msg);
 
 int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/include/uapi/asm/opal-prd.h 
b/arch/powerpc/include/uapi/asm/opal-prd.h
new file mode 100644
index 000..938af8e
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-prd.h
@@ -0,0 +1,57 @@
+/*
+ * OPAL Runtime Diagnostics interface driver
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2015
+ *
+ * Author: Vaidyanathan Srinivasan svaidy at linux.vnet.ibm.com
+ * Author: Jeremy Kerr j...@ozlabs.org
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_PRD_H_
+#define _UAPI_ASM_POWERPC_OPAL_PRD_H_
+
+#include linux/types.h
+
+#define OPAL_PRD_VERSION   1
+#define OPAL_PRD_RANGE_NAME_LEN32
+#define OPAL_PRD_MAX_RANGES8
+
+#define OPAL_PRD_GET_INFO  _IOR('o', 0x01, struct opal_prd_info)
+#define OPAL_PRD_SCOM_READ _IOR('o', 0x10, struct opal_prd_scom)
+#define OPAL_PRD_SCOM_WRITE_IOW('o', 0x11, struct opal_prd_scom)
+
+#ifndef __ASSEMBLY__
+
+struct opal_prd_range {
+   charname[OPAL_PRD_RANGE_NAME_LEN];
+   __u64   physaddr;
+   __u64   size;
+};
+
+struct

[PATCH 2/2] drivers/mtd: add powernv flash MTD abstraction driver

[Jeremy Kerr]

From: Cyril Bur cyril...@gmail.com

Powerpc powernv platforms allow access to certain system flash devices
through a firmwarwe interface. This change adds an mtd driver for these
flash devices.

Minor updates from Jeremy Kerr and Joel Stanley.

Signed-off-by: Cyril Bur cyril...@gmail.com
Signed-off-by: Joel Stanley j...@jms.id.au
Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 drivers/mtd/devices/Kconfig |6 
 drivers/mtd/devices/Makefile|1 
 drivers/mtd/devices/powernv_flash.c |  288 
 3 files changed, 295 insertions(+)

diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index c49d0b1..5065e7c 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -195,6 +195,12 @@ config MTD_BLOCK2MTD
  Testing MTD users (eg JFFS2) on large media and media that might
  be removed during a write (using the floppy drive).
 
+config MTD_POWERNV_FLASH
+   tristate powernv flash MTD driver
+   depends on PPC_POWERNV
+   help
+ This provides an MTD device for flash on powernv OPAL platforms
+
 comment Disk-On-Chip Device Drivers
 
 config MTD_DOCG3
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index f0b0e61..7912d3a 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_MTD_SPEAR_SMI)   += spear_smi.o
 obj-$(CONFIG_MTD_SST25L)   += sst25l.o
 obj-$(CONFIG_MTD_BCM47XXSFLASH)+= bcm47xxsflash.o
 obj-$(CONFIG_MTD_ST_SPI_FSM)+= st_spi_fsm.o
+obj-$(CONFIG_MTD_POWERNV_FLASH)+= powernv_flash.o
 
 
 CFLAGS_docg3.o += -I$(src)
diff --git a/drivers/mtd/devices/powernv_flash.c 
b/drivers/mtd/devices/powernv_flash.c
new file mode 100644
index 000..18f8a19
--- /dev/null
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -0,0 +1,288 @@
+/*
+ * OPAL PNOR flash MTD abstraction
+ *
+ * IBM 2015
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/string.h
+#include linux/slab.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+#include asm/opal.h
+
+
+/*
+ * This driver creates the a Linux MTD abstraction for platform PNOR flash
+ * backed by OPAL calls
+ */
+
+struct powernv_flash {
+   struct mtd_info mtd;
+   uint64_tid;
+};
+
+enum flash_op {
+   FLASH_OP_READ,
+   FLASH_OP_WRITE,
+   FLASH_OP_ERASE,
+};
+
+static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
+   loff_t offset, size_t len, size_t *retlen, u_char *buf)
+{
+   struct powernv_flash *info = (struct powernv_flash *)mtd-priv;
+   struct device *dev = mtd-dev;
+   int token;
+   struct opal_msg msg;
+   int rc;
+
+   dev_dbg(dev, %s(op=%d, offset=0x%llx, len=%zu)\n,
+   __func__, op, offset, len);
+
+   token = opal_async_get_token_interruptible();
+   if (token  0) {
+   dev_err(dev, Failed to get an async token\n);
+   return -ENOMEM;
+   }
+
+   switch (op) {
+   case FLASH_OP_READ:
+   rc = opal_flash_read(info-id, offset, __pa(buf), len, token);
+   break;
+   case FLASH_OP_WRITE:
+   rc = opal_flash_write(info-id, offset, __pa(buf), len, token);
+   break;
+   case FLASH_OP_ERASE:
+   rc = opal_flash_erase(info-id, offset, len, token);
+   break;
+   default:
+   BUG_ON(1);
+   }
+
+   if (rc != OPAL_ASYNC_COMPLETION) {
+   dev_err(dev, opal_flash_async_op(op=%d) failed (rc %d)\n,
+   op, rc);
+   return -EIO;
+   }
+
+   rc = opal_async_wait_response(token, msg);
+   opal_async_release_token(token);
+   if (rc) {
+   dev_err(dev, opal async wait failed (rc %d)\n, rc);
+   return -EIO;
+   }
+
+   rc = be64_to_cpu(msg.params[1]);
+   if (rc == OPAL_SUCCESS) {
+   rc = 0;
+   if (retlen)
+   *retlen = len;
+   } else

Re: [PATCH] powerpc: Remove the celleb support

[Jeremy Kerr]

Hi Michael,

 The celleb code has seen no actual development for ~7 years.
 
 We (maintainers) have no access to test hardware, and it is highly
 likely the code has bit-rotted.
 
 As far as we're aware the hardware was never widely available, and is
 certainly no longer available, and no one on the list has shown any
 interest in it over the years.
 
 So remove it. If anyone has one and cares please speak up.

I've never had any spufs-related feedback from celleb platforms either.

Acked-by: Jeremy Kerr j...@ozlabs.org

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/4] powerpc/boot: don't clobber r6 and r7 in epapr boot

[Jeremy Kerr]

Hi Ben,

 You might want to also remove the use of r8 and r9 which are supposed
 to contain the OPAL entry and base for debugging purposes. We would also
 have to restore them before booting the kernel.

I'd prefer that to be a separate change, if that's okay - it'd require
us to change the kentry prototype, and would percolate to epapr_platform
init too.

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/4] powerpc/boot/wrapper: use the pseries wrapper for zImage.epapr

[Jeremy Kerr]

Hi Ben,

 We'll likely be entering the zImage.epapr as BE, so include the pseries
 implementation of _zimage_start, which adds the endian fixup magic.
 
 Wont that break embedded epapr stuff ?

How so? This will just give us the endian fixup trampoline (followed by
a branch to _zimage_start_lib) as the entry point, rather than directly
entering _zimage_start_lib. Will that not work on embedded?

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/4] powerpc/boot/wrapper: use the pseries wrapper for zImage.epapr

[Jeremy Kerr]

We'll likely be entering the zImage.epapr as BE, so include the pseries
implementation of _zimage_start, which adds the endian fixup magic.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/wrapper |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index ae0f88e..3f50c27 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -277,7 +277,7 @@ treeboot-iss4xx-mpic)
 platformo=$object/treeboot-iss4xx.o
 ;;
 epapr)
-platformo=$object/epapr.o $object/epapr-wrapper.o
+platformo=$object/pseries-head.o $object/epapr.o $object/epapr-wrapper.o
 link_address='0x2000'
 pie=-pie
 ;;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/4] powerpc/boot/fdt: Add little-endian support to libfdt wrappers

[Jeremy Kerr]

For epapr-style boot, we may be little-endian. This change implements
the proper conversion for fdt*_to_cpu and cpu_to_fdt*. We also need the
full cpu_to_* and *_to_cpu macros for this.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/libfdt_env.h |   14 --
 arch/powerpc/boot/of.h |8 
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/libfdt_env.h b/arch/powerpc/boot/libfdt_env.h
index c89fdb1..8dcd744 100644
--- a/arch/powerpc/boot/libfdt_env.h
+++ b/arch/powerpc/boot/libfdt_env.h
@@ -4,15 +4,17 @@
 #include types.h
 #include string.h
 
+#include of.h
+
 typedef u32 uint32_t;
 typedef u64 uint64_t;
 typedef unsigned long uintptr_t;
 
-#define fdt16_to_cpu(x)(x)
-#define cpu_to_fdt16(x)(x)
-#define fdt32_to_cpu(x)(x)
-#define cpu_to_fdt32(x)(x)
-#define fdt64_to_cpu(x)(x)
-#define cpu_to_fdt64(x)(x)
+#define fdt16_to_cpu(x)be16_to_cpu(x)
+#define cpu_to_fdt16(x)cpu_to_be16(x)
+#define fdt32_to_cpu(x)be32_to_cpu(x)
+#define cpu_to_fdt32(x)cpu_to_be32(x)
+#define fdt64_to_cpu(x)be64_to_cpu(x)
+#define cpu_to_fdt64(x)cpu_to_be64(x)
 
 #endif /* _ARCH_POWERPC_BOOT_LIBFDT_ENV_H */
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
index c8c1750..5603320 100644
--- a/arch/powerpc/boot/of.h
+++ b/arch/powerpc/boot/of.h
@@ -24,11 +24,19 @@ void of_console_init(void);
 typedef u32__be32;
 
 #ifdef __LITTLE_ENDIAN__
+#define cpu_to_be16(x) swab16(x)
+#define be16_to_cpu(x) swab16(x)
 #define cpu_to_be32(x) swab32(x)
 #define be32_to_cpu(x) swab32(x)
+#define cpu_to_be64(x) swab64(x)
+#define be64_to_cpu(x) swab64(x)
 #else
+#define cpu_to_be16(x) (x)
+#define be16_to_cpu(x) (x)
 #define cpu_to_be32(x) (x)
 #define be32_to_cpu(x) (x)
+#define cpu_to_be64(x) (x)
+#define be64_to_cpu(x) (x)
 #endif
 
 #define PROM_ERROR (-1u)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/4] powerpc/boot: Fix stack corruption in epapr entry point

[Jeremy Kerr]

Currently, a 64-bit little-endian zImage.epapr won't boot in epapr mode,
as as we never return from platform_init.

Before entering C, we initialise our stack by setting r1 16 bytes below
the end of the _bss_stack:

  stwu  r0,-16(r1)  /* establish a stack frame */

However, the called function will save the caller's lr in the caller's
frame's lr save area, at -16(r1) to -32(r1).

This means that writes to the fdt variable corrupt the saved link
register:

 20c06018 l O .bss   1000 _bss_stack
 20c07018 l O .bss   0008 fdt

This change allocates the minimum of 32 bytes for the base of the stack
instead.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/crt0.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 14de4f8..bf8 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -218,7 +218,7 @@ p_base: mflrr10 /* r10 now points to 
runtime addr of p_base */
beq 6f
ld  r1,0(r8)
li  r0,0
-   stdur0,-16(r1)  /* establish a stack frame */
+   stdur0,-32(r1)  /* establish a stack frame */
 6:
 #endif  /* __powerpc64__ */
/* Call platform_init() */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/5 v2] powerpc/boot: Fix stack corruption in epapr entry point

[Jeremy Kerr]

Currently, a 64-bit little-endian zImage.epapr won't boot in epapr mode,
as we never return from platform_init.

Before entering C, we initialise our stack by setting r1 16 bytes below
the end of the _bss_stack:

  stwu  r0,-16(r1)  /* establish a stack frame */

However, the called function will save the caller's lr in the caller's
frame's lr save area, at -16(r1) to -32(r1).

This means that writes to the fdt variable will corrupt the saved link
register:

 20c06018 l O .bss   1000 _bss_stack
 20c07018 l O .bss   0008 fdt

We'll need at least 32 bytes in the initial stack frame, to handle the
LR save area. We bump this to 112 bytes, as that'll be the max required
by ABIv1.

Thanks to Alistair Popple for debugging help.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/crt0.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 14de4f8..e004062 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -218,7 +218,7 @@ p_base: mflrr10 /* r10 now points to 
runtime addr of p_base */
beq 6f
ld  r1,0(r8)
li  r0,0
-   stdur0,-16(r1)  /* establish a stack frame */
+   stdur0,-112(r1) /* establish a stack frame */
 6:
 #endif  /* __powerpc64__ */
/* Call platform_init() */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/5 v2] powerpc/boot/fdt: Use unsigned long for pointer casts

[Jeremy Kerr]

Now that the wrapper supports 64-bit builds, we see warnings when
attempting to cast pointers to int. Use unsigned long instead.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/libfdt-wrapper.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/libfdt-wrapper.c 
b/arch/powerpc/boot/libfdt-wrapper.c
index bb8b9b3..535e8fd 100644
--- a/arch/powerpc/boot/libfdt-wrapper.c
+++ b/arch/powerpc/boot/libfdt-wrapper.c
@@ -44,12 +44,12 @@
 
 #define offset_devp(off)   \
({ \
-   int _offset = (off); \
+   unsigned long _offset = (off); \
check_err(_offset) ? NULL : (void *)(_offset+1); \
})
 
-#define devp_offset_find(devp) (((int)(devp))-1)
-#define devp_offset(devp)  (devp ? ((int)(devp))-1 : 0)
+#define devp_offset_find(devp) (((unsigned long)(devp))-1)
+#define devp_offset(devp)  (devp ? ((unsigned long)(devp))-1 : 0)
 
 static void *fdt;
 static void *buf; /* = NULL */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 5/5 v2] powerpc/boot: don't clobber r6 and r7 in epapr boot

[Jeremy Kerr]

We use r6 and r7 for epapr boot, but the current pre-C init will clobber
both of these.

This change does a simple replacement, of r6 - r12 and r7 - r13, so
that we hit platform init with these registers intact.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/crt0.S |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index e004062..12866cc 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -155,29 +155,29 @@ p_base:   mflrr10 /* r10 now points to 
runtime addr of p_base */
ld  r9,(p_rela-p_base)(r10)
add r9,r9,r10
 
-   li  r7,0
+   li  r13,0
li  r8,0
-9: ld  r6,0(r11)   /* get tag */
-   cmpdi   r6,0
+9: ld  r12,0(r11)   /* get tag */
+   cmpdi   r12,0
beq 12f  /* end of list */
-   cmpdi   r6,RELA
+   cmpdi   r12,RELA
bne 10f
-   ld  r7,8(r11)   /* get RELA pointer in r7 */
+   ld  r13,8(r11)   /* get RELA pointer in r13 */
b   11f
-10:addis   r6,r6,(-RELACOUNT)@ha
-   cmpdi   r6,RELACOUNT@l
+10:addis   r12,r12,(-RELACOUNT)@ha
+   cmpdi   r12,RELACOUNT@l
bne 11f
ld  r8,8(r11)   /* get RELACOUNT value in r8 */
 11:addir11,r11,16
b   9b
 12:
-   cmpdi   r7,0/* check we have both RELA and RELACOUNT */
+   cmpdi   r13,0/* check we have both RELA and RELACOUNT */
cmpdi   cr1,r8,0
beq 3f
beq cr1,3f
 
/* Calcuate the runtime offset. */
-   subfr7,r7,r9
+   subfr13,r13,r9
 
/* Run through the list of relocations and process the
 * R_PPC64_RELATIVE ones. */
@@ -185,10 +185,10 @@ p_base:   mflrr10 /* r10 now points to 
runtime addr of p_base */
 13:ld  r0,8(r9)/* ELF64_R_TYPE(reloc-r_info) */
cmpdi   r0,22   /* R_PPC64_RELATIVE */
bne 3f
-   ld  r6,0(r9)/* reloc-r_offset */
+   ld  r12,0(r9)/* reloc-r_offset */
ld  r0,16(r9)   /* reloc-r_addend */
-   add r0,r0,r7
-   stdxr0,r7,r6
+   add r0,r0,r13
+   stdxr0,r13,r12
addir9,r9,24
bdnz13b
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/5 v2] powerpc/boot/wrapper: use the pseries wrapper for zImage.epapr

[Jeremy Kerr]

We'll likely be entering the zImage.epapr as BE, so include the pseries
implementation of _zimage_start, which adds the endian fixup magic.

Although the endian fixup won't work on Book III-E machines starting LE,
the current entry point doesn't support LE anyway, so we shouldn't be
breaking anything.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/wrapper |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index ae0f88e..3f50c27 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -277,7 +277,7 @@ treeboot-iss4xx-mpic)
 platformo=$object/treeboot-iss4xx.o
 ;;
 epapr)
-platformo=$object/epapr.o $object/epapr-wrapper.o
+platformo=$object/pseries-head.o $object/epapr.o $object/epapr-wrapper.o
 link_address='0x2000'
 pie=-pie
 ;;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/5 v2] powerpc/boot/fdt: Add little-endian support to libfdt wrappers

[Jeremy Kerr]

For epapr-style boot, we may be little-endian. This change implements
the proper conversion for fdt*_to_cpu and cpu_to_fdt*. We also need the
full cpu_to_* and *_to_cpu macros for this.

Signed-off-by: Jeremy Kerr j...@ozlabs.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org

---
 arch/powerpc/boot/libfdt_env.h |   14 --
 arch/powerpc/boot/of.h |8 
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/libfdt_env.h b/arch/powerpc/boot/libfdt_env.h
index c89fdb1..8dcd744 100644
--- a/arch/powerpc/boot/libfdt_env.h
+++ b/arch/powerpc/boot/libfdt_env.h
@@ -4,15 +4,17 @@
 #include types.h
 #include string.h
 
+#include of.h
+
 typedef u32 uint32_t;
 typedef u64 uint64_t;
 typedef unsigned long uintptr_t;
 
-#define fdt16_to_cpu(x)(x)
-#define cpu_to_fdt16(x)(x)
-#define fdt32_to_cpu(x)(x)
-#define cpu_to_fdt32(x)(x)
-#define fdt64_to_cpu(x)(x)
-#define cpu_to_fdt64(x)(x)
+#define fdt16_to_cpu(x)be16_to_cpu(x)
+#define cpu_to_fdt16(x)cpu_to_be16(x)
+#define fdt32_to_cpu(x)be32_to_cpu(x)
+#define cpu_to_fdt32(x)cpu_to_be32(x)
+#define fdt64_to_cpu(x)be64_to_cpu(x)
+#define cpu_to_fdt64(x)cpu_to_be64(x)
 
 #endif /* _ARCH_POWERPC_BOOT_LIBFDT_ENV_H */
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
index c8c1750..5603320 100644
--- a/arch/powerpc/boot/of.h
+++ b/arch/powerpc/boot/of.h
@@ -24,11 +24,19 @@ void of_console_init(void);
 typedef u32__be32;
 
 #ifdef __LITTLE_ENDIAN__
+#define cpu_to_be16(x) swab16(x)
+#define be16_to_cpu(x) swab16(x)
 #define cpu_to_be32(x) swab32(x)
 #define be32_to_cpu(x) swab32(x)
+#define cpu_to_be64(x) swab64(x)
+#define be64_to_cpu(x) swab64(x)
 #else
+#define cpu_to_be16(x) (x)
+#define be16_to_cpu(x) (x)
 #define cpu_to_be32(x) (x)
 #define be32_to_cpu(x) (x)
+#define cpu_to_be64(x) (x)
+#define be64_to_cpu(x) (x)
 #endif
 
 #define PROM_ERROR (-1u)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/4] powerpc/boot: don't clobber r6 and r7 in epapr boot

[Jeremy Kerr]

We use r6 and r7 for epapr boot, but the current pre-C init will clobber
both of these.

This change does a simple replacement, of r6 - r12 and r7 - r13, so
that we hit platform init with these registers intact.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/boot/crt0.S |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index bf8..7e50211 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -155,29 +155,29 @@ p_base:   mflrr10 /* r10 now points to 
runtime addr of p_base */
ld  r9,(p_rela-p_base)(r10)
add r9,r9,r10
 
-   li  r7,0
+   li  r13,0
li  r8,0
-9: ld  r6,0(r11)   /* get tag */
-   cmpdi   r6,0
+9: ld  r12,0(r11)   /* get tag */
+   cmpdi   r12,0
beq 12f  /* end of list */
-   cmpdi   r6,RELA
+   cmpdi   r12,RELA
bne 10f
-   ld  r7,8(r11)   /* get RELA pointer in r7 */
+   ld  r13,8(r11)   /* get RELA pointer in r13 */
b   11f
-10:addis   r6,r6,(-RELACOUNT)@ha
-   cmpdi   r6,RELACOUNT@l
+10:addis   r12,r12,(-RELACOUNT)@ha
+   cmpdi   r12,RELACOUNT@l
bne 11f
ld  r8,8(r11)   /* get RELACOUNT value in r8 */
 11:addir11,r11,16
b   9b
 12:
-   cmpdi   r7,0/* check we have both RELA and RELACOUNT */
+   cmpdi   r13,0/* check we have both RELA and RELACOUNT */
cmpdi   cr1,r8,0
beq 3f
beq cr1,3f
 
/* Calcuate the runtime offset. */
-   subfr7,r7,r9
+   subfr13,r13,r9
 
/* Run through the list of relocations and process the
 * R_PPC64_RELATIVE ones. */
@@ -185,10 +185,10 @@ p_base:   mflrr10 /* r10 now points to 
runtime addr of p_base */
 13:ld  r0,8(r9)/* ELF64_R_TYPE(reloc-r_info) */
cmpdi   r0,22   /* R_PPC64_RELATIVE */
bne 3f
-   ld  r6,0(r9)/* reloc-r_offset */
+   ld  r12,0(r9)/* reloc-r_offset */
ld  r0,16(r9)   /* reloc-r_addend */
-   add r0,r0,r7
-   stdxr0,r7,r6
+   add r0,r0,r13
+   stdxr0,r13,r12
addir9,r9,24
bdnz13b
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V3] powerpc, powernv: Add OPAL platform event driver

[Jeremy Kerr]

Hi Anshuman,

 This patch creates a new OPAL platform event character driver
 which will give userspace clients the access to these events
 and process them effectively. Following platforms events are
 currently supported with this platform driver.
 
   (1) Environmental and Power Warning (EPOW)
   (2) Delayed Power Off (DPO)
 
 The user interface for this driver is /dev/opal_event character
 device file where the user space clients can poll and read for
 new opal platform events. The expected sequence of events driven
 from user space should be like the following.
 
   (1) Open the character device file
   (2) Poll on the file for POLLIN event
   (3) When unblocked, must attempt to read PLAT_EVENT_MAX_SIZE size
   (4) Kernel driver will pass at most one opal_plat_event structure
   (5) Poll again for more new events

Why is the poll() required? Can't read() just block if there are no
events (and !O_NONBLOCK, of course).

 @@ -281,6 +282,7 @@ enum OpalMessageType {
   OPAL_MSG_EPOW,
   OPAL_MSG_SHUTDOWN,
   OPAL_MSG_HMI_EVT,
 + OPAL_MSG_DPO,
   OPAL_MSG_TYPE_MAX,
  };

I'd suggest adding the DPO interface definitions as a separate change,
but that's no huge deal.

  
 @@ -452,6 +454,46 @@ struct opal_msg {
   __be64 params[8];
  };
  
 +/*
 + * EPOW status sharing (OPAL and the host)
 + *
 + * The host will pass on OPAL, a buffer of length OPAL_SYSEPOW_MAX
 + * with individual elements being 16 bits wide to fetch the system
 + * wide EPOW status. Each element in the buffer will contain the
 + * EPOW status in it's bit representation for a particular EPOW sub
 + * class as defiend here. So multiple detailed EPOW status bits
 + * specific for any sub class can be represented in a single buffer
 + * element as it's bit representation.
 + */

Why do we have this in separate u16s? This just results in a really
sparse bitmask.

I guess the FW interface is already defined though, right?

[Minor grammar nit: it's is short for it is, which isn't what you
want here :)]

 -int64_t opal_get_epow_status(__be64 *status);
 +int64_t opal_get_epow_status(uint16_t *status, uint16_t *length);

Please keep the endian annotations there.

 +int64_t opal_get_dpo_status(int64_t *dpo_timeout);

and __be64 * here.

 +
 +/* EPOW classification */
 +enum epow_condition {
 + EPOW_SYSPOWER_CHNG  = 0,/* Power */
 + EPOW_SYSPOWER_FAIL  = 1,
 + EPOW_SYSPOWER_INCL  = 2,
 + EPOW_SYSPOWER_UPS   = 3,
 + EPOW_SYSTEMP_AMB= 4,/* Temperature */
 + EPOW_SYSTEMP_INT= 5,
 + EPOW_SYSTEMP_HMD= 6,
 + EPOW_SYSCOOL_INSF   = 7,/* Cooling */
 + EPOW_MAX = 8,
 +};
 +
 +/* OPAL EPOW event */
 +struct epow_event {
 + __u64   epow[EPOW_MAX]; /* Detailed system EPOW status */

Why an array of u64s when you're only using one bit of each? Do we
expect other status details to be set in each of these?

If not, you're converting from one sparse bitmask (the OPAL
interface) to another different sparse bitmask (the kernel interface).
Either keep them the same, or use a more sensible format.

Also, are you expecting a single epow_event to have multiple conditons
set? If not, no need for a bitmask at all.

 + __u64   timeout;/* Timeout to shutdown in secs */
 +};
 +
 +/* OPAL DPO event */
 +struct dpo_event {
 + __u64   orig_timeout;   /* Platform provided timeout in secs */
 + __u64   remain_timeout; /* Timeout to shutdown in secs */
 +};

Will all of these events have a timeout? If so, just put a timeout in
struct opal_plat_event.

Why does the DPO timeout have orig/remain timeouts, but not the EPOW one?

See below, but perhaps we want a absolute timeout here, instead of
relative? (which is essentially invalid as soon as you've read it).

 +
 +/* OPAL event */
 +struct opal_plat_event {
 + __u32   type;   /* Type of OPAL platform event */
 +#define OPAL_PLAT_EVENT_TYPE_EPOW0
 +#define OPAL_PLAT_EVENT_TYPE_DPO 1
 +#define OPAL_PLAT_EVENT_TYPE_MAX 2
 + __u32   size;   /* Size of OPAL platform event */
 + union {
 + struct epow_event epow; /* EPOW platform event */
 + struct dpo_event  dpo;  /* DPO platform event */
 + };
 +};
 +
 +/*
 + * Suggested read size
 + *
 + * The user space client should attempt to read OPAL_PLAT_EVENT_READ_SIZE
 + * amount of data from the character device file '/dev/opal_event' at any
 + * point of time. The kernel driver will pass an entire opal_plat_event
 + * structure in every read. This ensures that minium data the user space
 + * client gets from the kernel is one opal_plat_event structure.
 + */
 +#define  PLAT_EVENT_MAX_SIZE 4096

- OPAL_PLAT_EVENT_MAX_SIZE - this it a global header.

 +/*
 + * opal_event_read
 + *
 + * User client needs to attempt to read PLAT_EVENT_MAX_SIZE amount of data
 + * from the file descriptor at a time. The driver will 

Re: [PATCH v2] drivers/char/ipmi: Add powernv IPMI driver

[Jeremy Kerr]

Hi Corey,

 This looks good.  Can this go into the IPMI tree now, or does it need
 work done in the PowerPC tree first?

The 1/2 patch is already in the powerpc tree - but to ensure that we hit
Linus' tree in the right order, Michael has suggested that you merge his
topic branch (which only has that one change):


https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=topic/opal-ipmi

- then apply the patch. This way, whichever tree Linus pulls first will
have the changes in the correct order.

Cheers,


Jeremy


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/2] Add IPMI support for powernv powerpc machines

[Jeremy Kerr]

Hi Corey,

 Alternatively, they could be merged by one maintainer, pending an ack
 from the other.

 I'm fine either way.
 
 How about the third option? :)
 
 I've put patch 1 in a topic branch:
 
   
 https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=topic/opal-ipmi
 
 And will merge that into my next, probably by tomorrow.
 
 If you merge the topic branch and then apply patch 2/2, then it should all go
 in without any hiccups.

OK, and I have an updated IPMI driver patch (ie, 2/2) that will apply on
top of the new ipmi/for-next tree (best done after that merge). Patch
coming shortly...

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] drivers/char/ipmi: Add powernv IPMI driver

[Jeremy Kerr]

This change adds an initial IPMI driver for powerpc OPAL firmware. The
interface is exposed entirely through firmware: we have two functions to
send and receive IPMI messages, and an interrupt notification from the
firmware to signify that a message is available.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
v2: Update for ipmi/for-next tree, add copyright header

---
 drivers/char/ipmi/Kconfig|6 
 drivers/char/ipmi/Makefile   |1 
 drivers/char/ipmi/ipmi_powernv.c |  307 +++
 3 files changed, 314 insertions(+)

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index c1fccf4..65fb008 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -72,6 +72,12 @@ config IPMI_SSIF
 have a driver that must be accessed over an I2C bus instead of a
 standard interface.  This module requires I2C support.
 
+config IPMI_POWERNV
+   depends on PPC_POWERNV
+   tristate 'POWERNV (OPAL firmware) IPMI interface'
+   help
+ Provides a driver for OPAL firmware-based IPMI interfaces.
+
 config IPMI_WATCHDOG
tristate 'IPMI Watchdog Timer'
help
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 115c08d..f3ffde1 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_IPMI_HANDLER) += ipmi_msghandler.o
 obj-$(CONFIG_IPMI_DEVICE_INTERFACE) += ipmi_devintf.o
 obj-$(CONFIG_IPMI_SI) += ipmi_si.o
 obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
+obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
 obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
 obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
new file mode 100644
index 000..50134ec
--- /dev/null
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -0,0 +1,307 @@
+/*
+ * PowerNV OPAL IPMI driver
+ *
+ * Copyright 2014 IBM Corp.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt)ipmi-powernv:  fmt
+
+#include linux/ipmi_smi.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+
+#include asm/opal.h
+
+
+struct ipmi_smi_powernv {
+   u64 interface_id;
+   struct ipmi_device_id   ipmi_id;
+   ipmi_smi_t  intf;
+   u64 event;
+   struct notifier_block   event_nb;
+
+   /**
+* We assume that there can only be one outstanding request, so
+* keep the pending message in cur_msg. We protect this from concurrent
+* updates through send  recv calls, (and consequently opal_msg, which
+* is in-use when cur_msg is set) with msg_lock
+*/
+   spinlock_t  msg_lock;
+   struct ipmi_smi_msg *cur_msg;
+   struct opal_ipmi_msg*opal_msg;
+};
+
+static int ipmi_powernv_start_processing(void *send_info, ipmi_smi_t intf)
+{
+   struct ipmi_smi_powernv *smi = send_info;
+   smi-intf = intf;
+   return 0;
+}
+
+static void send_error_reply(struct ipmi_smi_powernv *smi,
+   struct ipmi_smi_msg *msg, u8 completion_code)
+{
+   msg-rsp[0] = msg-data[0] | 0x4;
+   msg-rsp[1] = msg-data[1];
+   msg-rsp[2] = completion_code;
+   msg-rsp_size = 3;
+   ipmi_smi_msg_received(smi-intf, msg);
+}
+
+static void ipmi_powernv_send(void *send_info, struct ipmi_smi_msg *msg)
+{
+   struct ipmi_smi_powernv *smi = send_info;
+   struct opal_ipmi_msg *opal_msg;
+   unsigned long flags;
+   int comp, rc;
+   size_t size;
+
+   /* ensure data_len will fit in the opal_ipmi_msg buffer... */
+   if (msg-data_size  IPMI_MAX_MSG_LENGTH) {
+   comp = IPMI_REQ_LEN_EXCEEDED_ERR;
+   goto err;
+   }
+
+   /* ... and that we at least have netfn and cmd bytes */
+   if (msg-data_size  2) {
+   comp = IPMI_REQ_LEN_INVALID_ERR;
+   goto err;
+   }
+
+   spin_lock_irqsave(smi-msg_lock, flags);
+
+   if (smi-cur_msg) {
+   comp = IPMI_NODE_BUSY_ERR;
+   goto err_unlock;
+   }
+
+   /* format our data for the OPAL API */
+   opal_msg = smi-opal_msg;
+   opal_msg-version = OPAL_IPMI_MSG_FORMAT_VERSION_1;
+   opal_msg-netfn = msg-data[0];
+   opal_msg-cmd = msg-data[1];
+   if (msg-data_size  2)
+   memcpy(opal_msg-data, msg-data + 2, msg-data_size - 2);
+
+   /* data_size already includes the netfn and cmd bytes */
+   size = sizeof(*opal_msg) + msg-data_size - 2;
+
+   pr_devel(%s: opal_ipmi_send(0x%llx, %p, %ld)\n, __func__,
+   smi-interface_id, opal_msg, size);
+   rc = opal_ipmi_send(smi-interface_id, opal_msg, size);
+   pr_devel(%s:  - %d\n

Re: [PATCH 0/2] Add IPMI support for powernv powerpc machines

[Jeremy Kerr]

Hi Corey,

Thanks for the review.

 IPMI folks: the IPMI driver could do with a little review, as it's
 not a conventional BT/KCS/SMI SI, in that the low-level send/recv
 interface will handle the entire message at once.
 
 Handling the entire message at once should be fine, as that's what
 this driver level is designed to do for the message handler.  That
 part all looks correct.  The code itself looks good, but I have a
 couple of high-level comments.
 
 The driver at this level can receive more than one message to handle
 at a time, so it needs some sort of queue.  This is to allow multiple
 users and to allow the message handler to send its own commands while
 other commands are going on.  You might argue that the queuing should
 be done in ipmi_msghandler, and you would probably be right.

Ah, that's what I'd been assuming was being done - I missed the
xmit_list in the si_intf code. It'd be great if this could be in the
generic msghandler code, otherwise I'd just be duplicating the si_intf
logic.

 I'll look at doing that.  If that is the case, then your NULL check
 for current message should probably be a BUG_ON().

OK, I'll update this when the msghandler bit is implemented.

 Do you need to handle any BMC flags?  Particularly incoming events?

Not at this stage - we may in future though.

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/2] Add IPMI support for powernv powerpc machines

[Jeremy Kerr]

Hi Ben,

 Our OPAL interface can only do one at a time ? Because our underlying
 FW driver already has a queue ..

The Linux driver needs to match responses to their requests, so the
driver needs to keep a reference to the requests that we've sent. The
current implementation is very simple: we just keep one pointer, and
require that there's only one outstanding request.

To have multiple outstanding requests, our options here are that we either:

1) duplicate the si_intf's queuing code in the powernv driver; or

2) move the queuing code from the si_intf component to the generic
   IPMI msghander, and use that (so all drivers can assume a single
   outstanding request)

Corey has suggested the latter, which will only require a minimal change
to the powerpv IPMI driver.

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] powerpc/powernv: Add OPAL IPMI interface

[Jeremy Kerr]

Recent OPAL firmare adds a couple of functions to send and receive IPMI
messages:

  https://github.com/open-power/skiboot/commit/b2a374da

This change updates the token list and wrappers to suit, and adds the
platform devices for any IPMI interfaces.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/include/asm/opal.h|   17 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |2 ++
 arch/powerpc/platforms/powernv/opal.c  |   14 ++
 3 files changed, 33 insertions(+)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9124b0e..5d073e5 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -154,6 +154,8 @@ struct opal_sg_list {
 #define OPAL_HANDLE_HMI98
 #define OPAL_REGISTER_DUMP_REGION  101
 #define OPAL_UNREGISTER_DUMP_REGION102
+#define OPAL_IPMI_SEND 107
+#define OPAL_IPMI_RECV 108
 
 #ifndef __ASSEMBLY__
 
@@ -452,6 +454,17 @@ struct opal_msg {
__be64 params[8];
 };
 
+enum {
+   OPAL_IPMI_MSG_FORMAT_VERSION_1 = 1,
+};
+
+struct opal_ipmi_msg {
+   uint8_t version;
+   uint8_t netfn;
+   uint8_t cmd;
+   uint8_t data[];
+};
+
 struct opal_machine_check_event {
enum OpalMCE_Versionversion:8;  /* 0x00 */
uint8_t in_use; /* 0x01 */
@@ -963,6 +976,10 @@ int64_t opal_handle_hmi(void);
 int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
 int64_t opal_unregister_dump_region(uint32_t id);
 int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t 
pe_number);
+int64_t opal_ipmi_send(uint64_t interface, struct opal_ipmi_msg *msg,
+   uint64_t msg_len);
+int64_t opal_ipmi_recv(uint64_t interface, struct opal_ipmi_msg *msg,
+   uint64_t *msg_len);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e9e2450..f463068 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -250,3 +250,5 @@ OPAL_CALL(opal_handle_hmi,  
OPAL_HANDLE_HMI);
 OPAL_CALL(opal_register_dump_region,   OPAL_REGISTER_DUMP_REGION);
 OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
 OPAL_CALL(opal_pci_set_phb_cxl_mode,   OPAL_PCI_SET_PHB_CXL_MODE);
+OPAL_CALL(opal_ipmi_send,  OPAL_IPMI_SEND);
+OPAL_CALL(opal_ipmi_recv,  OPAL_IPMI_RECV);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index b642b05..c2f873e 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -623,6 +623,16 @@ static void __init opal_dump_region_init(void)
pr_warn(DUMP: Failed to register kernel log buffer. 
rc = %d\n, rc);
 }
+
+static void opal_ipmi_init(struct device_node *opal_node)
+{
+   struct device_node *np;
+
+   for_each_child_of_node(opal_node, np)
+   if (of_device_is_compatible(np, ibm,opal-ipmi))
+   of_platform_device_create(np, NULL, NULL);
+}
+
 static int __init opal_init(void)
 {
struct device_node *np, *consoles;
@@ -686,6 +696,8 @@ static int __init opal_init(void)
opal_msglog_init();
}
 
+   opal_ipmi_init(opal_node);
+
return 0;
 }
 machine_subsys_initcall(powernv, opal_init);
@@ -721,6 +733,8 @@ void opal_shutdown(void)
 
 /* Export this so that test modules can use it */
 EXPORT_SYMBOL_GPL(opal_invalid_call);
+EXPORT_SYMBOL_GPL(opal_ipmi_send);
+EXPORT_SYMBOL_GPL(opal_ipmi_recv);
 
 /* Convert a region of vmalloc memory to an opal sg list */
 struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/2] Add IPMI support for powernv powerpc machines

[Jeremy Kerr]

This series adds IPMI driver and arch glue for OPAL-firmware-based
powernv machines. The first change exposes the firmware's IPMI API, and
the second adds an actual driver.

IPMI folks: the IPMI driver could do with a little review, as it's not a
conventional BT/KCS/SMI SI, in that the low-level send/recv interface
will handle the entire message at once.

Corey  Michael: if this is acceptable, it may be mergable as two
separate patches - one for the IPMI subsystem, one for the powernv
platform.  However, we'd need to preserve their order: patch 2/2 depends
on 1/2, which provides the structure  function definitions. This'll
break the build if only 2/2 is in the tree, and CONFIG_IPMI_POWERNV is
set.

Alternatively, they could be merged by one maintainer, pending an ack
from the other.

Comments / queries / etc welcome.

Cheers,


Jeremy

---
Jeremy Kerr (2):
  powerpc/powernv: Add OPAL IPMI interface
  drivers/char/ipmi: Add powernv IPMI driver

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] drivers/char/ipmi: Add powernv IPMI driver

[Jeremy Kerr]

This change adds an initial IPMI driver for powerpc OPAL firmware. The
interface is exposed entirely through firmware: we have two functions to
send and receive IPMI messages, and an interrupt notification from the
firmware to signify that a message is available.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 drivers/char/ipmi/Kconfig|6 
 drivers/char/ipmi/Makefile   |1 
 drivers/char/ipmi/ipmi_powernv.c |  298 +++
 3 files changed, 305 insertions(+)

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index db1c9b7..a6a8cb3 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -62,6 +62,12 @@ config IPMI_SI_PROBE_DEFAULTS
 only be available on older systems if the ipmi_si_intf.trydefaults=1
 boot argument is passed.
 
+config IPMI_POWERNV
+   depends on PPC_POWERNV
+   tristate 'POWERNV (OPAL firmware) IPMI interface'
+   help
+ Provides a driver for OPAL firmware-based IPMI interfaces.
+
 config IPMI_WATCHDOG
tristate 'IPMI Watchdog Timer'
help
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 16a9364..6620404 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -7,5 +7,6 @@ ipmi_si-y := ipmi_si_intf.o ipmi_kcs_sm.o ipmi_smic_sm.o 
ipmi_bt_sm.o
 obj-$(CONFIG_IPMI_HANDLER) += ipmi_msghandler.o
 obj-$(CONFIG_IPMI_DEVICE_INTERFACE) += ipmi_devintf.o
 obj-$(CONFIG_IPMI_SI) += ipmi_si.o
+obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
 obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
 obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
new file mode 100644
index 000..79bbed9
--- /dev/null
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -0,0 +1,298 @@
+
+#define pr_fmt(fmt)ipmi-powernv:  fmt
+
+#include linux/ipmi_smi.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+
+#include asm/opal.h
+
+
+struct ipmi_smi_powernv {
+   u64 interface_id;
+   struct ipmi_device_id   ipmi_id;
+   ipmi_smi_t  intf;
+   u64 event;
+   struct notifier_block   event_nb;
+
+   /**
+* We assume that there can only be one outstanding request, so
+* keep the pending message in cur_msg. We protect this from concurrent
+* updates through send  recv calls, (and consequently opal_msg, which
+* is in-use when cur_msg is set) with msg_lock
+*/
+   spinlock_t  msg_lock;
+   struct ipmi_smi_msg *cur_msg;
+   struct opal_ipmi_msg*opal_msg;
+};
+
+static int ipmi_powernv_start_processing(void *send_info, ipmi_smi_t intf)
+{
+   struct ipmi_smi_powernv *smi = send_info;
+   smi-intf = intf;
+   return 0;
+}
+
+static void send_error_reply(struct ipmi_smi_powernv *smi,
+   struct ipmi_smi_msg *msg, u8 completion_code)
+{
+   msg-rsp[0] = msg-data[0] | 0x4;
+   msg-rsp[1] = msg-data[1];
+   msg-rsp[2] = completion_code;
+   msg-rsp_size = 3;
+   ipmi_smi_msg_received(smi-intf, msg);
+}
+
+static void ipmi_powernv_send(void *send_info, struct ipmi_smi_msg *msg,
+   int priority)
+{
+   struct ipmi_smi_powernv *smi = send_info;
+   struct opal_ipmi_msg *opal_msg;
+   unsigned long flags;
+   int comp, rc;
+   size_t size;
+
+   /* ensure data_len will fit in the opal_ipmi_msg buffer... */
+   if (msg-data_size  IPMI_MAX_MSG_LENGTH) {
+   comp = IPMI_REQ_LEN_EXCEEDED_ERR;
+   goto err;
+   }
+
+   /* ... and that we at least have netfn and cmd bytes */
+   if (msg-data_size  2) {
+   comp = IPMI_REQ_LEN_INVALID_ERR;
+   goto err;
+   }
+
+   spin_lock_irqsave(smi-msg_lock, flags);
+
+   if (smi-cur_msg) {
+   comp = IPMI_NODE_BUSY_ERR;
+   goto err_unlock;
+   }
+
+   /* format our data for the OPAL API */
+   opal_msg = smi-opal_msg;
+   opal_msg-version = OPAL_IPMI_MSG_FORMAT_VERSION_1;
+   opal_msg-netfn = msg-data[0];
+   opal_msg-cmd = msg-data[1];
+   if (msg-data_size  2)
+   memcpy(opal_msg-data, msg-data + 2, msg-data_size - 2);
+
+   /* data_size already includes the netfn and cmd bytes */
+   size = sizeof(*opal_msg) + msg-data_size - 2;
+
+   pr_devel(%s: opal_ipmi_send(0x%llx, %p, %ld)\n, __func__,
+   smi-interface_id, opal_msg, size);
+   rc = opal_ipmi_send(smi-interface_id, opal_msg, size);
+   pr_devel(%s:  - %d\n, __func__, rc);
+
+   if (!rc) {
+   smi-cur_msg = msg;
+   spin_unlock_irqrestore(smi-msg_lock, flags);
+   return;
+   }
+
+   comp = IPMI_ERR_UNSPECIFIED;
+err_unlock:
+   spin_unlock_irqrestore(smi-msg_lock, flags);
+err:
+   send_error_reply(smi, msg, comp);
+}
+
+static int

Re: [PATCH] powernv: Use _GLOBAL_TOC for opal wrappers

[Jeremy Kerr]

Hi Michael,

 Currently, we can't call opal wrappers from modules when using the LE
 ABIv2, which requires a TOC init.
 
 What happens if we try? Build failure or run time bug?

We'll get an arbitrary memory dereference (two, actually) in the opal
wrappers, when we try to load the opal entry point  return address from
the TOC, as r2 may not point to a valid TOC for the kernel.

 This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the
 opal wrappers, so that we can do non-local calls to them.
 
 Are we doing that now, or we would like to?

We'd like to; although we do EXPORT_SYMBOL on another wrapper
(opal_invalid_call()) already. From the call name though, I figure it's
not in any mission-critical usage :)

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powernv: Use _GLOBAL_TOC for opal wrappers

[Jeremy Kerr]

Currently, we can't call opal wrappers from modules when using the LE
ABIv2, which requires a TOC init.

This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the
opal wrappers, so that we can do non-local calls to them.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/platforms/powernv/opal-wrappers.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e9e2450..845a5c5 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -58,7 +58,7 @@ END_FTR_SECTION(0, 1);
\
  */
 
 #define OPAL_CALL(name, token) \
- _GLOBAL(name);\
+ _GLOBAL_TOC(name);\
mflrr0; \
std r0,16(r1);  \
li  r0,token;   \
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 01/15] powerpc/cell: Move spu_handle_mm_fault() out of cell platform

[Jeremy Kerr]

Hi Mikey  Ian,

 Currently spu_handle_mm_fault() is in the cell platform.
 
 This code is generically useful for other non-cell co-processors on powerpc.
 
 This patch moves this function out of the cell platform into arch/powerpc/mm 
 so
 that others may use it.

Makes sense.

Acked-by: Jeremy Kerr j...@ozlabs.org

 @@ -58,12 +56,12 @@ int spu_handle_mm_fault(struct mm_struct *mm, unsigned 
 long ea,
   goto out_unlock;
   }
  
 - is_write = dsisr  MFC_DSISR_ACCESS_PUT;
 + is_write = dsisr  DSISR_ISSTORE;
   if (is_write) {
   if (!(vma-vm_flags  VM_WRITE))
   goto out_unlock;
   } else {
 - if (dsisr  MFC_DSISR_ACCESS_DENIED)
 + if (dsisr  DSISR_PROTFAULT)
   goto out_unlock;
   if (!(vma-vm_flags  (VM_READ | VM_EXEC)))
   goto out_unlock;

Consistent DSISR encodings? woot! :)

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform

[Jeremy Kerr]

Hi Mikey  Ian,

 __spu_trap_data_seg() currently contains code to determine the VSID and ESID
 required for a particular EA and mm struct.
 
 This code is generically useful for other co-processors.  This moves the code
 of the cell platform so it can be used by other powerpc code.

OK, nice.

 +
 +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid)
 +{
 + int psize, ssize;
 +
 + *esid = (ea  ESID_MASK) | SLB_ESID_V;
 +
 + switch (REGION_ID(ea)) {
 + case USER_REGION_ID:
 + pr_devel(copro_data_segment: 0x%llx -- USER_REGION_ID\n, ea);
 +#ifdef CONFIG_PPC_MM_SLICES
 + psize = get_slice_psize(mm, ea);
 +#else
 + psize = mm-context.user_psize;
 +#endif
 + ssize = user_segment_size(ea);
 + *vsid = (get_vsid(mm-context.id, ea, ssize)
 +  slb_vsid_shift(ssize)) | SLB_VSID_USER
 + | (ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
 + break;
 + case VMALLOC_REGION_ID:
 + pr_devel(copro_data_segment: 0x%llx -- VMALLOC_REGION_ID\n, 
 ea);
 + if (ea  VMALLOC_END)
 + psize = mmu_vmalloc_psize;
 + else
 + psize = mmu_io_psize;
 + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
 +  SLB_VSID_SHIFT) | SLB_VSID_KERNEL
 + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 
 0);
 + break;
 + case KERNEL_REGION_ID:
 + pr_devel(copro_data_segment: 0x%llx -- KERNEL_REGION_ID\n, 
 ea);
 + psize = mmu_linear_psize;
 + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
 +  SLB_VSID_SHIFT) | SLB_VSID_KERNEL
 + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 
 0);
 + break;
 + default:
 + /* Future: support kernel segments so that drivers can use the
 +  * CoProcessors */
 + pr_debug(invalid region access at %016llx\n, ea);
 + return 1;
 + }
 + *vsid |= mmu_psize_defs[psize].sllp;

A bit of a nitpick, but how about you remove the repeated:

| (size == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0)

then set ssize in each of the switch cases (like we do with psize), and
or-in the VSID_B_1T bit at the end:

*vsid |= mmu_psize_defs[psize].sllp
| (ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);

Otherwise, looks good to me.

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch] powerpc/spufs: remove duplicate SPUFS_CNTL_MAP_SIZE define

[Jeremy Kerr]

Hi Dan,

 The SPUFS_CNTL_MAP_SIZE define is cut and pasted twice so we can delete
 the second instance.

Looks good to me.

Acked-by: Jeremy Kerr j...@ozlabs.org

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/spufs: Remove MAX_USER_PRIO define

[Jeremy Kerr]

Current ppc64_defconfig fails with:

 arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: MAX_USER_PRIO 
redefined [-Werror]
 cc1: all warnings being treated as errors

6b6350f1 introduced a generic MAX_USER_PRIO macro to sched/prio.h, which
is causing the conflit. Use that one instead of our own.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
Ingo: 6b6350f1 is currently in tip; this fixes a build breakage for spufs

---
 arch/powerpc/platforms/cell/spufs/sched.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spufs/sched.c 
b/arch/powerpc/platforms/cell/spufs/sched.c
index 4931838..4a0a64f 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -83,7 +83,6 @@ static struct timer_list spuloadavg_timer;
 #define MIN_SPU_TIMESLICE  max(5 * HZ / (1000 * SPUSCHED_TICK), 1)
 #define DEF_SPU_TIMESLICE  (100 * HZ / (1000 * SPUSCHED_TICK))
 
-#define MAX_USER_PRIO  (MAX_PRIO - MAX_RT_PRIO)
 #define SCALE_PRIO(x, prio) \
max(x * (MAX_PRIO - prio) / (MAX_USER_PRIO / 2), MIN_SPU_TIMESLICE)
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] arch/powerpc: Dynamically allocate slb_shadow from memblock

[Jeremy Kerr]

Currently, the slb_shadow buffer is our largest symbol:

  [jk@pablo linux]$ nm --size-sort -r -S obj/vmlinux | head -1
  c0da 0004 d slb_shadow

- we allocate 128 bytes per cpu; so 256k with NR_CPUS=2048. As we have
constant initialisers, it's allocated in .text, causing a larger vmlinux
image. We may also allocate unecessary slb_shadow buffers ( no. pacas),
since we use the build-time NR_CPUS rather than the run-time nr_cpu_ids.

We could move this to the bss, but then we still have the NR_CPUS vs
nr_cpu_ids potential for overallocation.

This change dynamically allocates the slb_shadow array, during
initialise_pacas(). At a cost of 104 bytes of text, we save 256k of
data:

  [jk@pablo linux]$ size obj/vmlinux{.orig,}
 text data  bss   dec hex   filename
  9202795  5244676  1169576  15617047  ee4c17   obj/vmlinux.orig
  9202899  4982532  1169576  15355007  ea4c7f   obj/vmlinux

Tested on pseries.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/kernel/paca.c |   32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 9095a6f7..ad7a485f 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -99,12 +99,28 @@ static inline void free_lppacas(void) { }
  * 3 persistent SLBs are registered here.  The buffer will be zero
  * initially, hence will all be invaild until we actually write them.
  */
-static struct slb_shadow slb_shadow[] __cacheline_aligned = {
-   [0 ... (NR_CPUS-1)] = {
-   .persistent = cpu_to_be32(SLB_NUM_BOLTED),
-   .buffer_length = cpu_to_be32(sizeof(struct slb_shadow)),
-   },
-};
+static struct slb_shadow *slb_shadow;
+
+static void __init allocate_slb_shadows(int nr_cpus, int limit)
+{
+   int size = PAGE_ALIGN(sizeof(struct slb_shadow) * nr_cpus);
+   slb_shadow = __va(memblock_alloc_base(size, PAGE_SIZE, limit));
+   memset(slb_shadow, 0, size);
+}
+
+static struct slb_shadow * __init init_slb_shadow(int cpu)
+{
+   struct slb_shadow *s = slb_shadow[cpu];
+
+   s-persistent = ARRAY_SIZE(s-save_area);
+   s-buffer_length = sizeof(*s);
+
+   return s;
+}
+
+#else /* CONFIG_PPC_STD_MMU_64 */
+
+static void __init allocate_slb_shadows(int nr_cpus, int limit) { }
 
 #endif /* CONFIG_PPC_STD_MMU_64 */
 
@@ -142,7 +158,7 @@ void __init initialise_paca(struct paca_struct *new_paca, 
int cpu)
new_paca-__current = init_task;
new_paca-data_offset = 0xfeeeULL;
 #ifdef CONFIG_PPC_STD_MMU_64
-   new_paca-slb_shadow_ptr = slb_shadow[cpu];
+   new_paca-slb_shadow_ptr = init_slb_shadow(cpu);
 #endif /* CONFIG_PPC_STD_MMU_64 */
 }
 
@@ -190,6 +206,8 @@ void __init allocate_pacas(void)
 
allocate_lppacas(nr_cpu_ids, limit);
 
+   allocate_slb_shadows(nr_cpu_ids, limit);
+
/* Can't use for_each_*_cpu, as they aren't functional yet */
for (cpu = 0; cpu  nr_cpu_ids; cpu++)
initialise_paca(paca[cpu], cpu);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] arch/powerpc: Make slb_shadow a local

[Jeremy Kerr]

The only external user of slb_shadow is the pseries lpar code, and it
can access through the paca array instead.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/include/asm/lppaca.h |2 --
 arch/powerpc/kernel/paca.c|2 +-
 arch/powerpc/platforms/pseries/lpar.c |2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/lppaca.h 
b/arch/powerpc/include/asm/lppaca.h
index 844c28de..d0a2a2f9 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -132,8 +132,6 @@ struct slb_shadow {
} save_area[SLB_NUM_BOLTED];
 } cacheline_aligned;
 
-extern struct slb_shadow slb_shadow[];
-
 /*
  * Layout of entries in the hypervisor's dispatch trace log buffer.
  */
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 0620eaaa..9095a6f7 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -99,7 +99,7 @@ static inline void free_lppacas(void) { }
  * 3 persistent SLBs are registered here.  The buffer will be zero
  * initially, hence will all be invaild until we actually write them.
  */
-struct slb_shadow slb_shadow[] __cacheline_aligned = {
+static struct slb_shadow slb_shadow[] __cacheline_aligned = {
[0 ... (NR_CPUS-1)] = {
.persistent = cpu_to_be32(SLB_NUM_BOLTED),
.buffer_length = cpu_to_be32(sizeof(struct slb_shadow)),
diff --git a/arch/powerpc/platforms/pseries/lpar.c 
b/arch/powerpc/platforms/pseries/lpar.c
index 4fca3def..28cf0f33 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -92,7 +92,7 @@ void vpa_init(int cpu)
 * PAPR says this feature is SLB-Buffer but firmware never
 * reports that.  All SPLPAR support SLB shadow buffer.
 */
-   addr = __pa(slb_shadow[cpu]);
+   addr = __pa(paca[cpu].slb_shadow_ptr);
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
ret = register_slb_shadow(hwcpu, addr);
if (ret)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] arch/powerpc: Dynamically allocate slb_shadow from memblock

[Jeremy Kerr]

Currently, the slb_shadow buffer is our largest symbol:

  [jk@pablo linux]$ nm --size-sort -r -S obj/vmlinux | head -1
  c0da 0004 d slb_shadow

- we allocate 128 bytes per cpu; so 256k with NR_CPUS=2048. As we have
constant initialisers, it's allocated in .text, causing a larger vmlinux
image. We may also allocate unecessary slb_shadow buffers ( no. pacas),
since we use the build-time NR_CPUS rather than the run-time nr_cpu_ids.

We could move this to the bss, but then we still have the NR_CPUS vs
nr_cpu_ids potential for overallocation.

This change dynamically allocates the slb_shadow array, during
initialise_pacas(). At a cost of 104 bytes of text, we save 256k of
data:

  [jk@pablo linux]$ size obj/vmlinux{.orig,}
 text data  bss   dec hex   filename
  9202795  5244676  1169576  15617047  ee4c17   obj/vmlinux.orig
  9202899  4982532  1169576  15355007  ea4c7f   obj/vmlinux

Tested on pseries.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
v2: don't drop the endian conversion, use SLB_NUM_BOLTED

---
 arch/powerpc/kernel/paca.c |   32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 9095a6f7..623c356f 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -99,12 +99,28 @@ static inline void free_lppacas(void) { }
  * 3 persistent SLBs are registered here.  The buffer will be zero
  * initially, hence will all be invaild until we actually write them.
  */
-static struct slb_shadow slb_shadow[] __cacheline_aligned = {
-   [0 ... (NR_CPUS-1)] = {
-   .persistent = cpu_to_be32(SLB_NUM_BOLTED),
-   .buffer_length = cpu_to_be32(sizeof(struct slb_shadow)),
-   },
-};
+static struct slb_shadow *slb_shadow;
+
+static void __init allocate_slb_shadows(int nr_cpus, int limit)
+{
+   int size = PAGE_ALIGN(sizeof(struct slb_shadow) * nr_cpus);
+   slb_shadow = __va(memblock_alloc_base(size, PAGE_SIZE, limit));
+   memset(slb_shadow, 0, size);
+}
+
+static struct slb_shadow * __init init_slb_shadow(int cpu)
+{
+   struct slb_shadow *s = slb_shadow[cpu];
+
+   s-persistent = cpu_to_be32(SLB_NUM_BOLTED);
+   s-buffer_length = cpu_to_be32(sizeof(*s));
+
+   return s;
+}
+
+#else /* CONFIG_PPC_STD_MMU_64 */
+
+static void __init allocate_slb_shadows(int nr_cpus, int limit) { }
 
 #endif /* CONFIG_PPC_STD_MMU_64 */
 
@@ -142,7 +158,7 @@ void __init initialise_paca(struct paca_struct *new_paca, 
int cpu)
new_paca-__current = init_task;
new_paca-data_offset = 0xfeeeULL;
 #ifdef CONFIG_PPC_STD_MMU_64
-   new_paca-slb_shadow_ptr = slb_shadow[cpu];
+   new_paca-slb_shadow_ptr = init_slb_shadow(cpu);
 #endif /* CONFIG_PPC_STD_MMU_64 */
 }
 
@@ -190,6 +206,8 @@ void __init allocate_pacas(void)
 
allocate_lppacas(nr_cpu_ids, limit);
 
+   allocate_slb_shadows(nr_cpu_ids, limit);
+
/* Can't use for_each_*_cpu, as they aren't functional yet */
for (cpu = 0; cpu  nr_cpu_ids; cpu++)
initialise_paca(paca[cpu], cpu);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier

[Jeremy Kerr]

Hi Alexey,

 This patch does 2 things:
 1. removes the loop in which PCI devices were added to groups and
 adds explicit iommu_add_device() calls to add devices as soon as they get
 the iommu_table pointer assigned to them.
 2. moves a bus notifier to powernv code in order to avoid conflict with
 the notifier from Freescale driver.

This breaks when building with !IOMMU_API for me, as the
iommu_add_device function is declared but not defined. We'd need
something like the following (on top of your change) to work:

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 426d0ec0..04d2abbe 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -102,10 +102,27 @@ extern void iommu_free_table(struct iommu_table *tbl, cons
  */
 extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+
+#ifdef CONFIG_IOMMU_API
 extern void iommu_register_group(struct iommu_table *tbl,
 int pci_domain_number, unsigned long pe_num);
 extern int iommu_add_device(struct device *dev);
 extern void iommu_del_device(struct device *dev);
+#else
+static inline void iommu_register_group(struct iommu_table *tbl,
+int pci_domain_number, unsigned long pe_num)
+{
+}
+
+static inline int iommu_add_device(struct device *dev)
+{
+   return 0;
+}
+
+static inline void iommu_del_device(struct device *dev)
+{
+}
+#endif
 
 static inline void set_iommu_table_base_and_group(struct device *dev,
  void *base)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 170b2182..5a02a50f 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1212,11 +1212,4 @@ void iommu_del_device(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(iommu_del_device);
 
-#else
-
-void iommu_register_group(struct iommu_table *tbl,
-   int pci_domain_number, unsigned long pe_num)
-{
-}
-
 #endif /* CONFIG_IOMMU_API */


Cheers,


Jeremy



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: build failure after merge of the final tree

[Jeremy Kerr]

Hi all,

 Yes, I agree. The other filesystems that take an Opt_uid as well do use
 current_user_ns() and not init_user_ns. They also do a uid_valid()
 check and fail the mount (or fallback to GLOBAL_ROOT_UID). So I think
 that would look like this:

Looks good to me. Builds and mounts as expected.

Acked-by: Jeremy Kerr j...@ozlabs.org

Cheers,


Jeremy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [git pull] Please pull powerpc.git merge branch

[Jeremy Kerr]

Hi Linus,

 Is Jeremy the patchwork maintainer?

Yep, that's me.

 and it turns out that apparently 'patchwork' is just making up random
 times, because when you download the email as an mbox, it will turn
 this into that corrupt and incorrect
 
 Date: Thu, 06 Jun 2013 19:42:54 -
 
 thing which is apparently how you got the wrong timestamp to begin with.

We keep all patch dates in UTC, but were generating the Date header
incorrectly. Now fixed:

$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 07 Jun 2013 05:42:54 -

Commit is at:

 http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=e7353352

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [git pull] Please pull powerpc.git merge branch

[Jeremy Kerr]

Hi Linus,

 No. The date from the email was
 
 Date: Fri, 7 Jun 2013 15:42:54 +1000
 
 and we want *that* date.

Ah, gotchya.

So, we now use the original date header (if present) in the mbox views:

$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 7 Jun 2013 15:42:54 +1000

... for all your data-mining needs.

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/powernv: defer OPAL exception handler registration

[Jeremy Kerr]

Currently, the OPAL exception vectors are registered before the feature
fixups are processed. This means that the now-firmware-owned vectors
will likely be overwritten by the kernel.

This change moves the exception registration code to an early initcall,
rather than at machine_init time.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/platforms/powernv/opal.c |   15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index aaa0dba..ade4463 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -34,7 +34,6 @@ int __init early_init_dt_scan_opal(unsigned long node,
 {
const void *basep, *entryp;
unsigned long basesz, entrysz;
-   u64 glue;
 
if (depth != 1 || strcmp(uname, ibm,opal) != 0)
return 0;
@@ -61,6 +60,16 @@ int __init early_init_dt_scan_opal(unsigned long node,
printk(OPAL V1 detected !\n);
}
 
+   return 1;
+}
+
+static int __init opal_register_exception_handlers(void)
+{
+   u64 glue;
+
+   if (!(powerpc_firmware_features  FW_FEATURE_OPAL))
+   return -ENODEV;
+
/* Hookup some exception handlers. We use the fwnmi area at 0x7000
 * to provide the glue space to OPAL
 */
@@ -74,9 +83,11 @@ int __init early_init_dt_scan_opal(unsigned long node,
glue += 128;
opal_register_exception_handler(OPAL_SOFTPATCH_HANDLER, 0, glue);
 
-   return 1;
+   return 0;
 }
 
+early_initcall(opal_register_exception_handlers);
+
 int opal_get_chars(uint32_t vtermno, char *buf, int count)
 {
s64 len, rc;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RFC, PATCH v3] powerpc/prom: Scan reserved-ranges node for memory reservations

[Jeremy Kerr]

Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.

We just call memblock_reserve on these ranges for now.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
v3: Use of_get_flat_dt_root

---
 arch/powerpc/kernel/prom.c |   35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..9c753bc 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,33 @@ void __init early_init_dt_setup_initrd_arch(unsigned long 
start,
 }
 #endif
 
+static bool __init early_reserve_mem_dt(void)
+{
+   unsigned long i, len, dt_root;
+   const __be32 *prop;
+
+   dt_root = of_get_flat_dt_root();
+
+   prop = of_get_flat_dt_prop(dt_root, reserved-ranges, len);
+
+   if (!prop)
+   return false;
+
+   /* Each reserved range is an (address,size) pair, 2 cells each,
+* totalling 4 cells per range. */
+   for (i = 0; i  len / (sizeof(*prop) * 4); i++) {
+   u64 base, size;
+
+   base = of_read_number(prop + (i * 4) + 0, 2);
+   size = of_read_number(prop + (i * 4) + 2, 2);
+
+   if (size)
+   memblock_reserve(base, size);
+   }
+
+   return true;
+}
+
 static void __init early_reserve_mem(void)
 {
u64 base, size;
@@ -574,6 +601,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params-totalsize;
memblock_reserve(self_base, self_size);
 
+   /*
+* Try looking for reserved-regions property in the DT first; if
+* it's present, it'll contain all of the necessary reservation
+* info
+*/
+   if (early_reserve_mem_dt())
+   return;
+
 #ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start  (initrd_end  initrd_start))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RFC, PATCH] powerpc/prom: Scan reserved-ranges node for memory reservations

[Jeremy Kerr]

Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.

We just call memblock_reserve on these ranges for now.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
 arch/powerpc/kernel/prom.c |   36 
 1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..1208c8f 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,34 @@ void __init early_init_dt_setup_initrd_arch(unsigned long 
start,
 }
 #endif
 
+static bool __init early_reserve_mem_dt(void)
+{
+   unsigned long i, len, dt_root;
+   const __be32 *prop;
+
+   dt_root = ((unsigned long)initial_boot_params) +
+   be32_to_cpu(initial_boot_params-off_dt_struct);
+
+   prop = of_get_flat_dt_prop(dt_root, reserved-ranges, len);
+
+   if (!prop)
+   return false;
+
+   /* Each reserved range is an (address,size) pair, 2 cells each */
+   for (i = 0; i  len / sizeof(*prop);
+   i += dt_root_addr_cells + dt_root_size_cells) {
+   u64 base, size;
+
+   base = of_read_number(prop + (i * 4), 2);
+   size = of_read_number(prop + (i * 4) + 2, 2);
+
+   if (size)
+   memblock_reserve(base, size);
+   }
+
+   return true;
+}
+
 static void __init early_reserve_mem(void)
 {
u64 base, size;
@@ -574,6 +602,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params-totalsize;
memblock_reserve(self_base, self_size);
 
+   /*
+* Try looking for reserved-regions property in the DT first; if
+* it's present, it'll contain all of the necessary reservation
+* info
+*/
+   if (early_reserve_mem_dt())
+   return;
+
 #ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start  (initrd_end  initrd_start))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RFC, PATCH v2] powerpc/prom: Scan reserved-ranges node for memory reservations

[Jeremy Kerr]

Based on benh's proposal at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/101237.html,
this change provides support for reserving memory from the
reserved-ranges node at the root of the device tree.

We just call memblock_reserve on these ranges for now.

Signed-off-by: Jeremy Kerr j...@ozlabs.org

---
v2: fix range property iteration

---
 arch/powerpc/kernel/prom.c |   36 
 1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..c77307e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,6 +559,34 @@ void __init early_init_dt_setup_initrd_arch(unsigned long 
start,
 }
 #endif
 
+static bool __init early_reserve_mem_dt(void)
+{
+   unsigned long i, len, dt_root;
+   const __be32 *prop;
+
+   dt_root = ((unsigned long)initial_boot_params) +
+   be32_to_cpu(initial_boot_params-off_dt_struct);
+
+   prop = of_get_flat_dt_prop(dt_root, reserved-ranges, len);
+
+   if (!prop)
+   return false;
+
+   /* Each reserved range is an (address,size) pair, 2 cells each,
+* totalling 4 cells per range. */
+   for (i = 0; i  len / (sizeof(*prop) * 4); i++) {
+   u64 base, size;
+
+   base = of_read_number(prop + (i * 4) + 0, 2);
+   size = of_read_number(prop + (i * 4) + 2, 2);
+
+   if (size)
+   memblock_reserve(base, size);
+   }
+
+   return true;
+}
+
 static void __init early_reserve_mem(void)
 {
u64 base, size;
@@ -574,6 +602,14 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params-totalsize;
memblock_reserve(self_base, self_size);
 
+   /*
+* Try looking for reserved-regions property in the DT first; if
+* it's present, it'll contain all of the necessary reservation
+* info
+*/
+   if (early_reserve_mem_dt())
+   return;
+
 #ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start  (initrd_end  initrd_start))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev