All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haren Myneni <haren@linux.vnet.ibm.com>
To: Dan Streetman <ddstreet@ieee.org>
Cc: pair@us.ibm.com, Herbert Xu <herbert@gondor.apana.org.au>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: crypto/nx842: Ignore queue overflow informative error
Date: Fri, 11 Dec 2015 18:02:35 -0800	[thread overview]
Message-ID: <566B803B.5050608@linux.vnet.ibm.com> (raw)
In-Reply-To: <CALZtONCw9+wvSQ+vwsvSWa_itR-G9ZBkuXftzNHV9oTd8YZFaw@mail.gmail.com>

On 12/07/2015 11:34 AM, Dan Streetman wrote:
> On Sun, Dec 6, 2015 at 2:46 AM, Haren Myneni <haren@linux.vnet.ibm.com> wrote:
>>
>> NX842 coprocessor sets bit 3 if queue is overflow. It is just for
>> information to the user. So the driver prints this informative message
>> and ignores it.
>>
>> Signed-off-by: Haren Myneni <haren@us.ibm.com>
>>
>> diff --git a/arch/powerpc/include/asm/icswx.h b/arch/powerpc/include/asm/icswx.h
>> index 9f8402b..d1a2a2d 100644
>> --- a/arch/powerpc/include/asm/icswx.h
>> +++ b/arch/powerpc/include/asm/icswx.h
>> @@ -164,6 +164,7 @@ struct coprocessor_request_block {
>>  #define ICSWX_INITIATED                (0x8)
>>  #define ICSWX_BUSY             (0x4)
>>  #define ICSWX_REJECTED         (0x2)
>> +#define ICSWX_BIT3             (0x1)   /* undefined or set from XERSO. */
> 
> Since this isn't defined by the icswx rfc workbook, it probably
> shouldn't go here, it would make more sense to put it into nx-842.h
> and call it something like "ICSWX_NX_QUEUE_OVERFLOW" or similar
> NX-specific meaningful name.

This bit is defined in icswx RFC. Hence I think we should define this in icswx.h.

"Bit 3 of CR0 is undefined or set from XERSO."

Please ignore this patch. Talking to HW team, whenever gets floating point overflow from FPU, XER[S0] will be set and it stays until other FPU operation is executed. It is typical behaviour on powerpc. ixswx RFC says coprocessor can set this XER[S0] to bit 3 and NX is doing this. I think it should have ignored this bit.
 
"An implementation is permitted to set bit 3 of CR0 from XERSO."

So,the issue is not queue overflow problem, but NX is copying XER[S0] which is no use and nothing to do with compression. We need to ignore this bit since it can be set with other valuable return status. I will repost new patch with the proper description. 

Thanks
Haren 
 

> 
>>
>>  static inline int icswx(__be32 ccw, struct coprocessor_request_block *crb)
>>  {
>> diff --git a/drivers/crypto/nx/nx-842-powernv.c b/drivers/crypto/nx/nx-842-powernv.c
>> index 9ef51fa..321b8e8 100644
>> --- a/drivers/crypto/nx/nx-842-powernv.c
>> +++ b/drivers/crypto/nx/nx-842-powernv.c
>> @@ -442,6 +442,15 @@ static int nx842_powernv_function(const unsigned char *in, unsigned int inlen,
>>                              (unsigned int)ccw,
>>                              (unsigned int)be32_to_cpu(crb->ccw));
>>
>> +       /*
>> +        * NX842 coprocessor uses 3rd bit to report queue overflow which is
>> +        * not an error, just for information to user. So, ignore this bit.
>> +        */
> 
> a meaningfully named bit define means you don't need to explain it
> with a comment :-)
> 
> However, I suggest that you do explain *why* a queue overflow isn't an
> error - either here or (probably better) at the #define of the bit -
> because that isn't obvious.
> 
>> +       if (ret & ICSWX_BIT3) {
>> +               pr_info_ratelimited("842 coprocessor queue overflow\n");
> 
> if it's not an error, should this be pr_debug_ratelimited instead?
> What is an end user expected to do if they see this msg in the log?
> 
>> +               ret &= ~ICSWX_BIT3;
>> +       }
>> +
>>         switch (ret) {
>>         case ICSWX_INITIATED:
>>                 ret = wait_for_csb(wmem, csb);
>>
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

      reply	other threads:[~2015-12-12  2:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-06  7:46 crypto/nx842: Ignore queue overflow informative error Haren Myneni
2015-12-06  7:46 ` Haren Myneni
2015-12-06 22:57 ` Daniel Axtens
2015-12-07 19:39   ` Dan Streetman
2015-12-07 19:34 ` Dan Streetman
2015-12-12  2:02   ` Haren Myneni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566B803B.5050608@linux.vnet.ibm.com \
    --to=haren@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=ddstreet@ieee.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=pair@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.