Re: [PATCH] crypto: nx-842: Delete an error message for a failed memory allocation in nx842_pseries_init()

2018-02-14 Thread Dan Streetman
On Wed, Feb 14, 2018 at 11:17 AM, SF Markus Elfring
<elfr...@users.sourceforge.net> wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Wed, 14 Feb 2018 17:05:13 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Reviewed-by: Dan Streetman <ddstr...@ieee.org>

> ---
>  drivers/crypto/nx/nx-842-pseries.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/nx/nx-842-pseries.c 
> b/drivers/crypto/nx/nx-842-pseries.c
> index bf52cd1d7fca..66869976cfa2 100644
> --- a/drivers/crypto/nx/nx-842-pseries.c
> +++ b/drivers/crypto/nx/nx-842-pseries.c
> @@ -1105,10 +1105,9 @@ static int __init nx842_pseries_init(void)
>
> RCU_INIT_POINTER(devdata, NULL);
> new_devdata = kzalloc(sizeof(*new_devdata), GFP_KERNEL);
> -   if (!new_devdata) {
> -   pr_err("Could not allocate memory for device data\n");
> +   if (!new_devdata)
> return -ENOMEM;
> -   }
> +
> RCU_INIT_POINTER(devdata, new_devdata);
>
> ret = vio_register_driver(_vio_driver);
> --
> 2.16.1
>


Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-09-03 Thread Dan Streetman
On Sun, Sep 3, 2017 at 4:32 AM, Haren Myneni <ha...@linux.vnet.ibm.com> wrote:
> On 09/02/2017 09:17 AM, Dan Streetman wrote:
>> On Sat, Sep 2, 2017 at 4:40 AM, Haren Myneni <ha...@linux.vnet.ibm.com> 
>> wrote:
>>> On 08/29/2017 06:58 AM, Dan Streetman wrote:
>>>> On Sat, Jul 22, 2017 at 1:01 AM, Haren Myneni <ha...@linux.vnet.ibm.com> 
>>>> wrote:
>>>>>
>>>>> This patch adds P9 NX support for 842 compression engine. Virtual
>>>>> Accelerator Switchboard (VAS) is used to access 842 engine on P9.
>>>>>
>>>>> For each NX engine per chip, setup receive window using
>>>>> vas_rx_win_open() which configures RxFIFo with FIFO address, lpid,
>>>>> pid and tid values. This unique (lpid, pid, tid) combination will
>>>>> be used to identify the target engine.
>>>>>
>>>>> For crypto open request, open send window on the NX engine for
>>>>> the corresponding chip / cpu where the open request is executed.
>>>>> This send window will be closed upon crypto close request.
>>>>>
>>>>> NX provides high and normal priority FIFOs. For compression /
>>>>> decompression requests, we use only hight priority FIFOs in kernel.
>>>>>
>>>>> Each NX request will be communicated to VAS using copy/paste
>>>>> instructions with vas_copy_crb() / vas_paste_crb() functions.
>>>>>
>>>>> Signed-off-by: Haren Myneni <ha...@us.ibm.com>
>>>>> ---
>>>>>  drivers/crypto/nx/Kconfig  |   1 +
>>>>>  drivers/crypto/nx/nx-842-powernv.c | 375 
>>>>> -
>>>>>  drivers/crypto/nx/nx-842.c |   2 +-
>>>>>  3 files changed, 371 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
>>>>> index ad7552a6998c..cd5dda9c48f4 100644
>>>>> --- a/drivers/crypto/nx/Kconfig
>>>>> +++ b/drivers/crypto/nx/Kconfig
>>>>> @@ -38,6 +38,7 @@ config CRYPTO_DEV_NX_COMPRESS_PSERIES
>>>>>  config CRYPTO_DEV_NX_COMPRESS_POWERNV
>>>>> tristate "Compression acceleration support on PowerNV platform"
>>>>> depends on PPC_POWERNV
>>>>> +   depends on PPC_VAS
>>>>> default y
>>>>> help
>>>>>   Support for PowerPC Nest (NX) compression acceleration. This
>>>>> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
>>>>> b/drivers/crypto/nx/nx-842-powernv.c
>>>>> index c0dd4c7e17d3..13089a0b9dfa 100644
>>>>> --- a/drivers/crypto/nx/nx-842-powernv.c
>>>>> +++ b/drivers/crypto/nx/nx-842-powernv.c
>>>>> @@ -23,6 +23,7 @@
>>>>>  #include 
>>>>>  #include 
>>>>>  #include 
>>>>> +#include 
>>>>>
>>>>>  MODULE_LICENSE("GPL");
>>>>>  MODULE_AUTHOR("Dan Streetman <ddstr...@ieee.org>");
>>>>> @@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");
>>>>>
>>>>>  #define WORKMEM_ALIGN  (CRB_ALIGN)
>>>>>  #define CSB_WAIT_MAX   (5000) /* ms */
>>>>> +#define VAS_RETRIES(10)
>>>>> +/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
>>>>> +#define MAX_CREDITS_PER_RXFIFO (1024)
>>>>>
>>>>>  struct nx842_workmem {
>>>>> /* Below fields must be properly aligned */
>>>>> @@ -42,16 +46,27 @@ struct nx842_workmem {
>>>>>
>>>>> ktime_t start;
>>>>>
>>>>> +   struct vas_window *txwin;   /* Used with VAS function */
>>>>> char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
>>>>>  } __packed __aligned(WORKMEM_ALIGN);
>>>>>
>>>>>  struct nx842_coproc {
>>>>> unsigned int chip_id;
>>>>> unsigned int ct;
>>>>> -   unsigned int ci;
>>>>> +   unsigned int ci;/* Coprocessor instance, used with icswx 
>>>>> */
>>>>> +   struct {
>>>>> +   struct vas_window *rxwin;
>>>>> +   int id;
>>>>> +   } vas;
>>>>> struct list_head list;
>>>>> 

Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-09-02 Thread Dan Streetman
On Sat, Sep 2, 2017 at 4:40 AM, Haren Myneni <ha...@linux.vnet.ibm.com> wrote:
> On 08/29/2017 06:58 AM, Dan Streetman wrote:
>> On Sat, Jul 22, 2017 at 1:01 AM, Haren Myneni <ha...@linux.vnet.ibm.com> 
>> wrote:
>>>
>>> This patch adds P9 NX support for 842 compression engine. Virtual
>>> Accelerator Switchboard (VAS) is used to access 842 engine on P9.
>>>
>>> For each NX engine per chip, setup receive window using
>>> vas_rx_win_open() which configures RxFIFo with FIFO address, lpid,
>>> pid and tid values. This unique (lpid, pid, tid) combination will
>>> be used to identify the target engine.
>>>
>>> For crypto open request, open send window on the NX engine for
>>> the corresponding chip / cpu where the open request is executed.
>>> This send window will be closed upon crypto close request.
>>>
>>> NX provides high and normal priority FIFOs. For compression /
>>> decompression requests, we use only hight priority FIFOs in kernel.
>>>
>>> Each NX request will be communicated to VAS using copy/paste
>>> instructions with vas_copy_crb() / vas_paste_crb() functions.
>>>
>>> Signed-off-by: Haren Myneni <ha...@us.ibm.com>
>>> ---
>>>  drivers/crypto/nx/Kconfig  |   1 +
>>>  drivers/crypto/nx/nx-842-powernv.c | 375 
>>> -
>>>  drivers/crypto/nx/nx-842.c |   2 +-
>>>  3 files changed, 371 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
>>> index ad7552a6998c..cd5dda9c48f4 100644
>>> --- a/drivers/crypto/nx/Kconfig
>>> +++ b/drivers/crypto/nx/Kconfig
>>> @@ -38,6 +38,7 @@ config CRYPTO_DEV_NX_COMPRESS_PSERIES
>>>  config CRYPTO_DEV_NX_COMPRESS_POWERNV
>>> tristate "Compression acceleration support on PowerNV platform"
>>> depends on PPC_POWERNV
>>> +   depends on PPC_VAS
>>> default y
>>> help
>>>   Support for PowerPC Nest (NX) compression acceleration. This
>>> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
>>> b/drivers/crypto/nx/nx-842-powernv.c
>>> index c0dd4c7e17d3..13089a0b9dfa 100644
>>> --- a/drivers/crypto/nx/nx-842-powernv.c
>>> +++ b/drivers/crypto/nx/nx-842-powernv.c
>>> @@ -23,6 +23,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  MODULE_LICENSE("GPL");
>>>  MODULE_AUTHOR("Dan Streetman <ddstr...@ieee.org>");
>>> @@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");
>>>
>>>  #define WORKMEM_ALIGN  (CRB_ALIGN)
>>>  #define CSB_WAIT_MAX   (5000) /* ms */
>>> +#define VAS_RETRIES(10)
>>> +/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
>>> +#define MAX_CREDITS_PER_RXFIFO (1024)
>>>
>>>  struct nx842_workmem {
>>> /* Below fields must be properly aligned */
>>> @@ -42,16 +46,27 @@ struct nx842_workmem {
>>>
>>> ktime_t start;
>>>
>>> +   struct vas_window *txwin;   /* Used with VAS function */
>>> char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
>>>  } __packed __aligned(WORKMEM_ALIGN);
>>>
>>>  struct nx842_coproc {
>>> unsigned int chip_id;
>>> unsigned int ct;
>>> -   unsigned int ci;
>>> +   unsigned int ci;/* Coprocessor instance, used with icswx */
>>> +   struct {
>>> +   struct vas_window *rxwin;
>>> +   int id;
>>> +   } vas;
>>> struct list_head list;
>>>  };
>>>
>>> +/*
>>> + * Send the request to NX engine on the chip for the corresponding CPU
>>> + * where the process is executing. Use with VAS function.
>>> + */
>>> +static DEFINE_PER_CPU(struct nx842_coproc *, coproc_inst);
>>> +
>>>  /* no cpu hotplug on powernv, so this list never changes after init */
>>>  static LIST_HEAD(nx842_coprocs);
>>>  static unsigned int nx842_ct;  /* used in icswx function */
>>> @@ -513,6 +528,105 @@ static int nx842_exec_icswx(const unsigned char *in, 
>>> unsigned int inlen,
>>>  }
>>>
>>>  /**
>>> + * nx842_exec_vas - compress/decompress data using the 842 algorithm
>>> + *
>>> + * (De)compression provided by the NX842 coproc

Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-09-02 Thread Dan Streetman
On Fri, Sep 1, 2017 at 7:29 AM, Michael Ellerman <m...@ellerman.id.au> wrote:
> Hi Dan,
>
> Thanks for reviewing this series.
>
> Dan Streetman <ddstr...@ieee.org> writes:
>> On Tue, Aug 29, 2017 at 5:54 PM, Haren Myneni <ha...@linux.vnet.ibm.com> 
>> wrote:
>>> On 08/29/2017 02:23 PM, Benjamin Herrenschmidt wrote:
>>>> On Tue, 2017-08-29 at 09:58 -0400, Dan Streetman wrote:
>>>>>> +
>>>>>> +   ret = -EINVAL;
>>>>>> +   if (coproc && coproc->vas.rxwin) {
>>>>>> +   wmem->txwin = nx842_alloc_txwin(coproc);
>>>>>
>>>>> this is wrong.  the workmem is scratch memory that's valid only for
>>>>> the duration of a single operation.
>>>
>>> Correct, workmem is used until crypto_free is called.
>>
>> that's not a 'single operation'.  a single operation is compress() or
>> decompress().
>>
>>>>>
>>>>> do you actually need a txwin per crypto transform?  or do you need a
>>>>> txwin per coprocessor?  or txwin per processor?  either per-coproc or
>>>>> per-cpu should be created at driver init and held separately
>>>>> (globally) instead of a per-transform txwin.  I really don't see why
>>>>> you would need a txwin per transform, because the coproc should not
>>>>> care how many different transforms there are.
>>>>
>>>> We should only need a single window for the whole kernel really, plus
>>>> one per user process who wants direct access but that's not relevant
>>>> here.
>>>
>>> Opening send window for each crypto transform (crypto_alloc,
>>> compression/decompression, ..., crypto_free) so that does not
>>> have to wait for the previous copy/paste complete.
>>> VAS will map send and receive windows, and can cache in send
>>> windows (up to 128). So I thought using the same send window
>>> (per chip) for more requests (say 1000) may be adding overhead.
>>>
>>> I will make changes if you prefer using 1 send window per chip.
>>
>> i don't have the spec, so i shouldn't be making the decision on it,
>> but i do know putting a persistent field into the workmem is the wrong
>> location.  If it's valid for the life of the transform, put it into
>> the transform context.  The workmem buffer is intended to be used only
>> during a single operation - it's "working memory" to perform each
>> individual crypto transformation.
>
> I agree workmem isn't the right place for the txwin. But I don't believe
> it actually breaks anything to put txwin there.

it doesn't currently no, but workmem should be able to be memset(0) at
the start of each compress/decompress operation without breaking
anything.

Otherwise, the workmem fields should just go directly into the
nx842_crypto_ctx, which contains other persistent fields.

My concern isn't about breaking anything right now, it's about
misusing the design causing obscure breakage later.

>
> So for now I'm going to merge this series as-is and I've asked Haren to
> send fixes as soon as he can to clean it up.

sure, as i said i've been out of the 842 area for years now so i was
going to just stay out of it...I just happened to notice things i
thought i should comment on :-)

>
> cheers


Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-08-31 Thread Dan Streetman
On Thu, Aug 31, 2017 at 3:44 AM, Haren Myneni <ha...@linux.vnet.ibm.com> wrote:
> Thanks MIchael and Dan for your review comments.
>
>
> On 08/29/2017 06:32 AM, Dan Streetman wrote:
>> On Mon, Aug 28, 2017 at 7:25 PM, Michael Ellerman <m...@ellerman.id.au> 
>> wrote:
>>> Hi Haren,
>>>
>>> Some comments inline ...
>>>
>>> Haren Myneni <ha...@linux.vnet.ibm.com> writes:
>>>
>>>> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
>>>> b/drivers/crypto/nx/nx-842-powernv.c
>>>> index c0dd4c7e17d3..13089a0b9dfa 100644
>>>> --- a/drivers/crypto/nx/nx-842-powernv.c
>>>> +++ b/drivers/crypto/nx/nx-842-powernv.c
>>>> @@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");
>>>>
>>>>  #define WORKMEM_ALIGN(CRB_ALIGN)
>>>>  #define CSB_WAIT_MAX (5000) /* ms */
>>>> +#define VAS_RETRIES  (10)
>>>
>>> Where does that number come from?
>
> Sometimes HW returns copy/paste failures.

why?  what is causing the failure?

> So we should retry the request again. With 10 retries, Test running
> 12 hours was successful for repeated compression/decompression
> requests with 1024 threads.
>
>>>
>>> Do we have any idea what the trade off is between retrying vs just
>>> falling back to doing the request in software?
>
> Not checked the overhead with falling back to SW compression.

SW is very, very, very slow, due to 842 being an unaligned compression format.

>
>>>
>>>> +/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
>>>> +#define MAX_CREDITS_PER_RXFIFO   (1024)
>>>>
>>>>  struct nx842_workmem {
>>>>   /* Below fields must be properly aligned */
>>>> @@ -42,16 +46,27 @@ struct nx842_workmem {
>>>>
>>>>   ktime_t start;
>>>>
>>>> + struct vas_window *txwin;   /* Used with VAS function */
>>>
>>> I don't understand how it makes sense to put txwin and start between the
>>> fields above, and the padding.
>>
>> workmem is a scratch buffer and shouldn't be used for something
>> persistent like this.
>>
>>>
>>> If the workmem pointer you receive is not aligned, then PTR_ALIGN() will
>>> advance it and mean you end up writing over start and txwin.
>
> We always access workmem with PTR_ALIGN even when assigning txwin 
> (nx842_powernv_crypto_init/exit_vas).
> So we should not overwrite start and txwin,
>
> We can add txwin in nx842_crypto_ctx instead of workmem. But nx842_crypto_ctx 
> is used for both powernv and pseries. Hence used workmem. But if 
> nx842_crypto_ctx is preferred, I will send new patch soon.
>
>>>
>>> That's probably not your bug, the code is already like that.
>>
>> no, it's a bug in this patch, because workmem is scratch whose
>> contents are only valid for the duration of each operation (compress
>> or decompress).
>>
>>>
>>>>   char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
>>>>  } __packed __aligned(WORKMEM_ALIGN);
>>>
>
> Thanks
> Haren
>


Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-08-31 Thread Dan Streetman
On Tue, Aug 29, 2017 at 5:54 PM, Haren Myneni <ha...@linux.vnet.ibm.com> wrote:
> On 08/29/2017 02:23 PM, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-08-29 at 09:58 -0400, Dan Streetman wrote:
>>>> +
>>>> +   ret = -EINVAL;
>>>> +   if (coproc && coproc->vas.rxwin) {
>>>> +   wmem->txwin = nx842_alloc_txwin(coproc);
>>>
>>> this is wrong.  the workmem is scratch memory that's valid only for
>>> the duration of a single operation.
>
> Correct, workmem is used until crypto_free is called.

that's not a 'single operation'.  a single operation is compress() or
decompress().

>>>
>>> do you actually need a txwin per crypto transform?  or do you need a
>>> txwin per coprocessor?  or txwin per processor?  either per-coproc or
>>> per-cpu should be created at driver init and held separately
>>> (globally) instead of a per-transform txwin.  I really don't see why
>>> you would need a txwin per transform, because the coproc should not
>>> care how many different transforms there are.
>>
>> We should only need a single window for the whole kernel really, plus
>> one per user process who wants direct access but that's not relevant
>> here.
>
> Opening send window for each crypto transform (crypto_alloc,
> compression/decompression, ..., crypto_free) so that does not
> have to wait for the previous copy/paste complete.
> VAS will map send and receive windows, and can cache in send
> windows (up to 128). So I thought using the same send window
> (per chip) for more requests (say 1000) may be adding overhead.
>
> I will make changes if you prefer using 1 send window per chip.

i don't have the spec, so i shouldn't be making the decision on it,
but i do know putting a persistent field into the workmem is the wrong
location.  If it's valid for the life of the transform, put it into
the transform context.  The workmem buffer is intended to be used only
during a single operation - it's "working memory" to perform each
individual crypto transformation.

>
>>
>> Cheers,
>> Ben.
>>
>


Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-08-29 Thread Dan Streetman
On Sat, Jul 22, 2017 at 1:01 AM, Haren Myneni <ha...@linux.vnet.ibm.com> wrote:
>
> This patch adds P9 NX support for 842 compression engine. Virtual
> Accelerator Switchboard (VAS) is used to access 842 engine on P9.
>
> For each NX engine per chip, setup receive window using
> vas_rx_win_open() which configures RxFIFo with FIFO address, lpid,
> pid and tid values. This unique (lpid, pid, tid) combination will
> be used to identify the target engine.
>
> For crypto open request, open send window on the NX engine for
> the corresponding chip / cpu where the open request is executed.
> This send window will be closed upon crypto close request.
>
> NX provides high and normal priority FIFOs. For compression /
> decompression requests, we use only hight priority FIFOs in kernel.
>
> Each NX request will be communicated to VAS using copy/paste
> instructions with vas_copy_crb() / vas_paste_crb() functions.
>
> Signed-off-by: Haren Myneni <ha...@us.ibm.com>
> ---
>  drivers/crypto/nx/Kconfig  |   1 +
>  drivers/crypto/nx/nx-842-powernv.c | 375 
> -
>  drivers/crypto/nx/nx-842.c |   2 +-
>  3 files changed, 371 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
> index ad7552a6998c..cd5dda9c48f4 100644
> --- a/drivers/crypto/nx/Kconfig
> +++ b/drivers/crypto/nx/Kconfig
> @@ -38,6 +38,7 @@ config CRYPTO_DEV_NX_COMPRESS_PSERIES
>  config CRYPTO_DEV_NX_COMPRESS_POWERNV
> tristate "Compression acceleration support on PowerNV platform"
> depends on PPC_POWERNV
> +   depends on PPC_VAS
> default y
> help
>   Support for PowerPC Nest (NX) compression acceleration. This
> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
> b/drivers/crypto/nx/nx-842-powernv.c
> index c0dd4c7e17d3..13089a0b9dfa 100644
> --- a/drivers/crypto/nx/nx-842-powernv.c
> +++ b/drivers/crypto/nx/nx-842-powernv.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Dan Streetman <ddstr...@ieee.org>");
> @@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");
>
>  #define WORKMEM_ALIGN  (CRB_ALIGN)
>  #define CSB_WAIT_MAX   (5000) /* ms */
> +#define VAS_RETRIES(10)
> +/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
> +#define MAX_CREDITS_PER_RXFIFO (1024)
>
>  struct nx842_workmem {
> /* Below fields must be properly aligned */
> @@ -42,16 +46,27 @@ struct nx842_workmem {
>
> ktime_t start;
>
> +   struct vas_window *txwin;   /* Used with VAS function */
> char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
>  } __packed __aligned(WORKMEM_ALIGN);
>
>  struct nx842_coproc {
> unsigned int chip_id;
> unsigned int ct;
> -   unsigned int ci;
> +   unsigned int ci;/* Coprocessor instance, used with icswx */
> +   struct {
> +   struct vas_window *rxwin;
> +   int id;
> +   } vas;
> struct list_head list;
>  };
>
> +/*
> + * Send the request to NX engine on the chip for the corresponding CPU
> + * where the process is executing. Use with VAS function.
> + */
> +static DEFINE_PER_CPU(struct nx842_coproc *, coproc_inst);
> +
>  /* no cpu hotplug on powernv, so this list never changes after init */
>  static LIST_HEAD(nx842_coprocs);
>  static unsigned int nx842_ct;  /* used in icswx function */
> @@ -513,6 +528,105 @@ static int nx842_exec_icswx(const unsigned char *in, 
> unsigned int inlen,
>  }
>
>  /**
> + * nx842_exec_vas - compress/decompress data using the 842 algorithm
> + *
> + * (De)compression provided by the NX842 coprocessor on IBM PowerNV systems.
> + * This compresses or decompresses the provided input buffer into the 
> provided
> + * output buffer.
> + *
> + * Upon return from this function @outlen contains the length of the
> + * output data.  If there is an error then @outlen will be 0 and an
> + * error will be specified by the return code from this function.
> + *
> + * The @workmem buffer should only be used by one function call at a time.
> + *
> + * @in: input buffer pointer
> + * @inlen: input buffer size
> + * @out: output buffer pointer
> + * @outlenp: output buffer size pointer
> + * @workmem: working memory buffer pointer, size determined by
> + *   nx842_powernv_driver.workmem_size
> + * @fc: function code, see CCW Function Codes in nx-842.h
> + *
> + * Returns:
> + *   0 Success, output of length @outlenp stored in the buffer
> + * at @out
> + *   -

Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

2017-08-29 Thread Dan Streetman
On Mon, Aug 28, 2017 at 7:25 PM, Michael Ellerman  wrote:
> Hi Haren,
>
> Some comments inline ...
>
> Haren Myneni  writes:
>
>> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
>> b/drivers/crypto/nx/nx-842-powernv.c
>> index c0dd4c7e17d3..13089a0b9dfa 100644
>> --- a/drivers/crypto/nx/nx-842-powernv.c
>> +++ b/drivers/crypto/nx/nx-842-powernv.c
>> @@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");
>>
>>  #define WORKMEM_ALIGN(CRB_ALIGN)
>>  #define CSB_WAIT_MAX (5000) /* ms */
>> +#define VAS_RETRIES  (10)
>
> Where does that number come from?
>
> Do we have any idea what the trade off is between retrying vs just
> falling back to doing the request in software?
>
>> +/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
>> +#define MAX_CREDITS_PER_RXFIFO   (1024)
>>
>>  struct nx842_workmem {
>>   /* Below fields must be properly aligned */
>> @@ -42,16 +46,27 @@ struct nx842_workmem {
>>
>>   ktime_t start;
>>
>> + struct vas_window *txwin;   /* Used with VAS function */
>
> I don't understand how it makes sense to put txwin and start between the
> fields above, and the padding.

workmem is a scratch buffer and shouldn't be used for something
persistent like this.

>
> If the workmem pointer you receive is not aligned, then PTR_ALIGN() will
> advance it and mean you end up writing over start and txwin.
>
> That's probably not your bug, the code is already like that.

no, it's a bug in this patch, because workmem is scratch whose
contents are only valid for the duration of each operation (compress
or decompress).

>
>>   char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
>>  } __packed __aligned(WORKMEM_ALIGN);
>
>> @@ -576,6 +690,198 @@ static inline void nx842_add_coprocs_list(struct 
>> nx842_coproc *coproc,
>>   list_add(>list, _coprocs);
>>  }
>>
>> +/*
>> + * Identify chip ID for each CPU and save coprocesor adddress for the
>> + * corresponding NX engine in percpu coproc_inst.
>> + * coproc_inst is used in crypto_init to open send window on the NX instance
>> + * for the corresponding CPU / chip where the open request is executed.
>> + */
>> +static void nx842_set_per_cpu_coproc(struct nx842_coproc *coproc)
>> +{
>> + unsigned int i, chip_id;
>> +
>> + for_each_possible_cpu(i) {
>> + chip_id = cpu_to_chip_id(i);
>> +
>> + if (coproc->chip_id == chip_id)
>> + per_cpu(coproc_inst, i) = coproc;
>> + }
>> +}
>> +
>> +
>> +static struct vas_window *nx842_alloc_txwin(struct nx842_coproc *coproc)
>> +{
>> + struct vas_window *txwin = NULL;
>> + struct vas_tx_win_attr txattr;
>> +
>> + /*
>> +  * Kernel requests will be high priority. So open send
>> +  * windows only for high priority RxFIFO entries.
>> +  */
>> + vas_init_tx_win_attr(, coproc->ct);
>> + txattr.lpid = 0;/* lpid is 0 for kernel requests */
>> + txattr.pid = mfspr(SPRN_PID);
>
> Should we be using SPRN_PID here? That makes it appear as if it comes
> from the current user process, which seems fishy.
>
>> + /*
>> +  * Open a VAS send window which is used to send request to NX.
>> +  */
>> + txwin = vas_tx_win_open(coproc->vas.id, coproc->ct, );
>> + if (IS_ERR(txwin)) {
>> + pr_err("ibm,nx-842: Can not open TX window: %ld\n",
>> + PTR_ERR(txwin));
>> + return NULL;
>> + }
>> +
>> + return txwin;
>> +}
>> +
>> +static int __init vas_cfg_coproc_info(struct device_node *dn, int chip_id,
>> + int vasid)
>> +{
>> + struct vas_window *rxwin = NULL;
>> + struct vas_rx_win_attr rxattr;
>> + struct nx842_coproc *coproc;
>> + u32 lpid, pid, tid, fifo_size;
>> + u64 rx_fifo;
>> + const char *priority;
>> + int ret;
>> +
>> + ret = of_property_read_u64(dn, "rx-fifo-address", (void *)_fifo);
>   
>   Unnecessary cast.
>
>> + if (ret) {
>> + pr_err("Missing rx-fifo-address property\n");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(dn, "rx-fifo-size", _size);
>> + if (ret) {
>> + pr_err("Missing rx-fifo-size property\n");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(dn, "lpid", );
>> + if (ret) {
>> + pr_err("Missing lpid property\n");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(dn, "pid", );
>> + if (ret) {
>> + pr_err("Missing pid property\n");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(dn, "tid", );
>> + if (ret) {
>> + pr_err("Missing tid property\n");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_string(dn, "priority", );
>> + if 

Re: [PATCH] crypto/nx: Update MAINTAINERS entry for 842 compression

2017-04-01 Thread Dan Streetman
On Sat, Apr 1, 2017 at 1:25 PM, Haren Myneni <ha...@linux.vnet.ibm.com> wrote:
> [PATCH] crypto/nx: Update MAINTAINERS entry for 842 compression
>
> Signed-off-by: Haren Myneni <ha...@us.ibm.com>

Acked-by: Dan Streetman <ddstr...@ieee.org>

>
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c265a5f..4cfd225 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6211,7 +6211,7 @@ F:drivers/crypto/nx/nx_csbcpb.h
>  F: drivers/crypto/nx/nx_debugfs.h
>
>  IBM Power 842 compression accelerator
> -M: Dan Streetman <ddstr...@ieee.org>
> +M: Haren Myneni <ha...@us.ibm.com>
>  S: Supported
>  F: drivers/crypto/nx/Makefile
>  F: drivers/crypto/nx/Kconfig
> --
> 1.8.3.1
>
>
>


[PATCH] crypto: 842 - remove WARN inside printk

2015-12-21 Thread Dan Streetman
Remove the WARN() from the beN_to_cpu macro, which is used as a param to a
pr_debug() call.  With a certain kernel config, this printk-in-printk
results in the no_printk() macro trying to recursively call the
no_printk() macro, and since macros can't recursively call themselves
a build error results.

Reported-by: Randy Dunlap <rdun...@infradead.org>
Signed-off-by: Dan Streetman <ddstr...@ieee.org>
---
 lib/842/842_decompress.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lib/842/842_decompress.c b/lib/842/842_decompress.c
index 8881dad..a7f278d 100644
--- a/lib/842/842_decompress.c
+++ b/lib/842/842_decompress.c
@@ -69,7 +69,7 @@ struct sw842_param {
((s) == 2 ? be16_to_cpu(get_unaligned((__be16 *)d)) :   \
 (s) == 4 ? be32_to_cpu(get_unaligned((__be32 *)d)) :   \
 (s) == 8 ? be64_to_cpu(get_unaligned((__be64 *)d)) :   \
-WARN(1, "pr_debug param err invalid size %x\n", s))
+0)
 
 static int next_bits(struct sw842_param *p, u64 *d, u8 n);
 
@@ -202,10 +202,14 @@ static int __do_index(struct sw842_param *p, u8 size, u8 
bits, u64 fsize)
return -EINVAL;
}
 
-   pr_debug("index%x to %lx off %lx adjoff %lx tot %lx data %lx\n",
-size, (unsigned long)index, (unsigned long)(index * size),
-(unsigned long)offset, (unsigned long)total,
-(unsigned long)beN_to_cpu(>ostart[offset], size));
+   if (size != 2 && size != 4 && size != 8)
+   WARN(1, "__do_index invalid size %x\n", size);
+   else
+   pr_debug("index%x to %lx off %lx adjoff %lx tot %lx data %lx\n",
+size, (unsigned long)index,
+(unsigned long)(index * size), (unsigned long)offset,
+(unsigned long)total,
+(unsigned long)beN_to_cpu(>ostart[offset], size));
 
memcpy(p->out, >ostart[offset], size);
p->out += size;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: crypto/nx842: Ignore queue overflow informative error

2015-12-07 Thread Dan Streetman
On Sun, Dec 6, 2015 at 2:46 AM, Haren Myneni  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 
>
> 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.

>
>  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);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: crypto/nx842: Ignore queue overflow informative error

2015-12-07 Thread Dan Streetman
On Sun, Dec 6, 2015 at 5:57 PM, Daniel Axtens  wrote:
> Haren Myneni  writes:
>
>> 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.
>
> What queue, and what happens when the queue overflows? It seems like
> *something* would need to be done, somewhere, by someone?
>
> I realise that as a piece of IBM hardware this is probably an incredibly
> optimistic question, but is this behaviour documented publically anywhere?
> (As a distant second best, is it documented internally anywhere that I
> can read?)

When I worked there, it unfortunately wasn't public and there was no
future plan to make it public, but things might have changed since I
left.  Maybe it will be included in future openpower documentation...?

>
>> --- 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.
>> +  */
>> + if (ret & ICSWX_BIT3) {
>> + pr_info_ratelimited("842 coprocessor queue overflow\n");
> It doesn't look like this is done anywhere else in the file, but should
> this be prefixed with something? Something like "nx-842: Coprocessor
> queue overflow"?

it defines pr_fmt at the top of the file so it will be prefixed with
the module name.

>
> Regards,
> Daniel
>
>> + ret &= ~ICSWX_BIT3;
>> + }
>> +
>>   switch (ret) {
>>   case ICSWX_INITIATED:
>>   ret = wait_for_csb(wmem, csb);
>>
>>
>> ___
>> Linuxppc-dev mailing list
>> linuxppc-...@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: nx: use of_property_read_u32()

2015-11-23 Thread Dan Streetman
On Mon, Nov 23, 2015 at 4:56 AM, Saurabh Sengar <saurabh.tr...@gmail.com> wrote:
> use of_propert_read_u32() for reading int value,
> it can help reducing number of variables used
>
> Signed-off-by: Saurabh Sengar <saurabh.tr...@gmail.com>

Acked-by: Dan Streetman <ddstr...@ieee.org>

> ---
>  drivers/crypto/nx/nx-842-powernv.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
> b/drivers/crypto/nx/nx-842-powernv.c
> index 9ef51fa..87f7a0f 100644
> --- a/drivers/crypto/nx/nx-842-powernv.c
> +++ b/drivers/crypto/nx/nx-842-powernv.c
> @@ -525,7 +525,6 @@ static int nx842_powernv_decompress(const unsigned char 
> *in, unsigned int inlen,
>  static int __init nx842_powernv_probe(struct device_node *dn)
>  {
> struct nx842_coproc *coproc;
> -   struct property *ct_prop, *ci_prop;
> unsigned int ct, ci;
> int chip_id;
>
> @@ -534,18 +533,16 @@ static int __init nx842_powernv_probe(struct 
> device_node *dn)
> pr_err("ibm,chip-id missing\n");
> return -EINVAL;
> }
> -   ct_prop = of_find_property(dn, "ibm,842-coprocessor-type", NULL);
> -   if (!ct_prop) {
> +
> +   if (of_property_read_u32(dn, "ibm,842-coprocessor-type", )) {
> pr_err("ibm,842-coprocessor-type missing\n");
> return -EINVAL;
> }
> -   ct = be32_to_cpu(*(unsigned int *)ct_prop->value);
> -   ci_prop = of_find_property(dn, "ibm,842-coprocessor-instance", NULL);
> -   if (!ci_prop) {
> +
> +   if (of_property_read_u32(dn, "ibm,842-coprocessor-instance", )) {
> pr_err("ibm,842-coprocessor-instance missing\n");
> return -EINVAL;
> }
> -   ci = be32_to_cpu(*(unsigned int *)ci_prop->value);
>
> coproc = kmalloc(sizeof(*coproc), GFP_KERNEL);
> if (!coproc)
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] nx-842: Endian swap ->count before handing over to the nx-842 compressor

2015-11-02 Thread Dan Streetman
On Sat, Oct 31, 2015 at 2:39 PM, Ram Pai <linux...@us.ibm.com> wrote:
> On Sat, Oct 31, 2015 at 08:38:17AM -0400, Dan Streetman wrote:
>> On Fri, Oct 30, 2015 at 6:45 PM, Ram Pai <linux...@us.ibm.com> wrote:
>> > The nx-842 compressor overshoots the output buffer corrupting memory. 
>> > Verified
>> > that the following patch fixes the issue on a little-endian system.
>> >
>> > Signed-off-by: Ram Pai <linux...@us.ibm.com>
>> > ---
>> >  drivers/crypto/nx/nx-842-powernv.c |2 +-
>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/drivers/crypto/nx/nx-842-powernv.c 
>> > b/drivers/crypto/nx/nx-842-powernv.c
>> > index 3750e13..3b80ea7 100644
>> > --- a/drivers/crypto/nx/nx-842-powernv.c
>> > +++ b/drivers/crypto/nx/nx-842-powernv.c
>> > @@ -66,7 +66,7 @@ static void setup_indirect_dde(struct 
>> > data_descriptor_entry *dde,
>> >unsigned int dde_count, unsigned int 
>> > byte_count)
>> >  {
>> > dde->flags = 0;
>> > -   dde->count = dde_count;
>> > +   dde->count = cpu_to_be32(dde_count);
>>
>> ->count is u8, I don't think this is correct...you could change
>> dde_count to a u8, but I'm skeptical that's required at all, are you
>> sure this is your problem?  The dde->length should restrict the coproc
>> from r/w past the output buffer anyway, even if the ->count is too
>> large...
>
> Dan, you are right. The problem does resurface even after the above change.
> There is something else going on. Please ignore this patch for now.
>
> I see corruption, when the output buffer is smaller than needed to hold
> the compressed data. I expect it to return -ENOSPC, but its not; instead
> overshoots and corrupts.

what are the in/out buffer sizes and alignment when it overruns the
output buffer?  and is it for compression or decompression?  does it
happen if you disable CRC (since Haren just enabled it recently)?


>
> RP
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] nx-842: Endian swap ->count before handing over to the nx-842 compressor

2015-10-31 Thread Dan Streetman
On Fri, Oct 30, 2015 at 6:45 PM, Ram Pai  wrote:
> The nx-842 compressor overshoots the output buffer corrupting memory. Verified
> that the following patch fixes the issue on a little-endian system.
>
> Signed-off-by: Ram Pai 
> ---
>  drivers/crypto/nx/nx-842-powernv.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/crypto/nx/nx-842-powernv.c 
> b/drivers/crypto/nx/nx-842-powernv.c
> index 3750e13..3b80ea7 100644
> --- a/drivers/crypto/nx/nx-842-powernv.c
> +++ b/drivers/crypto/nx/nx-842-powernv.c
> @@ -66,7 +66,7 @@ static void setup_indirect_dde(struct data_descriptor_entry 
> *dde,
>unsigned int dde_count, unsigned int 
> byte_count)
>  {
> dde->flags = 0;
> -   dde->count = dde_count;
> +   dde->count = cpu_to_be32(dde_count);

->count is u8, I don't think this is correct...you could change
dde_count to a u8, but I'm skeptical that's required at all, are you
sure this is your problem?  The dde->length should restrict the coproc
from r/w past the output buffer anyway, even if the ->count is too
large...

> dde->index = 0;
> dde->length = cpu_to_be32(byte_count);
> dde->address = cpu_to_be64(nx842_get_pa(ddl));
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] nx-842: Ignore bit 3 of condition register returned by icswx

2015-10-31 Thread Dan Streetman
On Fri, Oct 30, 2015 at 6:43 PM, Ram Pai <linux...@us.ibm.com> wrote:
> icswx occasionally under heavy load sets bit 3 of condition register 0.
> It has no software implication.
>
> Currently that bit is interpreted by the driver as a failure, when
> it should have calmly ignored it.
>
> Signed-off-by: Ram Pai <linux...@us.ibm.com>

Acked-by: Dan Streetman <ddstr...@ieee.org>

> ---
>  arch/powerpc/include/asm/icswx.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/icswx.h 
> b/arch/powerpc/include/asm/icswx.h
> index 9f8402b..bce20c7 100644
> --- a/arch/powerpc/include/asm/icswx.h
> +++ b/arch/powerpc/include/asm/icswx.h
> @@ -177,7 +177,7 @@ static inline int icswx(__be32 ccw, struct 
> coprocessor_request_block *crb)
> : "r" (ccw_reg), "r" (crb)
> : "cr0", "memory");
>
> -   return (int)((cr >> 28) & 0xf);
> +   return (int)((cr >> 28) & 0xe);
>  }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: add asynchronous compression support

2015-10-28 Thread Dan Streetman
On Wed, Oct 21, 2015 at 3:59 AM, Li, Weigang <weigang...@intel.com> wrote:
>> -Original Message-
>> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
>> Sent: Wednesday, October 21, 2015 3:34 PM
>> To: Sergey Senozhatsky
>> Cc: Minchan Kim; Joonsoo Kim; Dan Streetman; Seth Jennings; Li, Weigang;
>> Struk, Tadeusz
>> Subject: Re: [PATCH] crypto: add asynchronous compression support
>>
>> On Wed, Oct 21, 2015 at 04:33:22PM +0900, Sergey Senozhatsky wrote:
>> >
>> > the thing is -- I still want to have/use SW compressors; and they [the
>> > existing S/W algorithms] want virtual addresses. so we need to
>> > kmap_atomic pages in every SW algorithm? isn't it simpler to keep
>> > kmap_atomic_to_page around?
>>
>> The Crypto API will do it for you.  Have a look at how we handle it for aead
>> and ahash for example.
>>
>> Cheers,
>> --
>> Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page:
>> http://gondor.apana.org.au/~herbert/
>> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
> Adding the "linux-crypto" list back to the latest discussion.

re: zswap, I suspect it won't be able to use async compression,
because when its store function returns the page must be available for
reallocation.  Of course, async compression can be useful elsewhere.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

2015-09-24 Thread Dan Streetman
On Wed, Sep 23, 2015 at 5:54 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Tue, Sep 22, 2015 at 11:08:22AM -0400, Dan Streetman wrote:
>>
>> you think we should just strip out the 842-nx alignment/sizing code
>> and change it to fallback to the sw driver?
>
> Right, if the only intended user can provide aligned input then
> by all means make the unaligned case use the software fallback as
> there is no point in investing any effort in making it fast.

ok sounds good.  thanks!

>
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

2015-09-22 Thread Dan Streetman
On Tue, Sep 22, 2015 at 10:42 AM, Herbert Xu
<herb...@gondor.apana.org.au> wrote:
> On Tue, Sep 22, 2015 at 10:39:53AM -0400, Dan Streetman wrote:
>>
>> hmm, that's true, and that would simplify the code a lot!  No need for
>> the header anymore.  But, since the sw driver is sooo much slower, it
>> would be important to be able to communicate the alignment and size
>> limits to the caller of the crypto compression api, via cra_alignmask
>> and cra_blocksize (for minimum size), as well as new fields for max
>> size (maybe cra_maxsize) and buffer length multiple - i.e. the buffer
>> length must be a multiple of N (maybe cra_blockmult or cra_blockmodulo
>> or something).  Otherwise callers would get unexpectedly slow
>> performance if they use the wrong alignment or size.
>
> Right.  So who actually uses this?

currently, zswap.  Probably nobody else.  And zswap will always
provide an input buffer that is exactly one page, and output buffer
that is exactly 2 pages.  So, it will always meet the 842 hw
requirements.

Maybe I got a little too excited about adding flexibility to the 842
hw driver? ;-)

As long as zswap is the only user of the 842 hw driver, it could be
changed to simply return error for any mis-aligned or mis-sized
buffer.  A quick git grep of crypto_comp shows the only users of it
outside of crypto itself are ubifs and ipcomp.  ubifs uses only lzo
and deflate. ipcomp appears to use only deflate (it also lists lzs and
lzjh but i don't see those implemented anywhere).

you think we should just strip out the 842-nx alignment/sizing code
and change it to fallback to the sw driver?


>
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

2015-09-22 Thread Dan Streetman
On Tue, Sep 22, 2015 at 8:21 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Sep 21, 2015 at 11:21:14AM -0400, Dan Streetman wrote:
>>
>> As far as the hw and sw drivers producing the exact same output, I
>> don't think that's possible with the current hw and sw drivers,
>> because the hw driver may have to add a header to the actual byte
>> stream that the hw creates, depending on buffer alignment and size
>> (the hw has specific restrictions).  Currently, the sw driver doesn't
>> understand that header that the 842 hw driver creates, although that
>> could be added to the sw driver.  And, the hw driver skips adding the
>> header if the buffers are correctly aligned/sized, which would result
>> in a test vector failure if it doesn't align the buffer the same way
>> each time.
>
> I guess they don't have to be exactly the same.  As long as each
> can take the output of the other and compress/decompress them it
> should be fine.

The hw driver code that handles the re-aligning and re-sizing, and
creating the header, is (mostly) isolated from the code that actually
talks to the NX 842 coprocessor, it's in drivers/crypto/nx/nx-842.c.

Haren, you could change the 842 sw driver to use that code to parse
compressed 842 buffers.  You'll have to modify the nx-842.c code some
though, as it expects to not only parse the header but also re-align
and re-size input and output buffers, which the sw driver doesn't need
to do, it can process buffers with any alignment and size.  Maybe you
could split out the header processing code into somewhere common, and
leave the code in 842-nx.c that actually re-aligns and re-sizes the
buffers.


>
>> Also, it might be a good time to add what we talked about a while ago,
>> to push the alignment/size restrictions into the crypto compression
>> layer, by adding cra_alignmask and cra_blocksize support to
>> crypto/compress.c.  Since the 842 hw has requirements not only for
>> specific alignment and min/max sizes, but also a requirement for
>> specific length multiple (i.e. must be !(len % 8)) it might be
>> worthwhile to also add a cra_sizemodulo or something like that.
>> However, if the common crypto alignment/size handling code allows any
>> alignment/size buffers (instead of just returning error for mis-sized
>> buffers), I think a common crypto header would need to be added in
>> cases of mis-sizing, which may not be appropriate for common code.
>> Alternately, the common crypto code could just return error for
>> mis-sized buffers; users of the crypto comp api would just have to
>> check crypto_tfm_alg_blocksize() before calling.
>
> I'd like to see another hardware implementation before we start
> moving this into the API.

ok.

>
>> In case I haven't said it before, I really hate how the 842 hw
>> requires specific alignment and sizing.  How hard is it to add support
>> for any alignment/size in the hw?!?
>
> Another option is to use a software fallback for the cases that
> the hardware can't handle.

hmm, that's true, and that would simplify the code a lot!  No need for
the header anymore.  But, since the sw driver is sooo much slower, it
would be important to be able to communicate the alignment and size
limits to the caller of the crypto compression api, via cra_alignmask
and cra_blocksize (for minimum size), as well as new fields for max
size (maybe cra_maxsize) and buffer length multiple - i.e. the buffer
length must be a multiple of N (maybe cra_blockmult or cra_blockmodulo
or something).  Otherwise callers would get unexpectedly slow
performance if they use the wrong alignment or size.

thanks!

>
> Cheers,
> --
> Email: Herbert Xu <herb...@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

2015-09-21 Thread Dan Streetman
On Mon, Sep 21, 2015 at 10:26 AM, Herbert Xu
 wrote:
> On Sat, Sep 19, 2015 at 05:02:42PM -0700, Haren Myneni wrote:
>> Hi,
>>
>> This patch allows nx842 coprocessor to add CRC for compression and
>> check the computed CRC value for uncompression. Please let me know
>> if you have any comments.
>>
>> Thanks
>> Haren
>>
>> commit d0b34d2e3ed41e7ec2afdbd654f0dd7716e4d4c0
>> Author: Haren Myneni 
>> Date:   Sat Sep 12 01:20:51 2015 -0700
>>
>> crypto/nx842: Add CRC and validation support
>>
>> This patch adds CRC generation and validation support for nx-842.
>> Add CRC flag so that nx842 coprocessor includes CRC during
>> compression and validates during uncompression.
>>
>> Signed-off-by: Haren Myneni 
>
> In future please post the patch without all the metadata.  You
> can use the helper git format-patch to help you prepare the patch
> for submission.
>
> As to the CRC itself what is the purpose of this and wouldn't it
> fail our test vectors if we had any? Remember that we also have a
> software implementation now and the hardware should produce exactly
> the same output as the software version.

As far as the hw and sw drivers producing the exact same output, I
don't think that's possible with the current hw and sw drivers,
because the hw driver may have to add a header to the actual byte
stream that the hw creates, depending on buffer alignment and size
(the hw has specific restrictions).  Currently, the sw driver doesn't
understand that header that the 842 hw driver creates, although that
could be added to the sw driver.  And, the hw driver skips adding the
header if the buffers are correctly aligned/sized, which would result
in a test vector failure if it doesn't align the buffer the same way
each time.

However, you're right that if the hw driver is doing crc checking, the
sw driver needs to be updated to make sure to add the crc to anything
it encodes, otherwise the hw driver will fail decompressing it; Haren,
you'll need to update the lib/842 code to also include crc
creation/checking.

Also, it might be a good time to add what we talked about a while ago,
to push the alignment/size restrictions into the crypto compression
layer, by adding cra_alignmask and cra_blocksize support to
crypto/compress.c.  Since the 842 hw has requirements not only for
specific alignment and min/max sizes, but also a requirement for
specific length multiple (i.e. must be !(len % 8)) it might be
worthwhile to also add a cra_sizemodulo or something like that.
However, if the common crypto alignment/size handling code allows any
alignment/size buffers (instead of just returning error for mis-sized
buffers), I think a common crypto header would need to be added in
cases of mis-sizing, which may not be appropriate for common code.
Alternately, the common crypto code could just return error for
mis-sized buffers; users of the crypto comp api would just have to
check crypto_tfm_alg_blocksize() before calling.

In case I haven't said it before, I really hate how the 842 hw
requires specific alignment and sizing.  How hard is it to add support
for any alignment/size in the hw?!?


>
> Thanks,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] MAINTAINERS: change 842 NX owner email address

2015-07-29 Thread Dan Streetman
Change my IBM email to my personal IEEE email.

I'm leaving IBM, so my email there won't work anymore.  This changes
the owner to my personal email, so I can still get cc'ed on patches,
until someone at IBM sends a patch to take it over.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 91e9b78..6295ec5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5073,7 +5073,7 @@ F:drivers/crypto/nx/nx_csbcpb.h
 F: drivers/crypto/nx/nx_debugfs.h
 
 IBM Power 842 compression accelerator
-M: Dan Streetman ddstr...@us.ibm.com
+M: Dan Streetman ddstr...@ieee.org
 S: Supported
 F: drivers/crypto/nx/Makefile
 F: drivers/crypto/nx/Kconfig
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] crypto: nx - use be32_to_cpu for __be32 field in debug msg

2015-07-29 Thread Dan Streetman
One of the debug messages in the NX 842 PowerNV driver is missing
the required be32_to_cpu() wrapper when accessing the __be32 field
csb-count.  Add the wrapper so the message will show the correct count.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-powernv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 684ce51..3750e13 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -346,7 +346,8 @@ static int wait_for_csb(struct nx842_workmem *wmem,
}
 
/* successful completion */
-   pr_debug_ratelimited(Processed %u bytes in %lu us\n, csb-count,
+   pr_debug_ratelimited(Processed %u bytes in %lu us\n,
+be32_to_cpu(csb-count),
 (unsigned long)ktime_us_delta(now, start));
 
return 0;
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/8] crypto: nx - remove __init/__exit from VIO functions

2015-07-22 Thread Dan Streetman
Remove the __init and __exit modifiers from the VIO driver probe and
remove functions.

The driver functions should not be marked __init/__exit because they
can/will be called during runtime, not only at module init and exit.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-pseries.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index d44524d..fc59520 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -977,8 +977,8 @@ static struct nx842_driver nx842_pseries_driver = {
.decompress =   nx842_pseries_decompress,
 };
 
-static int __init nx842_probe(struct vio_dev *viodev,
- const struct vio_device_id *id)
+static int nx842_probe(struct vio_dev *viodev,
+  const struct vio_device_id *id)
 {
struct nx842_devdata *old_devdata, *new_devdata = NULL;
unsigned long flags;
@@ -1050,7 +1050,7 @@ error:
return ret;
 }
 
-static int __exit nx842_remove(struct vio_dev *viodev)
+static int nx842_remove(struct vio_dev *viodev)
 {
struct nx842_devdata *old_devdata;
unsigned long flags;
@@ -1081,7 +1081,7 @@ static struct vio_device_id nx842_vio_driver_ids[] = {
 static struct vio_driver nx842_vio_driver = {
.name = KBUILD_MODNAME,
.probe = nx842_probe,
-   .remove = __exit_p(nx842_remove),
+   .remove = nx842_remove,
.get_desired_dma = nx842_get_desired_dma,
.id_table = nx842_vio_driver_ids,
 };
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/8] remove 'platform' shared NX driver

2015-07-22 Thread Dan Streetman
The shared 'platform' driver module isn't needed, the platform drivers
can directly register with crypto instead.  It only adds unneeded
complexity and problems.

The first 4 patches are minor updates/bugfixes to the pSeries driver.

The 5th patch is a minor update to the NX crypto driver.

The last 3 patches merge the crypto and common code driver, and move
the crypto compression driver registration into the platform (pSeries
and PowerNV) drivers.  Both platform drivers use the same alg name and
driver name when registering, but since only one (at most) will register
on a system, depending on the platform, their registration will not
conflict.

Dan Streetman (8):
  crypto: nx - remove __init/__exit from VIO functions
  crypto: nx - remove pSeries NX 'status' field
  crypto: nx - move kzalloc() out of spinlock
  crypto: nx - don't register pSeries driver if ENODEV
  crypto: nx - use common code for both NX decompress success cases
  crypto: nx - merge nx-compress and nx-compress-crypto
  crypto: nx - rename nx-842-crypto.c to nx-842.c
  crypto: nx - make platform drivers directly register with crypto

 drivers/crypto/nx/Kconfig   |  17 +-
 drivers/crypto/nx/Makefile  |   8 +-
 drivers/crypto/nx/nx-842-crypto.c   | 602 
 drivers/crypto/nx/nx-842-platform.c |  84 -
 drivers/crypto/nx/nx-842-powernv.c  |  29 +-
 drivers/crypto/nx/nx-842-pseries.c  | 126 
 drivers/crypto/nx/nx-842.c  | 554 +
 drivers/crypto/nx/nx-842.h  |  65 +++-
 8 files changed, 638 insertions(+), 847 deletions(-)
 delete mode 100644 drivers/crypto/nx/nx-842-crypto.c
 delete mode 100644 drivers/crypto/nx/nx-842-platform.c

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/8] crypto: nx - move kzalloc() out of spinlock

2015-07-22 Thread Dan Streetman
Move the kzalloc() calls in nx842_probe() and nx842_OF_upd() to the top
of the functions, before taking the devdata spinlock.

Since kzalloc() without GFP_ATOMIC can sleep, it can't be called while
holding a spinlock.  Move the calls to before taking the lock.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-pseries.c | 38 --
 1 file changed, 16 insertions(+), 22 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index b375877..74c53a1 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -724,6 +724,10 @@ static int nx842_OF_upd(struct property *new_prop)
int ret = 0;
unsigned long flags;
 
+   new_devdata = kzalloc(sizeof(*new_devdata), GFP_NOFS);
+   if (!new_devdata)
+   return -ENOMEM;
+
spin_lock_irqsave(devdata_mutex, flags);
old_devdata = rcu_dereference_check(devdata,
lockdep_is_held(devdata_mutex));
@@ -733,16 +737,10 @@ static int nx842_OF_upd(struct property *new_prop)
if (!old_devdata || !of_node) {
pr_err(%s: device is not available\n, __func__);
spin_unlock_irqrestore(devdata_mutex, flags);
+   kfree(new_devdata);
return -ENODEV;
}
 
-   new_devdata = kzalloc(sizeof(*new_devdata), GFP_NOFS);
-   if (!new_devdata) {
-   dev_err(old_devdata-dev, %s: Could not allocate memory for 
device data\n, __func__);
-   ret = -ENOMEM;
-   goto error_out;
-   }
-
memcpy(new_devdata, old_devdata, sizeof(*old_devdata));
new_devdata-counters = old_devdata-counters;
 
@@ -966,6 +964,17 @@ static int nx842_probe(struct vio_dev *viodev,
unsigned long flags;
int ret = 0;
 
+   new_devdata = kzalloc(sizeof(*new_devdata), GFP_NOFS);
+   if (!new_devdata)
+   return -ENOMEM;
+
+   new_devdata-counters = kzalloc(sizeof(*new_devdata-counters),
+   GFP_NOFS);
+   if (!new_devdata-counters) {
+   kfree(new_devdata);
+   return -ENOMEM;
+   }
+
spin_lock_irqsave(devdata_mutex, flags);
old_devdata = rcu_dereference_check(devdata,
lockdep_is_held(devdata_mutex));
@@ -978,21 +987,6 @@ static int nx842_probe(struct vio_dev *viodev,
 
dev_set_drvdata(viodev-dev, NULL);
 
-   new_devdata = kzalloc(sizeof(*new_devdata), GFP_NOFS);
-   if (!new_devdata) {
-   dev_err(viodev-dev, %s: Could not allocate memory for device 
data\n, __func__);
-   ret = -ENOMEM;
-   goto error_unlock;
-   }
-
-   new_devdata-counters = kzalloc(sizeof(*new_devdata-counters),
-   GFP_NOFS);
-   if (!new_devdata-counters) {
-   dev_err(viodev-dev, %s: Could not allocate memory for 
performance counters\n, __func__);
-   ret = -ENOMEM;
-   goto error_unlock;
-   }
-
new_devdata-vdev = viodev;
new_devdata-dev = viodev-dev;
nx842_OF_set_defaults(new_devdata);
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/8] crypto: nx - use common code for both NX decompress success cases

2015-07-22 Thread Dan Streetman
Replace the duplicated finishing code (set destination buffer length and
set return code to 0) in the case of decompressing a buffer with no header
with a goto to the success case of decompressing a buffer with a header.

This is a trivial change that allows both success cases to use common code,
and includes the pr_debug() msg in both cases as well.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-crypto.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
index 3288a70..51ca168 100644
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ b/drivers/crypto/nx/nx-842-crypto.c
@@ -520,10 +520,7 @@ static int nx842_crypto_decompress(struct crypto_tfm *tfm,
if (ret)
goto unlock;
 
-   *dlen = p.ototal;
-
-   ret = 0;
-   goto unlock;
+   goto success;
}
 
if (!hdr-groups) {
@@ -557,6 +554,7 @@ static int nx842_crypto_decompress(struct crypto_tfm *tfm,
goto unlock;
}
 
+success:
*dlen = p.ototal;
 
pr_debug(decompress total slen %x dlen %x\n, slen, *dlen);
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 7/8] crypto: nx - rename nx-842-crypto.c to nx-842.c

2015-07-22 Thread Dan Streetman
The last commit merged nx-842.c's code into nx-842-crypto.c.  It
did not rename nx-842-crypto.c to nx-842.c, in order to let the
patch more clearly show what was merged.  This just renames
nx-842-crypto.c to nx-842.c, with no changes to its code.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Makefile|   2 +-
 drivers/crypto/nx/nx-842-crypto.c | 600 --
 drivers/crypto/nx/nx-842.c| 600 ++
 3 files changed, 601 insertions(+), 601 deletions(-)
 delete mode 100644 drivers/crypto/nx/nx-842-crypto.c
 create mode 100644 drivers/crypto/nx/nx-842.c

diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index e29ee85..ffcc86c 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -13,7 +13,7 @@ nx-crypto-objs := nx.o \
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o nx-compress-platform.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o
-nx-compress-objs := nx-842-crypto.o
+nx-compress-objs := nx-842.o
 nx-compress-platform-objs := nx-842-platform.o
 nx-compress-pseries-objs := nx-842-pseries.o
 nx-compress-powernv-objs := nx-842-powernv.o
diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
deleted file mode 100644
index 4472e20..000
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ /dev/null
@@ -1,600 +0,0 @@
-/*
- * Cryptographic API for the NX-842 hardware compression.
- *
- * 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.
- *
- * Copyright (C) IBM Corporation, 2011-2015
- *
- * Designer of the Power data compression engine:
- *   Bulent Abali ab...@us.ibm.com
- *
- * Original Authors: Robert Jennings r...@linux.vnet.ibm.com
- *   Seth Jennings sjenn...@linux.vnet.ibm.com
- *
- * Rewrite: Dan Streetman ddstr...@ieee.org
- *
- * This is an interface to the NX-842 compression hardware in PowerPC
- * processors.  Most of the complexity of this drvier is due to the fact that
- * the NX-842 compression hardware requires the input and output data buffers
- * to be specifically aligned, to be a specific multiple in length, and within
- * specific minimum and maximum lengths.  Those restrictions, provided by the
- * nx-842 driver via nx842_constraints, mean this driver must use bounce
- * buffers and headers to correct misaligned in or out buffers, and to split
- * input buffers that are too large.
- *
- * This driver will fall back to software decompression if the hardware
- * decompression fails, so this driver's decompression should never fail as
- * long as the provided compressed buffer is valid.  Any compressed buffer
- * created by this driver will have a header (except ones where the input
- * perfectly matches the constraints); so users of this driver cannot simply
- * pass a compressed buffer created by this driver over to the 842 software
- * decompression library.  Instead, users must use this driver to decompress;
- * if the hardware fails or is unavailable, the compressed buffer will be
- * parsed and the header removed, and the raw 842 buffer(s) passed to the 842
- * software decompression library.
- *
- * This does not fall back to software compression, however, since the caller
- * of this function is specifically requesting hardware compression; if the
- * hardware compression fails, the caller can fall back to software
- * compression, and the raw 842 compressed buffer that the software compressor
- * creates can be passed to this driver for hardware decompression; any
- * buffer without our specific header magic is assumed to be a raw 842 buffer
- * and passed directly to the hardware.  Note that the software compression
- * library will produce a compressed buffer that is incompatible with the
- * hardware decompressor if the original input buffer length is not a multiple
- * of 8; if such a compressed buffer is passed to this driver for
- * decompression, the hardware will reject it and this driver will then pass
- * it over to the software library for decompression.
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
-
-#include linux/init.h
-#include linux/module.h
-#include linux/crypto.h
-#include linux/vmalloc.h
-#include linux/sw842.h
-#include linux/ratelimit.h
-#include linux/spinlock.h
-
-#include nx-842.h
-
-/* The first 5 bits of this magic are 0x1f, which is an invalid 842 5-bit
- * template (see lib/842/842.h), so this magic number will never appear

[PATCH 2/8] crypto: nx - remove pSeries NX 'status' field

2015-07-22 Thread Dan Streetman
Remove the 'status' field from the pSeries NX driver data.

The 'status' field isn't used by the driver at all; it simply checks the
devicetree status node at initialization, and returns success if 'okay'
and failure otherwise.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-pseries.c | 39 ++
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index fc59520..b375877 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -99,11 +99,6 @@ struct nx842_workmem {
 #define NX842_HW_PAGE_SIZE (4096)
 #define NX842_HW_PAGE_MASK (~(NX842_HW_PAGE_SIZE-1))
 
-enum nx842_status {
-   UNAVAILABLE,
-   AVAILABLE
-};
-
 struct ibm_nx842_counters {
atomic64_t comp_complete;
atomic64_t comp_failed;
@@ -121,7 +116,6 @@ static struct nx842_devdata {
unsigned int max_sg_len;
unsigned int max_sync_size;
unsigned int max_sync_sg;
-   enum nx842_status status;
 } __rcu *devdata;
 static DEFINE_SPINLOCK(devdata_mutex);
 
@@ -537,48 +531,36 @@ static int nx842_OF_set_defaults(struct nx842_devdata 
*devdata)
devdata-max_sync_size = 0;
devdata-max_sync_sg = 0;
devdata-max_sg_len = 0;
-   devdata-status = UNAVAILABLE;
return 0;
} else
return -ENOENT;
 }
 
 /**
- * nx842_OF_upd_status -- Update the device info from OF status prop
+ * nx842_OF_upd_status -- Check the device info from OF status prop
  *
  * The status property indicates if the accelerator is enabled.  If the
  * device is in the OF tree it indicates that the hardware is present.
  * The status field indicates if the device is enabled when the status
  * is 'okay'.  Otherwise the device driver will be disabled.
  *
- * @devdata - struct nx842_devdata to update
  * @prop - struct property point containing the maxsyncop for the update
  *
  * Returns:
  *  0 - Device is available
  *  -ENODEV - Device is not available
  */
-static int nx842_OF_upd_status(struct nx842_devdata *devdata,
-   struct property *prop) {
-   int ret = 0;
+static int nx842_OF_upd_status(struct property *prop)
+{
const char *status = (const char *)prop-value;
 
-   if (!strncmp(status, okay, (size_t)prop-length)) {
-   devdata-status = AVAILABLE;
-   } else {
-   /*
-* Caller will log that the device is disabled, so only
-* output if there is an unexpected status.
-*/
-   if (strncmp(status, disabled, (size_t)prop-length)) {
-   dev_info(devdata-dev, %s: status '%s' is not 
'okay'\n,
-   __func__, status);
-   }
-   devdata-status = UNAVAILABLE;
-   ret = -ENODEV;
-   }
+   if (!strncmp(status, okay, (size_t)prop-length))
+   return 0;
+   if (!strncmp(status, disabled, (size_t)prop-length))
+   return -ENODEV;
+   dev_info(devdata-dev, %s: unknown status '%s'\n, __func__, status);
 
-   return ret;
+   return -EINVAL;
 }
 
 /**
@@ -784,7 +766,7 @@ static int nx842_OF_upd(struct property *new_prop)
goto out;
 
/* Perform property updates */
-   ret = nx842_OF_upd_status(new_devdata, status);
+   ret = nx842_OF_upd_status(status);
if (ret)
goto error_out;
 
@@ -1100,7 +1082,6 @@ static int __init nx842_pseries_init(void)
pr_err(Could not allocate memory for device data\n);
return -ENOMEM;
}
-   new_devdata-status = UNAVAILABLE;
RCU_INIT_POINTER(devdata, new_devdata);
 
ret = vio_register_driver(nx842_vio_driver);
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 8/8] crypto: nx - make platform drivers directly register with crypto

2015-07-22 Thread Dan Streetman
Remove the common 'platform' registration module, and move the crypto
compression driver registration into each of the pSeries and PowerNV
platform NX 842 drivers.  Change the nx-842.c code into simple common
functions that each platform driver uses to perform constraints-based
buffer changes, i.e. realigning and/or resizing buffers to match the
driver's hardware requirements.

The common 'platform' module was my mistake to create - since each
platform driver will only load/operate when running on its own
platform (i.e. a pSeries platform or a PowerNV platform), they can
directly register with the crypto subsystem, using the same alg and
driver name.  This removes unneeded complexity.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Makefile  |   6 +--
 drivers/crypto/nx/nx-842-platform.c |  84 -
 drivers/crypto/nx/nx-842-powernv.c  |  29 --
 drivers/crypto/nx/nx-842-pseries.c  |  38 ++---
 drivers/crypto/nx/nx-842.c  | 105 +++-
 drivers/crypto/nx/nx-842.h  |  43 ---
 6 files changed, 114 insertions(+), 191 deletions(-)
 delete mode 100644 drivers/crypto/nx/nx-842-platform.c

diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index ffcc86c..b727821 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -10,10 +10,8 @@ nx-crypto-objs := nx.o \
  nx-sha256.o \
  nx-sha512.o
 
-obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o nx-compress-platform.o
-obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o
-obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o
+obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o 
nx-compress.o
+obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o 
nx-compress.o
 nx-compress-objs := nx-842.o
-nx-compress-platform-objs := nx-842-platform.o
 nx-compress-pseries-objs := nx-842-pseries.o
 nx-compress-powernv-objs := nx-842-powernv.o
diff --git a/drivers/crypto/nx/nx-842-platform.c 
b/drivers/crypto/nx/nx-842-platform.c
deleted file mode 100644
index 664f13d..000
--- a/drivers/crypto/nx/nx-842-platform.c
+++ /dev/null
@@ -1,84 +0,0 @@
-
-#include nx-842.h
-
-/* this is needed, separate from the main nx-842.c driver, because that main
- * driver loads the platform drivers during its init(), and it expects one
- * (or none) of the platform drivers to set this pointer to its driver.
- * That means this pointer can't be in the main nx-842 driver, because it
- * wouldn't be accessible until after the main driver loaded, which wouldn't
- * be possible as it's waiting for the platform driver to load.  So place it
- * here.
- */
-static struct nx842_driver *driver;
-static DEFINE_SPINLOCK(driver_lock);
-
-struct nx842_driver *nx842_platform_driver(void)
-{
-   return driver;
-}
-EXPORT_SYMBOL_GPL(nx842_platform_driver);
-
-bool nx842_platform_driver_set(struct nx842_driver *_driver)
-{
-   bool ret = false;
-
-   spin_lock(driver_lock);
-
-   if (!driver) {
-   driver = _driver;
-   ret = true;
-   } else
-   WARN(1, can't set platform driver, already set to %s\n,
-driver-name);
-
-   spin_unlock(driver_lock);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(nx842_platform_driver_set);
-
-/* only call this from the platform driver exit function */
-void nx842_platform_driver_unset(struct nx842_driver *_driver)
-{
-   spin_lock(driver_lock);
-
-   if (driver == _driver)
-   driver = NULL;
-   else if (driver)
-   WARN(1, can't unset platform driver %s, currently set to %s\n,
-_driver-name, driver-name);
-   else
-   WARN(1, can't unset platform driver, already unset\n);
-
-   spin_unlock(driver_lock);
-}
-EXPORT_SYMBOL_GPL(nx842_platform_driver_unset);
-
-bool nx842_platform_driver_get(void)
-{
-   bool ret = false;
-
-   spin_lock(driver_lock);
-
-   if (driver)
-   ret = try_module_get(driver-owner);
-
-   spin_unlock(driver_lock);
-
-   return ret;
-}
-EXPORT_SYMBOL_GPL(nx842_platform_driver_get);
-
-void nx842_platform_driver_put(void)
-{
-   spin_lock(driver_lock);
-
-   if (driver)
-   module_put(driver-owner);
-
-   spin_unlock(driver_lock);
-}
-EXPORT_SYMBOL_GPL(nx842_platform_driver_put);
-
-MODULE_LICENSE(GPL);
-MODULE_AUTHOR(Dan Streetman ddstr...@ieee.org);
-MODULE_DESCRIPTION(842 H/W Compression platform driver);
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 7e47456..684ce51 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -26,6 +26,8 @@
 MODULE_LICENSE(GPL);
 MODULE_AUTHOR(Dan Streetman ddstr...@ieee.org);
 MODULE_DESCRIPTION(842 H/W Compression driver for IBM PowerNV processors);
+MODULE_ALIAS_CRYPTO(842

[PATCH 4/8] crypto: nx - don't register pSeries driver if ENODEV

2015-07-22 Thread Dan Streetman
Don't register the pSeries driver when parsing the device tree returns
ENODEV.

The nx842_probe() function in the pSeries driver returns error instead
of registering as a crypto compression driver, when it receives an
error return value from the nx842_OF_upd() function that probes the
device tree nodes, except when ENODEV is returned.  However ENODEV
should not be a special case and the driver should not register when
there is no hw device, or the hw device is disabled.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-pseries.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index 74c53a1..4b7bd8f 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -999,11 +999,8 @@ static int nx842_probe(struct vio_dev *viodev,
of_reconfig_notifier_register(nx842_of_nb);
 
ret = nx842_OF_upd(NULL);
-   if (ret  ret != -ENODEV) {
-   dev_err(viodev-dev, could not parse device tree. %d\n, ret);
-   ret = -1;
+   if (ret)
goto error;
-   }
 
rcu_read_lock();
dev_set_drvdata(viodev-dev, rcu_dereference(devdata));
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 6/8] crypto: nx - merge nx-compress and nx-compress-crypto

2015-07-22 Thread Dan Streetman
Merge the nx-842.c code into nx-842-crypto.c.

This allows later patches to remove the 'platform' driver, and instead
allow each platform driver to directly register with the crypto
compression api.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Kconfig |  17 ++-
 drivers/crypto/nx/Makefile|   4 +-
 drivers/crypto/nx/nx-842-crypto.c |  70 +-
 drivers/crypto/nx/nx-842.c| 103 --
 drivers/crypto/nx/nx-842.h|  28 +++
 5 files changed, 60 insertions(+), 162 deletions(-)
 delete mode 100644 drivers/crypto/nx/nx-842.c

diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
index e421c96..ad7552a 100644
--- a/drivers/crypto/nx/Kconfig
+++ b/drivers/crypto/nx/Kconfig
@@ -14,11 +14,14 @@ config CRYPTO_DEV_NX_ENCRYPT
 config CRYPTO_DEV_NX_COMPRESS
tristate Compression acceleration support
default y
+   select CRYPTO_ALGAPI
+   select 842_DECOMPRESS
help
  Support for PowerPC Nest (NX) compression acceleration. This
  module supports acceleration for compressing memory with the 842
- algorithm.  One of the platform drivers must be selected also.
- If you choose 'M' here, this module will be called nx_compress.
+ algorithm using the cryptographic API.  One of the platform
+ drivers must be selected also.  If you choose 'M' here, this
+ module will be called nx_compress.
 
 if CRYPTO_DEV_NX_COMPRESS
 
@@ -42,14 +45,4 @@ config CRYPTO_DEV_NX_COMPRESS_POWERNV
  algorithm.  This supports NX hardware on the PowerNV platform.
  If you choose 'M' here, this module will be called 
nx_compress_powernv.
 
-config CRYPTO_DEV_NX_COMPRESS_CRYPTO
-   tristate Compression acceleration cryptographic interface
-   select CRYPTO_ALGAPI
-   select 842_DECOMPRESS
-   default y
-   help
- Support for PowerPC Nest (NX) accelerators using the cryptographic
- API.  If you choose 'M' here, this module will be called
- nx_compress_crypto.
-
 endif
diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index e1684f5..e29ee85 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -13,9 +13,7 @@ nx-crypto-objs := nx.o \
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o nx-compress-platform.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o
-obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_CRYPTO) += nx-compress-crypto.o
-nx-compress-objs := nx-842.o
+nx-compress-objs := nx-842-crypto.o
 nx-compress-platform-objs := nx-842-platform.o
 nx-compress-pseries-objs := nx-842-pseries.o
 nx-compress-powernv-objs := nx-842-powernv.o
-nx-compress-crypto-objs := nx-842-crypto.o
diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
index 51ca168..4472e20 100644
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ b/drivers/crypto/nx/nx-842-crypto.c
@@ -13,6 +13,9 @@
  *
  * Copyright (C) IBM Corporation, 2011-2015
  *
+ * Designer of the Power data compression engine:
+ *   Bulent Abali ab...@us.ibm.com
+ *
  * Original Authors: Robert Jennings r...@linux.vnet.ibm.com
  *   Seth Jennings sjenn...@linux.vnet.ibm.com
  *
@@ -162,24 +165,11 @@ static void nx842_crypto_exit(struct crypto_tfm *tfm)
free_page((unsigned long)ctx-dbounce);
 }
 
-static int read_constraints(struct nx842_constraints *c)
+static void check_constraints(struct nx842_constraints *c)
 {
-   int ret;
-
-   ret = nx842_constraints(c);
-   if (ret) {
-   pr_err_ratelimited(could not get nx842 constraints : %d\n,
-  ret);
-   return ret;
-   }
-
/* limit maximum, to always have enough bounce buffer to decompress */
-   if (c-maximum  BOUNCE_BUFFER_SIZE) {
+   if (c-maximum  BOUNCE_BUFFER_SIZE)
c-maximum = BOUNCE_BUFFER_SIZE;
-   pr_info_once(limiting nx842 maximum to %x\n, c-maximum);
-   }
-
-   return 0;
 }
 
 static int nx842_crypto_add_header(struct nx842_crypto_header *hdr, u8 *buf)
@@ -260,7 +250,9 @@ nospc:
timeout = ktime_add_ms(ktime_get(), COMP_BUSY_TIMEOUT);
do {
dlen = tmplen; /* reset dlen, if we're retrying */
-   ret = nx842_compress(src, slen, dst, dlen, ctx-wmem);
+   ret = nx842_platform_driver()-compress(src, slen,
+   dst, dlen,
+   ctx-wmem);
/* possibly we should reduce the slen here, instead of
 * retrying with the dbounce buffer?
 */
@@ -297,12 +289,14 @@ static int nx842_crypto_compress(struct crypto_tfm *tfm,
struct nx842_crypto_ctx *ctx = crypto_tfm_ctx(tfm);
struct

Re: [PATCH 5/6] [RFC] crypto/testmgr: add null test for 842 algorithm

2015-07-15 Thread Dan Streetman
On Mon, Jul 13, 2015 at 8:05 PM, Nishanth Aravamudan
n...@linux.vnet.ibm.com wrote:
 On 13.07.2015 [17:05:36 -0700], Nishanth Aravamudan wrote:
 On 04.07.2015 [15:24:53 +0800], Herbert Xu wrote:
  On Thu, Jul 02, 2015 at 03:41:19PM -0700, Nishanth Aravamudan wrote:
   Currently, when the nx-842-pseries driver loads, the following message
   is emitted:
  
   alg: No test for 842 (842-nx)
  
   It seems like the simplest way to fix this message (other than adding a
   proper test) is to just insert the null test into the list in the
   testmgr.
  
   Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
 
  Please add some real test vectors instead.

 Apologies, hit send too fast. I'll work with Dan on this when he gets
 back from vacation.

Back from vacation! :-)

I originally didn't add any test vector for NX 842 because the main
driver was loading before the platform (pseries/powernv) drivers,
and the test couldn't run as the platform driver hadn't loaded yet.
That's now fixed so we should be able to add a real test for NX 842
now, I can work on that patch.


 -Nish

 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 6/6] nx-842-platform: if NX842 platform drivers are not modules, don't try to load them

2015-07-15 Thread Dan Streetman
On Mon, Jul 6, 2015 at 1:07 PM, Nishanth Aravamudan
n...@linux.vnet.ibm.com wrote:
 On 06.07.2015 [16:13:07 +0800], Herbert Xu wrote:
 On Thu, Jul 02, 2015 at 03:42:26PM -0700, Nishanth Aravamudan wrote:
  Based off the CONFIG_SPU_FS_MODULE code, only attempt to load platform
  modules if the nx-842 pseries/powernv drivers are built as modules.
 
  Otherwise, if CONFIG_DEV_NX_COMPRESS=y,
  CONFIG_DEV_NX_COMPRESS_PSERIES=y, CONFIG_DEV_NX_POWERNV=y, the following
  message is emitted at boot:
 
  nx_compress: no nx842 driver found.
 
  even though the drivers successfully loads.
 
  This is because in the =y case, the module_init() calls get converted to
  initcalls and the nx842_init() runs before the platform driver
  nx842_pseries_init() or nx842_powernv_init() functions, which are what
  normally set the static platform driver.
 
  Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
  Cc: Dan Streetman ddstr...@us.ibm.com
  Cc: Herbert Xu herb...@gondor.apana.org.au
  Cc: David S. Miller da...@davemloft.net
  Cc: linux-crypto@vger.kernel.org
  Cc: linuxppc-...@lists.ozlabs.org

 Ugh, I think this whole thing is redundant.  The whole point of
 the crypto API is to allow the coexistence of multiple underlying
 implementations.

 Sure, that makes sense -- sorry, I was picking this up while Dan was on
 vacation. Will provide a better v2.

 Please get rid of nx-842-platform.c completely and move the crypto
 registration into the individual platform drivers.  That is, powernv
 and pseries should each register their own crypto driver.  They can of
 course share a common set of crypto code which can live in its own
 module.  There should be no need for mucking with module reference
 counts at all.

 Will do, thanks!

Yep, I originally did it this way because I didn't realize crypto
could register different drivers with the same alg name (but different
driver names).  I have some patches already to start doing this but
they weren't ready enough to send before I left for vacation; I'll
finish them up and send them.


 -Nish

 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] MAINTAINERS: clarify drivers/crypto/nx/ file ownership

2015-06-18 Thread Dan Streetman
Update the IBM Power in-Nest Crypto Acceleration and
IBM Power 842 compression accelerator sections to specify the correct
files.

The IBM Power in-Nest Crypto Acceleration was originally the only
NX driver, and so its section listed all drivers/crypto/nx/ files,
but now there is also the 842 driver which has its own section.  This
lists explicitly what files are owned by the Crypto driver and which
files are owned by the 842 compression driver.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
Leonidas, I assume you'll update the owner line at some point too,
since you're the new NX Crypto owner.

 MAINTAINERS | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fb06e1e..d6fb983 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4856,11 +4856,19 @@ M:  Marcelo Henrique Cerri 
mhce...@linux.vnet.ibm.com
 M: Fionnuala Gunter f...@linux.vnet.ibm.com
 L: linux-crypto@vger.kernel.org
 S: Supported
-F: drivers/crypto/nx/
+F: drivers/crypto/nx/Makefile
+F: drivers/crypto/nx/Kconfig
+F: drivers/crypto/nx/nx-aes*
+F: drivers/crypto/nx/nx-sha*
+F: drivers/crypto/nx/nx.*
+F: drivers/crypto/nx/nx_csbcpb.h
+F: drivers/crypto/nx/nx_debugfs.h
 
 IBM Power 842 compression accelerator
 M: Dan Streetman ddstr...@us.ibm.com
 S: Supported
+F: drivers/crypto/nx/Makefile
+F: drivers/crypto/nx/Kconfig
 F: drivers/crypto/nx/nx-842*
 F: include/linux/sw842.h
 F: crypto/842.c
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] crypto: nx - add LE support to pSeries platform driver

2015-06-18 Thread Dan Streetman
Add support to the nx-842-pseries.c driver for running in little endian
mode.

The pSeries platform NX 842 driver currently only works as big endian.
This adds cpu_to_be*() and be*_to_cpu() in the appropriate places to
work in LE mode also.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Kconfig  |  2 +-
 drivers/crypto/nx/nx-842-pseries.c | 83 +++---
 drivers/crypto/nx/nx-842.h |  3 +-
 3 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
index b1addf6..e421c96 100644
--- a/drivers/crypto/nx/Kconfig
+++ b/drivers/crypto/nx/Kconfig
@@ -24,7 +24,7 @@ if CRYPTO_DEV_NX_COMPRESS
 
 config CRYPTO_DEV_NX_COMPRESS_PSERIES
tristate Compression acceleration support on pSeries platform
-   depends on PPC_PSERIES  IBMVIO  !CPU_LITTLE_ENDIAN
+   depends on PPC_PSERIES  IBMVIO
default y
help
  Support for PowerPC Nest (NX) compression acceleration. This
diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index da52d8e..3040a60 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -166,8 +166,8 @@ static unsigned long nx842_get_desired_dma(struct vio_dev 
*viodev)
 }
 
 struct nx842_slentry {
-   unsigned long ptr; /* Real address (use __pa()) */
-   unsigned long len;
+   __be64 ptr; /* Real address (use __pa()) */
+   __be64 len;
 };
 
 /* pHyp scatterlist entry */
@@ -186,30 +186,21 @@ static inline unsigned long nx842_get_scatterlist_size(
 static int nx842_build_scatterlist(unsigned long buf, int len,
struct nx842_scatterlist *sl)
 {
-   unsigned long nextpage;
+   unsigned long entrylen;
struct nx842_slentry *entry;
 
sl-entry_nr = 0;
 
entry = sl-entries;
while (len) {
-   entry-ptr = nx842_get_pa((void *)buf);
-   nextpage = ALIGN(buf + 1, NX842_HW_PAGE_SIZE);
-   if (nextpage  buf + len) {
-   /* we aren't at the end yet */
-   if (IS_ALIGNED(buf, NX842_HW_PAGE_SIZE))
-   /* we are in the middle (or beginning) */
-   entry-len = NX842_HW_PAGE_SIZE;
-   else
-   /* we are at the beginning */
-   entry-len = nextpage - buf;
-   } else {
-   /* at the end */
-   entry-len = len;
-   }
-
-   len -= entry-len;
-   buf += entry-len;
+   entry-ptr = cpu_to_be64(nx842_get_pa((void *)buf));
+   entrylen = min_t(int, len,
+LEN_ON_SIZE(buf, NX842_HW_PAGE_SIZE));
+   entry-len = cpu_to_be64(entrylen);
+
+   len -= entrylen;
+   buf += entrylen;
+
sl-entry_nr++;
entry++;
}
@@ -230,8 +221,8 @@ static int nx842_validate_result(struct device *dev,
csb-completion_code,
csb-completion_extension);
dev_dbg(dev, processed_bytes:%d address:0x%016lx\n,
-   csb-processed_byte_count,
-   (unsigned long)csb-address);
+   be32_to_cpu(csb-processed_byte_count),
+   (unsigned long)be64_to_cpu(csb-address));
return -EIO;
}
 
@@ -338,7 +329,6 @@ static int nx842_pseries_compress(const unsigned char *in, 
unsigned int inlen,
csbcpb = workmem-csbcpb;
memset(csbcpb, 0, sizeof(*csbcpb));
op.csbcpb = nx842_get_pa(csbcpb);
-   op.out = nx842_get_pa(slout.entries);
 
if ((inbuf  NX842_HW_PAGE_MASK) ==
((inbuf + inlen - 1)  NX842_HW_PAGE_MASK)) {
@@ -364,6 +354,10 @@ static int nx842_pseries_compress(const unsigned char *in, 
unsigned int inlen,
op.outlen = -nx842_get_scatterlist_size(slout);
}
 
+   dev_dbg(dev, %s: op.in %lx op.inlen %ld op.out %lx op.outlen %ld\n,
+   __func__, (unsigned long)op.in, (long)op.inlen,
+   (unsigned long)op.out, (long)op.outlen);
+
/* Send request to pHyp */
ret = vio_h_cop_sync(local_devdata-vdev, op);
 
@@ -380,7 +374,7 @@ static int nx842_pseries_compress(const unsigned char *in, 
unsigned int inlen,
if (ret)
goto unlock;
 
-   *outlen = csbcpb-csb.processed_byte_count;
+   *outlen = be32_to_cpu(csbcpb-csb.processed_byte_count);
dev_dbg(dev, %s: processed_bytes=%d\n, __func__, *outlen);
 
 unlock:
@@ -493,6 +487,10 @@ static int nx842_pseries_decompress(const unsigned char 
*in, unsigned int inlen,
op.outlen = -nx842_get_scatterlist_size(slout);
}
 
+   dev_dbg(dev, %s: op.in

Re: [cryptodev:master 73/233] drivers/crypto/nx/nx-842-pseries.c:45:14: error: 'DDE_BUFFER_LAST_MULT' undeclared here (not in a function)

2015-06-13 Thread Dan Streetman
On Sat, Jun 13, 2015 at 8:58 AM, kbuild test robot
fengguang...@intel.com wrote:
 tree:   
 git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
 head:   81781e681551ed3f56c9202e9adc7ef941cba654
 commit: 959e6659b6f74ec1fa4d391a3b88d63dc0189f36 [73/233] crypto: nx - add 
 nx842 constraints
 config: powerpc-allmodconfig (attached as .config)
 reproduce:
   wget 
 https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
  -O ~/bin/make.cross
   chmod +x ~/bin/make.cross
   git checkout 959e6659b6f74ec1fa4d391a3b88d63dc0189f36
   # save the attached .config to linux build tree
   make.cross ARCH=powerpc

 Note: the cryptodev/master HEAD 81781e681551ed3f56c9202e9adc7ef941cba654 
 builds fine.
   It only hurts bisectibility.

 All error/warnings (new ones prefixed by ):

 drivers/crypto/nx/nx-842-pseries.c:45:14: error: 'DDE_BUFFER_LAST_MULT' 
 undeclared here (not in a function)
  .multiple = DDE_BUFFER_LAST_MULT,
  ^

sorry, that is added by the next patch in the patch series, so there
should be no problem except this specific patch will have to be
skipped during bisecting.



 vim +/DDE_BUFFER_LAST_MULT +45 drivers/crypto/nx/nx-842-pseries.c

 39
 40  /* IO buffer must be 128 byte aligned */
 41  #define IO_BUFFER_ALIGN 128
 42
 43  static struct nx842_constraints nx842_pseries_constraints = {
 44  .alignment =IO_BUFFER_ALIGN,
45  .multiple = DDE_BUFFER_LAST_MULT,
 46  .minimum =  IO_BUFFER_ALIGN,
 47  .maximum =  PAGE_SIZE, /* dynamic, max_sync_size */
 48  };

 ---
 0-DAY kernel test infrastructureOpen Source Technology Center
 http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] crypto: move include/linux/nx842.h into drivers/crypto/nx/nx-842.h

2015-06-12 Thread Dan Streetman
Move the contents of the include/linux/nx842.h header file into the
drivers/crypto/nx/nx-842.h header file.  Remove the nx842.h header
file and its entry in the MAINTAINERS file.

The include/linux/nx842.h header originally was there because the
crypto/842.c driver needed it to communicate with the nx-842 hw
driver.  However, that crypto compression driver was moved into
the drivers/crypto/nx/ directory, and now can directly include the
nx-842.h header.  Nothing else needs the public include/linux/nx842.h
header file, as all use of the nx-842 hardware driver will be through
the 842-nx crypto compression driver, since the direct nx-842 api is
very limited in the buffer alignments and sizes that it will accept,
and the crypto compression interface handles those limitations and
allows any alignment and size buffers.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 MAINTAINERS   |  1 -
 drivers/crypto/nx/nx-842-crypto.c |  3 ++-
 drivers/crypto/nx/nx-842.h| 21 -
 include/linux/nx842.h | 24 
 4 files changed, 22 insertions(+), 27 deletions(-)
 delete mode 100644 include/linux/nx842.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 912c9d9..fb06e1e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4862,7 +4862,6 @@ IBM Power 842 compression accelerator
 M: Dan Streetman ddstr...@us.ibm.com
 S: Supported
 F: drivers/crypto/nx/nx-842*
-F: include/linux/nx842.h
 F: include/linux/sw842.h
 F: crypto/842.c
 F: lib/842/
diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
index 2ffa103..95066f3 100644
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ b/drivers/crypto/nx/nx-842-crypto.c
@@ -58,10 +58,11 @@
 #include linux/module.h
 #include linux/crypto.h
 #include linux/vmalloc.h
-#include linux/nx842.h
 #include linux/sw842.h
 #include linux/ratelimit.h
 
+#include nx-842.h
+
 /* The first 5 bits of this magic are 0x1f, which is an invalid 842 5-bit
  * template (see lib/842/842.h), so this magic number will never appear at
  * the start of a raw 842 compressed buffer.  That is important, as any buffer
diff --git a/drivers/crypto/nx/nx-842.h b/drivers/crypto/nx/nx-842.h
index 1730f4da..4dbac11 100644
--- a/drivers/crypto/nx/nx-842.h
+++ b/drivers/crypto/nx/nx-842.h
@@ -4,7 +4,6 @@
 
 #include linux/kernel.h
 #include linux/module.h
-#include linux/nx842.h
 #include linux/sw842.h
 #include linux/of.h
 #include linux/slab.h
@@ -12,6 +11,12 @@
 #include linux/mm.h
 #include linux/ratelimit.h
 
+#define __NX842_PSERIES_MEM_COMPRESS   (10240)
+#define __NX842_POWERNV_MEM_COMPRESS   (1024)
+
+#define NX842_MEM_COMPRESS (max_t(unsigned int,\
+   __NX842_PSERIES_MEM_COMPRESS, __NX842_POWERNV_MEM_COMPRESS))
+
 /* Restrictions on Data Descriptor List (DDL) and Entry (DDE) buffers
  *
  * From NX P8 workbook, sec 4.9.1 842 details
@@ -104,6 +109,13 @@ static inline unsigned long nx842_get_pa(void *addr)
 #define GET_FIELD(v, m)(((v)  (m))  MASK_LSH(m))
 #define SET_FIELD(v, m, val)   (((v)  ~(m)) | (((val)  MASK_LSH(m))  (m)))
 
+struct nx842_constraints {
+   int alignment;
+   int multiple;
+   int minimum;
+   int maximum;
+};
+
 struct nx842_driver {
char *name;
struct module *owner;
@@ -124,4 +136,11 @@ void nx842_platform_driver_unset(struct nx842_driver 
*driver);
 bool nx842_platform_driver_get(void);
 void nx842_platform_driver_put(void);
 
+int nx842_constraints(struct nx842_constraints *constraints);
+
+int nx842_compress(const unsigned char *in, unsigned int in_len,
+  unsigned char *out, unsigned int *out_len, void *wrkmem);
+int nx842_decompress(const unsigned char *in, unsigned int in_len,
+unsigned char *out, unsigned int *out_len, void *wrkmem);
+
 #endif /* __NX_842_H__ */
diff --git a/include/linux/nx842.h b/include/linux/nx842.h
deleted file mode 100644
index 4ddf68d..000
--- a/include/linux/nx842.h
+++ /dev/null
@@ -1,24 +0,0 @@
-#ifndef __NX842_H__
-#define __NX842_H__
-
-#define __NX842_PSERIES_MEM_COMPRESS   (10240)
-#define __NX842_POWERNV_MEM_COMPRESS   (1024)
-
-#define NX842_MEM_COMPRESS (max_t(unsigned int,\
-   __NX842_PSERIES_MEM_COMPRESS, __NX842_POWERNV_MEM_COMPRESS))
-
-struct nx842_constraints {
-   int alignment;
-   int multiple;
-   int minimum;
-   int maximum;
-};
-
-int nx842_constraints(struct nx842_constraints *constraints);
-
-int nx842_compress(const unsigned char *in, unsigned int in_len,
-  unsigned char *out, unsigned int *out_len, void *wrkmem);
-int nx842_decompress(const unsigned char *in, unsigned int in_len,
-unsigned char *out, unsigned int *out_len, void *wrkmem);
-
-#endif
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http

[PATCH 0/2] remove nx842.h from include/linux

2015-06-12 Thread Dan Streetman
Now that the crypto/842.c driver does only software 842 comp/decomp,
and the hardware crypto compressor for 842-nx is located in
drivers/crypto/nx with the NX 842 hw driver, there's no reason for
the nx842.h header to be located in include/linux/ anymore; nobody
should use the NX 842 hw driver directly, everyone should use the
crypto compression API.

The first patch moves the contents of include/linux/nx842.h into the
existing drivers/crypto/nx/nx-842.h header file.  The second patch
replaces the use of the NX842_MEM_COMPRESS define, since the 842-nx
crypto compression driver can directly get the required working
memory size from the NX 842 hw driver.

This cleans up include/linux/ by 1 file, and it saves some memory
by reducing the 842-nx working memory size down to exactly what the
NX 842 platform driver requires.

Dan Streetman (2):
  crypto: move include/linux/nx842.h into drivers/crypto/nx/nx-842.h
  crypto: replace NX842_MEM_COMPRESS with function

 MAINTAINERS|  1 -
 drivers/crypto/nx/nx-842-crypto.c  |  5 +++--
 drivers/crypto/nx/nx-842-powernv.c | 11 +++
 drivers/crypto/nx/nx-842-pseries.c |  7 +++
 drivers/crypto/nx/nx-842.c | 11 +++
 drivers/crypto/nx/nx-842.h | 18 +-
 include/linux/nx842.h  | 24 
 7 files changed, 41 insertions(+), 36 deletions(-)
 delete mode 100644 include/linux/nx842.h

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] crypto: replace NX842_MEM_COMPRESS with function

2015-06-12 Thread Dan Streetman
Replace the NX842_MEM_COMPRESS define with a function that returns the
specific platform driver's required working memory size.

The common nx-842.c driver refuses to load if there is no platform
driver present, so instead of defining an approximate working memory
size that's the maximum approximate size of both platform driver's
size requirements, the platform driver can directly provide its
specific, i.e. sizeof(struct nx842_workmem), size requirements which
the 842-nx crypto compression driver will use.

This saves memory by both reducing the required size of each driver
to the specific sizeof() amount, as well as using the specific loaded
platform driver's required amount, instead of the maximum of both.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-crypto.c  |  2 +-
 drivers/crypto/nx/nx-842-powernv.c | 11 +++
 drivers/crypto/nx/nx-842-pseries.c |  7 +++
 drivers/crypto/nx/nx-842.c | 11 +++
 drivers/crypto/nx/nx-842.h |  9 +++--
 5 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
index 95066f3..d53a1dc 100644
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ b/drivers/crypto/nx/nx-842-crypto.c
@@ -136,7 +136,7 @@ static int nx842_crypto_init(struct crypto_tfm *tfm)
 {
struct nx842_crypto_ctx *ctx = crypto_tfm_ctx(tfm);
 
-   ctx-wmem = kmalloc(NX842_MEM_COMPRESS, GFP_KERNEL);
+   ctx-wmem = kmalloc(nx842_workmem_size(), GFP_KERNEL);
ctx-sbounce = (u8 *)__get_free_pages(GFP_KERNEL, BOUNCE_BUFFER_ORDER);
ctx-dbounce = (u8 *)__get_free_pages(GFP_KERNEL, BOUNCE_BUFFER_ORDER);
if (!ctx-wmem || !ctx-sbounce || !ctx-dbounce) {
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index c388dba..33b3b0a 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -367,7 +367,8 @@ static int wait_for_csb(struct nx842_workmem *wmem,
  * @inlen: input buffer size
  * @out: output buffer pointer
  * @outlenp: output buffer size pointer
- * @workmem: working memory buffer pointer, must be at least NX842_MEM_COMPRESS
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
  * @fc: function code, see CCW Function Codes in nx-842.h
  *
  * Returns:
@@ -477,7 +478,8 @@ static int nx842_powernv_function(const unsigned char *in, 
unsigned int inlen,
  * @inlen: input buffer size
  * @out: output buffer pointer
  * @outlenp: output buffer size pointer
- * @workmem: working memory buffer pointer, must be at least NX842_MEM_COMPRESS
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
  *
  * Returns: see @nx842_powernv_function()
  */
@@ -504,7 +506,8 @@ static int nx842_powernv_compress(const unsigned char *in, 
unsigned int inlen,
  * @inlen: input buffer size
  * @out: output buffer pointer
  * @outlenp: output buffer size pointer
- * @workmem: working memory buffer pointer, must be at least NX842_MEM_COMPRESS
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
  *
  * Returns: see @nx842_powernv_function()
  */
@@ -572,6 +575,7 @@ static struct nx842_constraints nx842_powernv_constraints = 
{
 static struct nx842_driver nx842_powernv_driver = {
.name = KBUILD_MODNAME,
.owner =THIS_MODULE,
+   .workmem_size = sizeof(struct nx842_workmem),
.constraints =  nx842_powernv_constraints,
.compress = nx842_powernv_compress,
.decompress =   nx842_powernv_decompress,
@@ -582,7 +586,6 @@ static __init int nx842_powernv_init(void)
struct device_node *dn;
 
/* verify workmem size/align restrictions */
-   BUILD_BUG_ON(sizeof(struct nx842_workmem)  NX842_MEM_COMPRESS);
BUILD_BUG_ON(WORKMEM_ALIGN % CRB_ALIGN);
BUILD_BUG_ON(CRB_ALIGN % DDE_ALIGN);
BUILD_BUG_ON(CRB_SIZE % DDE_ALIGN);
diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index 41bc551..da52d8e 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -284,7 +284,7 @@ static int nx842_validate_result(struct device *dev,
  * @out: Pointer to output buffer
  * @outlen: Length of output buffer
  * @wrkmem: ptr to buffer for working memory, size determined by
- *  NX842_MEM_COMPRESS
+ *  nx842_pseries_driver.workmem_size
  *
  * Returns:
  *   0 Success, output of length @outlen stored in the buffer at @out
@@ -411,7 +411,7 @@ unlock:
  * @out: Pointer to output buffer
  * @outlen: Length of output buffer
  * @wrkmem: ptr to buffer for working memory, size determined by
- *  NX842_MEM_COMPRESS
+ *  nx842_pseries_driver.workmem_size
  *
  * Returns:
  *   0 Success, output of length @outlen stored in the buffer at @out
@@ -963,6 +963,7

Re: [PATCH] crypto: prevent nx 842 load if no hw driver

2015-06-03 Thread Dan Streetman
On Wed, Jun 3, 2015 at 1:08 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
 On Thu, May 28, 2015 at 04:21:31PM -0400, Dan Streetman wrote:
 Change the nx-842 common driver to wait for loading of both platform
 drivers, and fail loading if the platform driver pointer is not set.
 Add an independent platform driver pointer, that the platform drivers
 set if they find they are able to load (i.e. if they find their platform
 devicetree node(s)).

 The problem is currently, the main nx-842 driver will stay loaded even
 if there is no platform driver and thus no possible way it can do any
 compression or decompression.  This allows the crypto 842-nx driver
 to load even if it won't actually work.  For crypto compression users
 (e.g. zswap) that expect an available crypto compression driver to
 actually work, this is bad.  This patch fixes that, so the 842-nx crypto
 compression driver won't load if it doesn't have the driver and hardware
 available to perform the compression.

 Signed-off-by: Dan Streetman ddstr...@ieee.org

 Applied.  Though I had to do the Makefile bit by hand because
 it contains references to nx-compress-test which doesn't exist
 in my tree.

Oops sorry, I forgot to remove that old test module patch from my tree.

Thanks.


 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] crypto: prevent nx 842 load if no hw driver

2015-05-28 Thread Dan Streetman
Change the nx-842 common driver to wait for loading of both platform
drivers, and fail loading if the platform driver pointer is not set.
Add an independent platform driver pointer, that the platform drivers
set if they find they are able to load (i.e. if they find their platform
devicetree node(s)).

The problem is currently, the main nx-842 driver will stay loaded even
if there is no platform driver and thus no possible way it can do any
compression or decompression.  This allows the crypto 842-nx driver
to load even if it won't actually work.  For crypto compression users
(e.g. zswap) that expect an available crypto compression driver to
actually work, this is bad.  This patch fixes that, so the 842-nx crypto
compression driver won't load if it doesn't have the driver and hardware
available to perform the compression.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Makefile  |   3 +-
 drivers/crypto/nx/nx-842-platform.c |  84 +++
 drivers/crypto/nx/nx-842-powernv.c  |  17 +++--
 drivers/crypto/nx/nx-842-pseries.c  |  33 ++---
 drivers/crypto/nx/nx-842.c  | 130 ++--
 drivers/crypto/nx/nx-842.h  |  16 ++---
 6 files changed, 148 insertions(+), 135 deletions(-)
 create mode 100644 drivers/crypto/nx/nx-842-platform.c

diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index 8e3512d..9d56205 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -10,12 +10,13 @@ nx-crypto-objs := nx.o \
  nx-sha256.o \
  nx-sha512.o
 
-obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o
+obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o nx-compress-platform.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_CRYPTO) += nx-compress-crypto.o
 obj-$(CONFIG_CRYPTO_DEV_NX_SELFTEST) += nx-compress-test.o
 nx-compress-objs := nx-842.o
+nx-compress-platform-objs := nx-842-platform.o
 nx-compress-pseries-objs := nx-842-pseries.o
 nx-compress-powernv-objs := nx-842-powernv.o
 nx-compress-crypto-objs := nx-842-crypto.o
diff --git a/drivers/crypto/nx/nx-842-platform.c 
b/drivers/crypto/nx/nx-842-platform.c
new file mode 100644
index 000..664f13d
--- /dev/null
+++ b/drivers/crypto/nx/nx-842-platform.c
@@ -0,0 +1,84 @@
+
+#include nx-842.h
+
+/* this is needed, separate from the main nx-842.c driver, because that main
+ * driver loads the platform drivers during its init(), and it expects one
+ * (or none) of the platform drivers to set this pointer to its driver.
+ * That means this pointer can't be in the main nx-842 driver, because it
+ * wouldn't be accessible until after the main driver loaded, which wouldn't
+ * be possible as it's waiting for the platform driver to load.  So place it
+ * here.
+ */
+static struct nx842_driver *driver;
+static DEFINE_SPINLOCK(driver_lock);
+
+struct nx842_driver *nx842_platform_driver(void)
+{
+   return driver;
+}
+EXPORT_SYMBOL_GPL(nx842_platform_driver);
+
+bool nx842_platform_driver_set(struct nx842_driver *_driver)
+{
+   bool ret = false;
+
+   spin_lock(driver_lock);
+
+   if (!driver) {
+   driver = _driver;
+   ret = true;
+   } else
+   WARN(1, can't set platform driver, already set to %s\n,
+driver-name);
+
+   spin_unlock(driver_lock);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(nx842_platform_driver_set);
+
+/* only call this from the platform driver exit function */
+void nx842_platform_driver_unset(struct nx842_driver *_driver)
+{
+   spin_lock(driver_lock);
+
+   if (driver == _driver)
+   driver = NULL;
+   else if (driver)
+   WARN(1, can't unset platform driver %s, currently set to %s\n,
+_driver-name, driver-name);
+   else
+   WARN(1, can't unset platform driver, already unset\n);
+
+   spin_unlock(driver_lock);
+}
+EXPORT_SYMBOL_GPL(nx842_platform_driver_unset);
+
+bool nx842_platform_driver_get(void)
+{
+   bool ret = false;
+
+   spin_lock(driver_lock);
+
+   if (driver)
+   ret = try_module_get(driver-owner);
+
+   spin_unlock(driver_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(nx842_platform_driver_get);
+
+void nx842_platform_driver_put(void)
+{
+   spin_lock(driver_lock);
+
+   if (driver)
+   module_put(driver-owner);
+
+   spin_unlock(driver_lock);
+}
+EXPORT_SYMBOL_GPL(nx842_platform_driver_put);
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Dan Streetman ddstr...@ieee.org);
+MODULE_DESCRIPTION(842 H/W Compression platform driver);
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 6a9fb8b..c388dba 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -23,7 +23,6 @@
 #include asm

Re: [PATCH] crypto: move Kconfig 842 to end of list, default to N

2015-05-22 Thread Dan Streetman
On Fri, May 22, 2015 at 8:34 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
 On Fri, May 22, 2015 at 08:08:28PM -0400, Dan Streetman wrote:
 Move the 842 compression alg choice to last in the list, so it's
 not in the middle of LZO/LZ4/LZ4HC.  Change its default to N, as it
 is a very slow alg, which generally should only be used with
 compression hardware that's capable of doing it much faster.

 Signed-off-by: Dan Streetman ddstr...@ieee.org

 The default default is n so this is redundant.

ah ok. never mind then! :-)


 Cheers,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] crypto: move Kconfig 842 to end of list, default to N

2015-05-22 Thread Dan Streetman
Move the 842 compression alg choice to last in the list, so it's
not in the middle of LZO/LZ4/LZ4HC.  Change its default to N, as it
is a very slow alg, which generally should only be used with
compression hardware that's capable of doing it much faster.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 crypto/Kconfig | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 24df47b..62ced6f 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1419,14 +1419,6 @@ config CRYPTO_LZO
help
  This is the LZO algorithm.
 
-config CRYPTO_842
-   tristate 842 compression algorithm
-   select CRYPTO_ALGAPI
-   select 842_COMPRESS
-   select 842_DECOMPRESS
-   help
- This is the 842 algorithm.
-
 config CRYPTO_LZ4
tristate LZ4 compression algorithm
select CRYPTO_ALGAPI
@@ -1443,6 +1435,15 @@ config CRYPTO_LZ4HC
help
  This is the LZ4 high compression mode algorithm.
 
+config CRYPTO_842
+   tristate 842 compression algorithm
+   default n
+   select CRYPTO_ALGAPI
+   select 842_COMPRESS
+   select 842_DECOMPRESS
+   help
+ This is the 842 algorithm.
+
 comment Random Number Generation
 
 config CRYPTO_ANSI_CPRNG
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 09/11] crypto: remove LZO fallback from crypto 842

2015-04-08 Thread Dan Streetman
On Wed, Apr 8, 2015 at 10:38 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
 On Wed, Apr 08, 2015 at 10:28:23AM -0400, Dan Streetman wrote:

 So, the sw implementation is only for decompression; there's no sw
 compression implementation in these patches.

 As a general rule we don't add any hardware implementation unless
 there is a software implementation.  The reason is that every new
 algorithm creates an API (potentially a user-space API if the
 algorithm can be exported via algif).  But sometimes things slip
 through.

 So I'm not going to immediately remove 842 but it would be nice
 if we had a reference implementation so that if ever there were
 another hardware 842 implmentation added then at least we have
 something that we can judge against.

Ok I'll see if I can include a sw compression implementation.


 The hw 842 driver is currently at drivers/crypto/nx, and the
 crypto/842 driver just calls the hw driver (after correctly
 aligning/sizing the provided buffers to what the hw driver expects),
 and falls back to the sw decompression if the hw decompression fails
 (there is no compression fallback, a failure is reported to the
 caller).

 Is that setup ok?  If users had to directly call the hw driver,
 instead of using the generic crypto_comp interface, it would
 complicate things, e.g. in zswap it only expects to call
 crypto_comp_compress()/decompress(), not call the 842 hw driver
 directly.

 I think the only thing that needs to happen for now is moving
 crypto/842.c over to drivers/crypto/nx (perhaps merge it into
 nx-842.c) so that it's obvious that this is not a generic
 implementation.

ah ok, so you mean it can still be a crypto_comp interface, just move
its location and/or merge it into nx-842.c?


 Cheers,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 09/11] crypto: remove LZO fallback from crypto 842

2015-04-08 Thread Dan Streetman
On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
 On Tue, Apr 07, 2015 at 01:34:28PM -0400, Dan Streetman wrote:
 Update the crypto 842 driver to no longer fallback to LZO if the 842
 hardware is unavailable.  Simplify the crpypto 842 driver to remove all
 headers indicating 842/lzo.

 The crypto 842 driver should do 842-format compression and decompression
 only.  It should not fallback to LZO compression/decompression.  The
 user of the crypto 842 driver can fallback to another format if desired.

 Signed-off-by: Dan Streetman ddstr...@ieee.org

 Thanks for the series.  I don't know how I missed it when it was
 merged originally but crypto/842.c needs to be moved over to
 drivers/crypto.  Your software implementation should take its
 places as the reference implementation.

So, the sw implementation is only for decompression; there's no sw
compression implementation in these patches.

The hw 842 driver is currently at drivers/crypto/nx, and the
crypto/842 driver just calls the hw driver (after correctly
aligning/sizing the provided buffers to what the hw driver expects),
and falls back to the sw decompression if the hw decompression fails
(there is no compression fallback, a failure is reported to the
caller).

Is that setup ok?  If users had to directly call the hw driver,
instead of using the generic crypto_comp interface, it would
complicate things, e.g. in zswap it only expects to call
crypto_comp_compress()/decompress(), not call the 842 hw driver
directly.



 Cheers,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 11/11] crypto: add crypto compression sefltest

2015-04-08 Thread Dan Streetman
On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
 On Tue, Apr 07, 2015 at 01:34:30PM -0400, Dan Streetman wrote:
 Add configurable module to perform self-tests on any crypto compression
 driver.

 This allows testing any crypto compression driver with any input buffer,
 at varying alignments and lengths.  It calculates the average bytes per
 second compression and decompression rates.  Any errors reported by the
 compressor during compression or decompression will end the test and
 be logged.

 Signed-off-by: Dan Streetman ddstr...@ieee.org

 Please use the existing infrastructure in testmgr/tcrypt.

I think I looked at that and it didn't seem like it would be able to
include all the user controls, but I'll look again.  In any case this
test doesn't have to be included in this 842 patch set, so I'll drop
it from the next version and re-send it by itself if/when I can update
it to use testmgr.


 Thanks,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 11/11] crypto: add crypto compression sefltest

2015-04-07 Thread Dan Streetman
Add configurable module to perform self-tests on any crypto compression
driver.

This allows testing any crypto compression driver with any input buffer,
at varying alignments and lengths.  It calculates the average bytes per
second compression and decompression rates.  Any errors reported by the
compressor during compression or decompression will end the test and
be logged.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 crypto/Kconfig |   9 +
 crypto/Makefile|   1 +
 crypto/comp_selftest.c | 928 +
 3 files changed, 938 insertions(+)
 create mode 100644 crypto/comp_selftest.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index a7148ff..e56ecf2 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -189,6 +189,15 @@ config CRYPTO_TEST
help
  Quick  dirty crypto test module.
 
+config CRYPTO_COMP_SELFTEST
+   tristate Compression Self-Testing module
+   help
+ Configurable Compression Self-Testing using debugfs interface.
+ This allows you to compress and decompress buffers of variable
+ offsets, lengths, and data, using different compressors.  Also
+ the average bytes per second rate for compression/decompression
+ can be calculated.
+
 config CRYPTO_ABLK_HELPER
tristate
select CRYPTO_CRYPTD
diff --git a/crypto/Makefile b/crypto/Makefile
index ba19465..0bb1ac2 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_CRYPTO_RNG2) += krng.o
 obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o
 obj-$(CONFIG_CRYPTO_DRBG) += drbg.o
 obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
+obj-$(CONFIG_CRYPTO_COMP_SELFTEST) += comp_selftest.o
 obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
 obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
 obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
diff --git a/crypto/comp_selftest.c b/crypto/comp_selftest.c
new file mode 100644
index 000..691a8ea
--- /dev/null
+++ b/crypto/comp_selftest.c
@@ -0,0 +1,928 @@
+/*
+ * Self-test for compression
+ *
+ * Copyright (C) 2015 Dan Streetman, 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.
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/kthread.h
+#include linux/debugfs.h
+#include linux/uaccess.h
+#include linux/crypto.h
+#include linux/rwsem.h
+#include linux/ratelimit.h
+
+#define MODULE_NAME comp_selftest
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Dan Streetman ddstr...@ieee.org);
+MODULE_DESCRIPTION(Crypto Compression Self-Test);
+
+static unsigned int test_kthreads_max = 64;
+module_param_named(threads_max, test_kthreads_max, uint, 0444);
+
+static unsigned int test_buffer_order = 2;
+module_param_named(buffer_order, test_buffer_order, uint, 0444);
+
+#define TEST_KTHREADS_DEFAULT  (4)
+
+#define TEST_REPEAT_DEFAULT(1)
+
+#define TEST_BPS_WINDOW_DEFAULT(1)
+
+#define TEST_BUFFER_SIZE   (PAGE_SIZE  test_buffer_order)
+
+#define TEST_CHECK_INTERVAL(msecs_to_jiffies(500))
+
+#define OFFSET_START_DEFAULT   (0)
+#define OFFSET_END_DEFAULT OFFSET_START_DEFAULT
+#define OFFSET_INTERVAL_DEFAULT(1)
+#define LENGTH_START_DEFAULT   (PAGE_SIZE)
+#define LENGTH_END_DEFAULT LENGTH_START_DEFAULT
+#define LENGTH_INTERVAL_DEFAULT(1)
+
+struct test_range {
+   u32 start, interval, end;
+};
+
+struct test_param {
+   u32 running;
+   u32 repeat;
+   u32 kthreads;
+   u32 bps_window; /* in seconds */
+   struct test_range offset[3];
+   struct test_range length[3];
+};
+
+struct test_kthread_param {
+   bool running;
+   struct task_struct *kthread;
+   struct crypto_comp *tfm;
+   u8 *buffer[3];
+   u32 offset[3];
+   u32 length[3];
+   atomic64_t bps[2];
+};
+
+static struct test_kthread_param *test_kthread_params;
+
+static struct task_struct *test_kthread;
+static int test_return;
+static u8 *test_buffer;
+
+static atomic64_t test_max_bps[2];
+
+#define TEST_TFM_NAME_MAX  (32)
+static char test_tfm[TEST_TFM_NAME_MAX];
+
+static struct test_param test_params, test_new_params;
+
+static DECLARE_RWSEM(test_lock);
+
+
+static unsigned long total_bps(int i)
+{
+   unsigned long total = 0;
+   int j;
+
+   for (j = 0; j  test_kthreads_max; j++)
+   total += atomic64_read(test_kthread_params[j].bps[i]);
+
+   return total;
+}
+
+static void update_max_bps(int i)
+{
+   uint64_t prev, t;
+
+   t = total_bps(i);
+   prev = atomic64_read(test_max_bps[i]);
+   while (t  prev) {
+   uint64_t

[PATCH 06/11] drivers/crypto/nx: add nx842 constraints

2015-04-07 Thread Dan Streetman
Add constraints for the NX-842 driver.  The constraints are used to
indicate what the current NX-842 platform driver is capable of.  The
constraints tell the NX-842 user what alignment, min and max length, and
length multiple each provided buffers should conform to.  These are
required because the 842 hardware requires buffers to meet specific
constraints that vary based on platform - for example, the pSeries
max length is much lower than the PowerNV max length.

These constraints are used by a later patch that improves the crypto 842
driver.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-pseries.c | 10 ++
 drivers/crypto/nx/nx-842.c | 38 ++
 drivers/crypto/nx/nx-842.h |  2 ++
 include/linux/nx842.h  |  9 +
 4 files changed, 59 insertions(+)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index 728a148..baa2e52 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -40,6 +40,13 @@ MODULE_DESCRIPTION(842 H/W Compression driver for IBM Power 
processors);
 /* IO buffer must be 128 byte aligned */
 #define IO_BUFFER_ALIGN 128
 
+static struct nx842_constraints nx842_pseries_constraints = {
+   .alignment =IO_BUFFER_ALIGN,
+   .multiple = DDE_BUFFER_LAST_MULT,
+   .minimum =  IO_BUFFER_ALIGN,
+   .maximum =  PAGE_SIZE, /* dynamic, max_sync_size */
+};
+
 struct nx842_header {
int blocks_nr; /* number of compressed blocks */
int offset; /* offset of the first block (from beginning of header) */
@@ -840,6 +847,8 @@ static int nx842_OF_upd_maxsyncop(struct nx842_devdata 
*devdata,
goto out;
}
 
+   nx842_pseries_constraints.maximum = devdata-max_sync_size;
+
devdata-max_sync_sg = (unsigned int)min(maxsynccop-comp_sg_limit,
maxsynccop-decomp_sg_limit);
if (devdata-max_sync_sg  1) {
@@ -1113,6 +1122,7 @@ static struct attribute_group nx842_attribute_group = {
 
 static struct nx842_driver nx842_pseries_driver = {
.owner =THIS_MODULE,
+   .constraints =  nx842_pseries_constraints,
.compress = nx842_pseries_compress,
.decompress =   nx842_pseries_decompress,
 };
diff --git a/drivers/crypto/nx/nx-842.c b/drivers/crypto/nx/nx-842.c
index 815d277..279a38e 100644
--- a/drivers/crypto/nx/nx-842.c
+++ b/drivers/crypto/nx/nx-842.c
@@ -86,6 +86,44 @@ static void put_driver(struct nx842_driver *driver)
module_put(driver-owner);
 }
 
+/**
+ * nx842_constraints
+ *
+ * This provides the driver's constraints.  Different nx842 implementations
+ * may have varying requirements.  The constraints are:
+ *   @alignment:   All buffers should be aligned to this
+ *   @multiple:All buffer lengths should be a multiple of this
+ *   @minimum: Buffer lengths must not be less than this amount
+ *   @maximum: Buffer lengths must not be more than this amount
+ *
+ * The constraints apply to all buffers and lengths, both input and output,
+ * for both compression and decompression, except for the minimum which
+ * only applies to compression input and decompression output; the
+ * compressed data can be less than the minimum constraint.  It can be
+ * assumed that compressed data will always adhere to the multiple
+ * constraint.
+ *
+ * The driver may succeed even if these constraints are violated;
+ * however the driver can return failure or suffer reduced performance
+ * if any constraint is not met.
+ */
+int nx842_constraints(struct nx842_constraints *c)
+{
+   struct nx842_driver *driver = get_driver();
+   int ret = 0;
+
+   if (!driver)
+   return -ENODEV;
+
+   BUG_ON(!c);
+   memcpy(c, driver-constraints, sizeof(*c));
+
+   put_driver(driver);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(nx842_constraints);
+
 int nx842_compress(const unsigned char *in, unsigned int in_len,
unsigned char *out, unsigned int *out_len,
void *wrkmem)
diff --git a/drivers/crypto/nx/nx-842.h b/drivers/crypto/nx/nx-842.h
index 2a5d4e1..c6ceb0f 100644
--- a/drivers/crypto/nx/nx-842.h
+++ b/drivers/crypto/nx/nx-842.h
@@ -12,6 +12,8 @@
 struct nx842_driver {
struct module *owner;
 
+   struct nx842_constraints *constraints;
+
int (*compress)(const unsigned char *in, unsigned int in_len,
unsigned char *out, unsigned int *out_len,
void *wrkmem);
diff --git a/include/linux/nx842.h b/include/linux/nx842.h
index 778e3ab..883b474 100644
--- a/include/linux/nx842.h
+++ b/include/linux/nx842.h
@@ -5,6 +5,15 @@
 
 #define NX842_MEM_COMPRESS __NX842_PSERIES_MEM_COMPRESS
 
+struct nx842_constraints {
+   int alignment;
+   int multiple;
+   int minimum;
+   int maximum;
+};
+
+int nx842_constraints

[PATCH 00/11] add 842 hw compression for PowerNV platform

2015-04-07 Thread Dan Streetman
IBM PowerPC processors starting at version P7+ contain a NX coprocessor that
provides various hw-accelerated functions, one of which is memory compression
to the IBM 842 compression format.  This NX-842 coprocessor is already
supported on the pSeries platform, by the nx-842.c driver and the crypto
compression interface at crypto/842.c.  This patch set adds support for NX-842
on the PowerNV (Non-Virtualized) platform.

The existing pSeries platform NX-842 driver could not be re-used for the
PowerNV platform driver, as there are fundamentally different interfaces;
on pSeries the system hypervisor (pHyp) provides the interface and manages
communication with the coprocessor, while on PowerNV the kernel talks directly
to the coprocessor using the ICSWX instruction.  The data structures used to
describe each compression or decompression request to the coprocessor are
also different between pHyp's interface and direct communication with ICSWX.
So, different drivers for pSeries and PowerNV are required.  Adding the new
PowerNV driver but keeping the interface to the drivers the same required
adding a new common frontend interface, to which only one of the platform
drivers will connect (based on what platform the kernel is currently running
on), and moving some functionality out of the existing pSeries driver into a
more common location.  Also, the crypto/842.c interface to the NX-842 hw
driver is modified to be able to handle any alignment or length input or
output buffer; currently with the pSeries driver only page-size and
page-aligned (uncompressed) buffers are possible.

The result is a crypto 842 interface that allows using any input and output
buffers (i.e. any alignment and length) to communicate with the NX-842
hardware on either the pSeries or PowerNV platforms, as well as a generic
842 software decompressor that the crypto 842 interface falls back to if the
NX-842 hardware fails and/or returns error during decompression.

Finally, this also adds a generic crypto compression selftest module, that
can verify correct compression/decompression cycles using variable alignment
and length buffers, multiple threads, and can calculate the throughput.

Dan Streetman (11):
  powerpc: export of_get_ibm_chip_id function
  powerpc: Add ICSWX instruction
  crypto: add software 842 decompression
  drivers/crypto/nx: move nx-842.c to nx-842-pseries.c
  drivers/crypto/nx: add NX-842 platform frontend driver
  drivers/crypto/nx: add nx842 constraints
  drivers/crypto/nx: add PowerNV platform NX-842 driver
  drivers/crypto/nx: simplify pSeries nx842 driver
  crypto: remove LZO fallback from crypto 842
  crypto: rewrite crypto 842 to use nx842 constraints
  crypto: add crypto compression sefltest

 MAINTAINERS   |5 +-
 arch/powerpc/include/asm/icswx.h  |  184 
 arch/powerpc/include/asm/ppc-opcode.h |   13 +
 arch/powerpc/kernel/prom.c|1 +
 crypto/842.c  |  495 --
 crypto/Kconfig|   13 +-
 crypto/Makefile   |1 +
 crypto/comp_selftest.c|  928 +++
 drivers/crypto/Kconfig|6 +-
 drivers/crypto/nx/Kconfig |   43 +-
 drivers/crypto/nx/Makefile|4 +
 drivers/crypto/nx/nx-842-powernv.c|  623 +
 drivers/crypto/nx/nx-842-pseries.c| 1126 +++
 drivers/crypto/nx/nx-842.c| 1623 +++--
 drivers/crypto/nx/nx-842.h|  131 +++
 include/linux/nx842.h |   17 +-
 include/linux/sw842.h |7 +
 lib/842/842_decompress.c  |  413 +
 lib/842/Makefile  |1 +
 lib/Kconfig   |3 +
 lib/Makefile  |1 +
 21 files changed, 4001 insertions(+), 1637 deletions(-)
 create mode 100644 arch/powerpc/include/asm/icswx.h
 create mode 100644 crypto/comp_selftest.c
 create mode 100644 drivers/crypto/nx/nx-842-powernv.c
 create mode 100644 drivers/crypto/nx/nx-842-pseries.c
 create mode 100644 drivers/crypto/nx/nx-842.h
 create mode 100644 include/linux/sw842.h
 create mode 100644 lib/842/842_decompress.c
 create mode 100644 lib/842/Makefile

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 03/11] crypto: add software 842 decompression

2015-04-07 Thread Dan Streetman
Add an 842-format software decompression function.  Update the MAINTAINERS
842 section to include the new files.

This decompression function can decompress any standard-format 842
compressed data.  The 842 compressed format is explained in the header
comments.  This general-use decompression function is required by later
patches that update the crypto 842 driver to fall back to software 842
decompression if the NX-842 hardware fails and/or returns an error.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 MAINTAINERS  |   2 +
 include/linux/sw842.h|   7 +
 lib/842/842_decompress.c | 413 +++
 lib/842/Makefile |   1 +
 lib/Kconfig  |   3 +
 lib/Makefile |   1 +
 6 files changed, 427 insertions(+)
 create mode 100644 include/linux/sw842.h
 create mode 100644 lib/842/842_decompress.c
 create mode 100644 lib/842/Makefile

diff --git a/MAINTAINERS b/MAINTAINERS
index efbcb50..3dc973a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4836,6 +4836,8 @@ M:Dan Streetman ddstr...@us.ibm.com
 S: Supported
 F: drivers/crypto/nx/nx-842.c
 F: include/linux/nx842.h
+F: include/linux/sw842.h
+F: lib/842/
 
 IBM Power Linux RAID adapter
 M: Brian King brk...@us.ibm.com
diff --git a/include/linux/sw842.h b/include/linux/sw842.h
new file mode 100644
index 000..aa8d86e
--- /dev/null
+++ b/include/linux/sw842.h
@@ -0,0 +1,7 @@
+#ifndef __SW842_H__
+#define __SW842_H__
+
+int sw842_decompress(const unsigned char *src, int srclen,
+   unsigned char *dst, int *destlen);
+
+#endif
diff --git a/lib/842/842_decompress.c b/lib/842/842_decompress.c
new file mode 100644
index 000..9fc0ffc
--- /dev/null
+++ b/lib/842/842_decompress.c
@@ -0,0 +1,413 @@
+/*
+ * 842 Decompressor
+ *
+ * Copyright (C) 2015 Dan Streetman, 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.
+ *
+ * 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.
+ *
+ * The 842 compressed format is made up of multiple blocks, each of
+ * which have the format:
+ *
+ * template[arg1][arg2][arg3][arg4]
+ *
+ * where there are between 0 and 4 template args, depending on the specific
+ * template operation.  For normal operations, each arg is either a specific
+ * number of data bytes to add to the output stream, or an index pointing
+ * to a previously-written number of data bytes to copy to the output stream.
+ *
+ * The template code is a 5-bit value.  This code indicates what to
+ * do with the following data.  Template codes from 0 to 0x19 should
+ * use the template table, the static ops table in the code below.
+ * For each template (table row), there are between 1 and 4 actions;
+ * each action corresponds to an arg following the template code
+ * bits.  Each action is either a data type action, or a index
+ * type action, and each action results in 2, 4, or 8 bytes being
+ * written to the output stream.  Each template (i.e. all actions in
+ * the table row) will add up to 8 bytes being written to the output
+ * stream.  Any row with less than 4 actions is padded with noop
+ * actions, indicated by N0 (for which there is no corresponding arg
+ * in the compressed data stream).
+ *
+ * Data actions, indicated in the table by D2, D4, and D8, mean that
+ * the corresponding arg is 2, 4, or 8 bytes, respectively, in the
+ * compressed data stream should be copied directly to the output stream.
+ *
+ * Index actions, indicated in the table by I2, I4, and I8, mean
+ * the corresponding arg is an index parameter that points to,
+ * respectively, a 2, 4, or 8 byte value already in the output
+ * stream, that should be copied to the end of the output stream.
+ * Essentially, the index points to a position in a ring buffer that
+ * contains the last N bytes of output stream data.  The number of bits
+ * for each index's arg are: 8 bits for I2, 9 bits for I4, and 8 bits for
+ * I8.  Since each index points to a 2, 4, or 8 byte section, this means
+ * that I2 can reference 512 bytes ((2^8 bits = 256) * 2 bytes), I4 can
+ * reference 2048 bytes ((2^9 = 512) * 4 bytes), and I8 can reference
+ * 2048 bytes ((2^8 = 256) * 8 bytes).  Think of it as a dedicated ring
+ * buffer for each of I2, I4, and I8 that are updated for each byte
+ * written to the output stream.  In this implementation, the output stream
+ * is directly used for each index; there is no additional memory required.
+ * Note that the index is into a ring buffer, not a sliding window;
+ * for example, if there have been 260 bytes written to the output stream

[PATCH 07/11] drivers/crypto/nx: add PowerNV platform NX-842 driver

2015-04-07 Thread Dan Streetman
Add driver for NX-842 hardware on the PowerNV platform.

This allows the use of the 842 compression hardware coprocessor on
the PowerNV platform.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Kconfig  |  10 +
 drivers/crypto/nx/Makefile |   2 +
 drivers/crypto/nx/nx-842-powernv.c | 623 +
 drivers/crypto/nx/nx-842-pseries.c |   9 -
 drivers/crypto/nx/nx-842.c |   4 +-
 drivers/crypto/nx/nx-842.h |  97 ++
 include/linux/nx842.h  |   6 +-
 7 files changed, 739 insertions(+), 12 deletions(-)
 create mode 100644 drivers/crypto/nx/nx-842-powernv.c

diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
index e4396fc..4bf400a 100644
--- a/drivers/crypto/nx/Kconfig
+++ b/drivers/crypto/nx/Kconfig
@@ -38,4 +38,14 @@ config CRYPTO_DEV_NX_PSERIES_COMPRESS
  algorithm.  This supports NX hardware on the pSeries platform.
  If you choose 'M' here, this module will be called 
nx_compress_pseries.
 
+config CRYPTO_DEV_NX_POWERNV_COMPRESS
+   tristate Compression acceleration support on PowerNV platform
+   depends on PPC_POWERNV
+   default y
+   help
+ Support for Power in-Nest compression acceleration. This
+ module supports acceleration for compressing memory with the 842
+ algorithm.  This supports NX hardware on the PowerNV platform.
+ If you choose 'M' here, this module will be called 
nx_compress_powernv.
+
 endif
diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index bc7b7ea..82221f2 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -12,5 +12,7 @@ nx-crypto-objs := nx.o \
 
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o
 obj-$(CONFIG_CRYPTO_DEV_NX_PSERIES_COMPRESS) += nx-compress-pseries.o
+obj-$(CONFIG_CRYPTO_DEV_NX_POWERNV_COMPRESS) += nx-compress-powernv.o
 nx-compress-objs := nx-842.o
 nx-compress-pseries-objs := nx-842-pseries.o
+nx-compress-powernv-objs := nx-842-powernv.o
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
new file mode 100644
index 000..f1624a8
--- /dev/null
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -0,0 +1,623 @@
+/*
+ * Driver for IBM PowerNV 842 compression accelerator
+ *
+ * Copyright (C) 2015 Dan Streetman, 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.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
+
+#include nx-842.h
+
+#include linux/timer.h
+
+#include asm/prom.h
+#include asm/icswx.h
+
+#define MODULE_NAME NX842_POWERNV_MODULE_NAME
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Dan Streetman ddstr...@ieee.org);
+MODULE_DESCRIPTION(842 H/W Compression driver for IBM PowerNV processors);
+
+#define WORKMEM_ALIGN  (CRB_ALIGN)
+#define CSB_WAIT_MAX   (5000) /* ms */
+
+struct nx842_workmem {
+   /* Below fields must be properly aligned */
+   struct coprocessor_request_block crb; /* CRB_ALIGN align */
+   struct data_descriptor_entry ddl_in[DDL_LEN_MAX]; /* DDE_ALIGN align */
+   struct data_descriptor_entry ddl_out[DDL_LEN_MAX]; /* DDE_ALIGN align */
+   /* Above fields must be properly aligned */
+
+   ktime_t start;
+
+   char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
+} __packed __aligned(WORKMEM_ALIGN);
+
+struct nx842_coproc {
+   unsigned int chip_id;
+   unsigned int ct;
+   unsigned int ci;
+   struct list_head list;
+};
+
+/* no cpu hotplug on powernv, so this list never changes after init */
+static LIST_HEAD(nx842_coprocs);
+static unsigned int nx842_ct;
+
+/**
+ * setup_indirect_dde - Setup an indirect DDE
+ *
+ * The DDE is setup with the the DDE count, byte count, and address of
+ * first direct DDE in the list.
+ */
+static void setup_indirect_dde(struct data_descriptor_entry *dde,
+   struct data_descriptor_entry *ddl,
+   unsigned int dde_count, unsigned int byte_count)
+{
+   dde-flags = 0;
+   dde-count = dde_count;
+   dde-index = 0;
+   dde-length = cpu_to_be32(byte_count);
+   dde-address = cpu_to_be64(nx842_get_pa(ddl));
+}
+
+/**
+ * setup_direct_dde - Setup single DDE from buffer
+ *
+ * The DDE is setup with the buffer and length.  The buffer must be properly
+ * aligned.  The used length is returned.
+ * Returns:
+ *   NSuccessfully set up DDE with N bytes
+ */
+static unsigned int setup_direct_dde(struct data_descriptor_entry *dde,
+   unsigned long pa, unsigned int len

[PATCH 09/11] crypto: remove LZO fallback from crypto 842

2015-04-07 Thread Dan Streetman
Update the crypto 842 driver to no longer fallback to LZO if the 842
hardware is unavailable.  Simplify the crpypto 842 driver to remove all
headers indicating 842/lzo.

The crypto 842 driver should do 842-format compression and decompression
only.  It should not fallback to LZO compression/decompression.  The
user of the crypto 842 driver can fallback to another format if desired.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 crypto/842.c   | 139 -
 crypto/Kconfig |   4 +-
 2 files changed, 29 insertions(+), 114 deletions(-)

diff --git a/crypto/842.c b/crypto/842.c
index d21cedb..d81c6c7 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -26,128 +26,46 @@
 #include linux/crypto.h
 #include linux/vmalloc.h
 #include linux/nx842.h
-#include linux/lzo.h
+#include linux/sw842.h
 #include linux/timer.h
 
-static int nx842_uselzo;
-
-struct nx842_ctx {
-   void *nx842_wmem; /* working memory for 842/lzo */
-};
-
-enum nx842_crypto_type {
-   NX842_CRYPTO_TYPE_842,
-   NX842_CRYPTO_TYPE_LZO
+struct crypto842_ctx {
+   void *wmem; /* working memory for 842 */
 };
 
-#define NX842_SENTINEL 0xdeadbeef
-
-struct nx842_crypto_header {
-   unsigned int sentinel; /* debug */
-   enum nx842_crypto_type type;
-};
-
-static int nx842_init(struct crypto_tfm *tfm)
+static int crypto842_init(struct crypto_tfm *tfm)
 {
-   struct nx842_ctx *ctx = crypto_tfm_ctx(tfm);
-   int wmemsize;
+   struct crypto842_ctx *ctx = crypto_tfm_ctx(tfm);
 
-   wmemsize = max_t(int, NX842_MEM_COMPRESS, LZO1X_MEM_COMPRESS);
-   ctx-nx842_wmem = kmalloc(wmemsize, GFP_NOFS);
-   if (!ctx-nx842_wmem)
+   ctx-wmem = kmalloc(NX842_MEM_COMPRESS, GFP_NOFS);
+   if (!ctx-wmem)
return -ENOMEM;
 
return 0;
 }
 
-static void nx842_exit(struct crypto_tfm *tfm)
+static void crypto842_exit(struct crypto_tfm *tfm)
 {
-   struct nx842_ctx *ctx = crypto_tfm_ctx(tfm);
+   struct crypto842_ctx *ctx = crypto_tfm_ctx(tfm);
 
-   kfree(ctx-nx842_wmem);
+   kfree(ctx-wmem);
 }
 
-static void nx842_reset_uselzo(unsigned long data)
-{
-   nx842_uselzo = 0;
-}
-
-static DEFINE_TIMER(failover_timer, nx842_reset_uselzo, 0, 0);
-
-static int nx842_crypto_compress(struct crypto_tfm *tfm, const u8 *src,
+static int crypto842_compress(struct crypto_tfm *tfm, const u8 *src,
unsigned int slen, u8 *dst, unsigned int *dlen)
 {
-   struct nx842_ctx *ctx = crypto_tfm_ctx(tfm);
-   struct nx842_crypto_header *hdr;
-   unsigned int tmp_len = *dlen;
-   size_t lzodlen; /* needed for lzo */
-   int err;
-
-   *dlen = 0;
-   hdr = (struct nx842_crypto_header *)dst;
-   hdr-sentinel = NX842_SENTINEL; /* debug */
-   dst += sizeof(struct nx842_crypto_header);
-   tmp_len -= sizeof(struct nx842_crypto_header);
-   lzodlen = tmp_len;
-
-   if (likely(!nx842_uselzo)) {
-   err = nx842_compress(src, slen, dst, tmp_len, ctx-nx842_wmem);
-
-   if (likely(!err)) {
-   hdr-type = NX842_CRYPTO_TYPE_842;
-   *dlen = tmp_len + sizeof(struct nx842_crypto_header);
-   return 0;
-   }
-
-   /* hardware failed */
-   nx842_uselzo = 1;
-
-   /* set timer to check for hardware again in 1 second */
-   mod_timer(failover_timer, jiffies + msecs_to_jiffies(1000));
-   }
-
-   /* no hardware, use lzo */
-   err = lzo1x_1_compress(src, slen, dst, lzodlen, ctx-nx842_wmem);
-   if (err != LZO_E_OK)
-   return -EINVAL;
-
-   hdr-type = NX842_CRYPTO_TYPE_LZO;
-   *dlen = lzodlen + sizeof(struct nx842_crypto_header);
-   return 0;
+   struct crypto842_ctx *ctx = crypto_tfm_ctx(tfm);
+
+   return nx842_compress(src, slen, dst, dlen, ctx-wmem);
 }
 
-static int nx842_crypto_decompress(struct crypto_tfm *tfm, const u8 *src,
+static int crypto842_decompress(struct crypto_tfm *tfm, const u8 *src,
  unsigned int slen, u8 *dst, unsigned int *dlen)
 {
-   struct nx842_ctx *ctx = crypto_tfm_ctx(tfm);
-   struct nx842_crypto_header *hdr;
-   unsigned int tmp_len = *dlen;
-   size_t lzodlen; /* needed for lzo */
-   int err;
-
-   *dlen = 0;
-   hdr = (struct nx842_crypto_header *)src;
-
-   if (unlikely(hdr-sentinel != NX842_SENTINEL))
-   return -EINVAL;
-
-   src += sizeof(struct nx842_crypto_header);
-   slen -= sizeof(struct nx842_crypto_header);
-
-   if (likely(hdr-type == NX842_CRYPTO_TYPE_842)) {
-   err = nx842_decompress(src, slen, dst, tmp_len,
-   ctx-nx842_wmem);
-   if (err)
-   return -EINVAL;
-   *dlen = tmp_len;
-   } else if (hdr-type == NX842_CRYPTO_TYPE_LZO) {
-   lzodlen = tmp_len;
-   err

[PATCH 10/11] crypto: rewrite crypto 842 to use nx842 constraints

2015-04-07 Thread Dan Streetman
Major rewrite of the crypto 842 driver to use the constraints from the
NX-842 hardware driver, and split and/or shift input or output buffers to
fit the required alignment/length constraints.  Add a header to the compressed
buffers.  Update the MAINTAINERS 842 section with the crypto 842 filename.
Fallback to software 842 decompression if the NX-842 hardware fails.

Now that the NX-842 hardware driver provides information about its constraints,
this updates the main crypto 842 driver to adjust each incoming buffer to those
hw constraints.  This allows using the 842 compression hardware with any
alignment or length buffers; previously with only the pSeries NX-842 driver
all (uncompressed) buffers needed to be page-sized and page-aligned.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 MAINTAINERS  |   1 +
 crypto/842.c | 414 ---
 2 files changed, 399 insertions(+), 16 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5a8d46d..850540d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4837,6 +4837,7 @@ S:Supported
 F: drivers/crypto/nx/nx-842*
 F: include/linux/nx842.h
 F: include/linux/sw842.h
+F: crypto/842.c
 F: lib/842/
 
 IBM Power Linux RAID adapter
diff --git a/crypto/842.c b/crypto/842.c
index d81c6c7..7f35c49 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -11,14 +11,22 @@
  * 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, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ * Copyright (C) IBM Corporation, 2011-2015
  *
- * Copyright (C) IBM Corporation, 2011
+ * Original Authors: Robert Jennings r...@linux.vnet.ibm.com
+ *   Seth Jennings sjenn...@linux.vnet.ibm.com
  *
- * Authors: Robert Jennings r...@linux.vnet.ibm.com
- *  Seth Jennings sjenn...@linux.vnet.ibm.com
+ * Rewrite: Dan Streetman ddstr...@ieee.org
+ *
+ * This is an interface to the NX-842 compression hardware in PowerPC
+ * processors (see drivers/crypto/nx/nx-842.c for details).  Most (all?)
+ * of the complexity of this drvier is due to the fact that the NX-842
+ * compression hardware requires the input and output data buffers to be
+ * specifically aligned, to be a specific multiple in length, and within
+ * specific minimum and maximum lengths.  Those restrictions, provided by
+ * the nx-842 driver via is nx842_constraints, mean this driver must use
+ * bounce buffers and headers to correct misaligned in or out buffers,
+ * and to split input buffers that are too large.
  */
 
 #include linux/init.h
@@ -27,10 +35,59 @@
 #include linux/vmalloc.h
 #include linux/nx842.h
 #include linux/sw842.h
-#include linux/timer.h
+#include linux/ratelimit.h
+
+/* The first 5 bits of this magic are 0x1f, which is an invalid 842 5-bit
+ * template (see lib/842/842_decompress.c), so this magic number
+ * will never appear at the start of a raw 842 compressed buffer.
+ * That can be useful in the future, if buffer alignment and length is
+ * correct, to not require the use of any header, which will save some
+ * space in the resulting compressed buffer; then in decompress, if the
+ * input buffer does not contain this header magic, it's assumed to be
+ * a raw compressed buffer and should be passed directly to the NX-842
+ * hardware driver.
+ */
+#define CRYPTO_842_MAGIC   (0xf842)
+#define CRYPTO_842_GROUP_MAX   (0x19)  /* max 0-based index, real max is +1 */
+#define CRYPTO_842_HEADER_SIZE(h)  \
+   (sizeof(*(h)) + sizeof((h)-group) * (h)-groups)
+#define CRYPTO_842_HEADER_MAX_SIZE \
+   (sizeof(struct crypto842_header) +  \
+sizeof(struct crypto842_header_group) * CRYPTO_842_GROUP_MAX)
+
+/* try longer on comp because we can fallback to sw decomp if hw is busy */
+#define COMP_BUSY_TIMEOUT  (250) /* ms */
+#define DECOMP_BUSY_TIMEOUT(50) /* ms */
+
+struct crypto842_header_group {
+   u16 padding;/* unused bytes at start of group */
+   u32 length; /* length of group, not including padding */
+} __packed;
+
+struct crypto842_header {
+   u16 magic;  /* CRYPTO_842_MAGIC */
+   u16 ignore; /* decompressed end bytes to ignore */
+   u8 groups;  /* 0-based; add 1 for total */
+   struct crypto842_header_group group[1];
+} __packed;
+
+struct crypto842_param {
+   u8 *in;
+   long iremain;
+   u8 *out;
+   long oremain;
+   long ototal;
+};
 
 struct crypto842_ctx {
-   void *wmem; /* working memory for 842 */
+   void *wmem; /* working memory for 842 */
+   void *bounce;   /* bounce buffer to correct alignment */
+
+   /* header includes 1 group, so the total usable groups

[PATCH 08/11] drivers/crypto/nx: simplify pSeries nx842 driver

2015-04-07 Thread Dan Streetman
Simplify the pSeries NX-842 driver: do not expect incoming buffers to be
exactly page-sized; do not break up input buffers to compress smaller blocks;
do not use any internal headers in the compressed data blocks; remove the
software decompression implementation.

This changes the pSeries NX-842 driver to perform constraints-based compression
so that it only needs to compress one entire input block at a time.  This
removes the need for it to split input data blocks into multiple compressed
data sections in the output buffer, and removes the need for any extra header
info in the compressed data; all that is moved (in a later patch) into the
main crypto 842 driver.  Additionally, the 842 software decompression
implementation is no longer needed here, and the crypto 842 driver will use
the generic software 842 decompression function as a fallback if any hardware
842 driver fails.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/nx-842-pseries.c | 779 -
 1 file changed, 153 insertions(+), 626 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index 3773e36..0b7bad3 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -21,7 +21,6 @@
  *  Seth Jennings sjenn...@linux.vnet.ibm.com
  */
 
-#include asm/page.h
 #include asm/vio.h
 
 #include nx-842.h
@@ -32,11 +31,6 @@ MODULE_LICENSE(GPL);
 MODULE_AUTHOR(Robert Jennings r...@linux.vnet.ibm.com);
 MODULE_DESCRIPTION(842 H/W Compression driver for IBM Power processors);
 
-#define SHIFT_4K 12
-#define SHIFT_64K 16
-#define SIZE_4K (1UL  SHIFT_4K)
-#define SIZE_64K (1UL  SHIFT_64K)
-
 /* IO buffer must be 128 byte aligned */
 #define IO_BUFFER_ALIGN 128
 
@@ -47,18 +41,52 @@ static struct nx842_constraints nx842_pseries_constraints = 
{
.maximum =  PAGE_SIZE, /* dynamic, max_sync_size */
 };
 
-struct nx842_header {
-   int blocks_nr; /* number of compressed blocks */
-   int offset; /* offset of the first block (from beginning of header) */
-   int sizes[0]; /* size of compressed blocks */
-};
-
-static inline int nx842_header_size(const struct nx842_header *hdr)
+static int check_constraints(unsigned long buf, unsigned int *len, bool in)
 {
-   return sizeof(struct nx842_header) +
-   hdr-blocks_nr * sizeof(hdr-sizes[0]);
+   if (!IS_ALIGNED(buf, nx842_pseries_constraints.alignment)) {
+   pr_debug(%s buffer 0x%lx not aligned to 0x%x\n,
+in ? input : output, buf,
+nx842_pseries_constraints.alignment);
+   return -EINVAL;
+   }
+   if (*len % nx842_pseries_constraints.multiple) {
+   pr_debug(%s buffer len 0x%x not multiple of 0x%x\n,
+in ? input : output, *len,
+nx842_pseries_constraints.multiple);
+   if (in)
+   return -EINVAL;
+   *len = round_down(*len, nx842_pseries_constraints.multiple);
+   }
+   if (*len  nx842_pseries_constraints.minimum) {
+   pr_debug(%s buffer len 0x%x under minimum 0x%x\n,
+in ? input : output, *len,
+nx842_pseries_constraints.minimum);
+   return -EINVAL;
+   }
+   if (*len  nx842_pseries_constraints.maximum) {
+   pr_debug(%s buffer len 0x%x over maximum 0x%x\n,
+in ? input : output, *len,
+nx842_pseries_constraints.maximum);
+   if (in)
+   return -EINVAL;
+   *len = nx842_pseries_constraints.maximum;
+   }
+   return 0;
 }
 
+/* I assume we need to align the CSB? */
+#define WORKMEM_ALIGN  (256)
+
+struct nx842_workmem {
+   /* scatterlist */
+   char slin[4096];
+   char slout[4096];
+   /* coprocessor status/parameter block */
+   struct nx_csbcpb csbcpb;
+
+   char padding[WORKMEM_ALIGN];
+} __packed __aligned(WORKMEM_ALIGN);
+
 /* Macros for fields within nx_csbcpb */
 /* Check the valid bit within the csbcpb valid field */
 #define NX842_CSBCBP_VALID_CHK(x) (x  BIT_MASK(7))
@@ -72,8 +100,7 @@ static inline int nx842_header_size(const struct 
nx842_header *hdr)
 #define NX842_CSBCPB_CE2(x)(x  BIT_MASK(5))
 
 /* The NX unit accepts data only on 4K page boundaries */
-#define NX842_HW_PAGE_SHIFTSHIFT_4K
-#define NX842_HW_PAGE_SIZE (ASM_CONST(1)  NX842_HW_PAGE_SHIFT)
+#define NX842_HW_PAGE_SIZE (4096)
 #define NX842_HW_PAGE_MASK (~(NX842_HW_PAGE_SIZE-1))
 
 enum nx842_status {
@@ -194,41 +221,6 @@ static int nx842_build_scatterlist(unsigned long buf, int 
len,
return 0;
 }
 
-/*
- * Working memory for software decompression
- */
-struct sw842_fifo {
-   union {
-   char f8[256][8];
-   char f4[512][4];
-   };
-   char f2[256][2];
-   unsigned char f84_full

[PATCH 01/11] powerpc: export of_get_ibm_chip_id function

2015-04-07 Thread Dan Streetman
Export the of_get_ibm_chip_id() function.  This will be used by the
PowerNV NX-842 driver.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 arch/powerpc/kernel/prom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index b8e15c6..f9fb9a2 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -800,6 +800,7 @@ int of_get_ibm_chip_id(struct device_node *np)
}
return -1;
 }
+EXPORT_SYMBOL(of_get_ibm_chip_id);
 
 /**
  * cpu_to_chip_id - Return the cpus chip-id
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 05/11] drivers/crypto/nx: add NX-842 platform frontend driver

2015-04-07 Thread Dan Streetman
Add NX-842 frontend that allows using either the pSeries platform
or PowerNV platform driver for the NX-842 hardware.  Update the
MAINTAINERS file to include the new filenames.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 MAINTAINERS|   2 +-
 crypto/842.c   |   2 +-
 drivers/crypto/Kconfig |   6 +-
 drivers/crypto/nx/Kconfig  |  33 ++---
 drivers/crypto/nx/Makefile |   4 +-
 drivers/crypto/nx/nx-842-pseries.c |  51 ++---
 drivers/crypto/nx/nx-842.c | 144 +
 drivers/crypto/nx/nx-842.h |  32 +
 include/linux/nx842.h  |   6 +-
 9 files changed, 235 insertions(+), 45 deletions(-)
 create mode 100644 drivers/crypto/nx/nx-842.c
 create mode 100644 drivers/crypto/nx/nx-842.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 3dc973a..5a8d46d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4834,7 +4834,7 @@ F:drivers/crypto/nx/
 IBM Power 842 compression accelerator
 M: Dan Streetman ddstr...@us.ibm.com
 S: Supported
-F: drivers/crypto/nx/nx-842.c
+F: drivers/crypto/nx/nx-842*
 F: include/linux/nx842.h
 F: include/linux/sw842.h
 F: lib/842/
diff --git a/crypto/842.c b/crypto/842.c
index b48f4f1..d21cedb 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -52,7 +52,7 @@ static int nx842_init(struct crypto_tfm *tfm)
struct nx842_ctx *ctx = crypto_tfm_ctx(tfm);
int wmemsize;
 
-   wmemsize = max_t(int, nx842_get_workmem_size(), LZO1X_MEM_COMPRESS);
+   wmemsize = max_t(int, NX842_MEM_COMPRESS, LZO1X_MEM_COMPRESS);
ctx-nx842_wmem = kmalloc(wmemsize, GFP_NOFS);
if (!ctx-nx842_wmem)
return -ENOMEM;
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..6d8b11f 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -312,11 +312,11 @@ config CRYPTO_DEV_S5P
  algorithms execution.
 
 config CRYPTO_DEV_NX
-   bool Support for IBM Power7+ in-Nest cryptographic acceleration
-   depends on PPC64  IBMVIO  !CPU_LITTLE_ENDIAN
+   bool Support for IBM Power in-Nest cryptographic acceleration
+   depends on PPC64
default n
help
- Support for Power7+ in-Nest cryptographic acceleration.
+ Support for Power in-Nest cryptographic acceleration.
 
 if CRYPTO_DEV_NX
source drivers/crypto/nx/Kconfig
diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
index f826166..e4396fc 100644
--- a/drivers/crypto/nx/Kconfig
+++ b/drivers/crypto/nx/Kconfig
@@ -1,6 +1,6 @@
 config CRYPTO_DEV_NX_ENCRYPT
-   tristate Encryption acceleration support
-   depends on PPC64  IBMVIO
+   tristate Encryption acceleration support on pSeries platform
+   depends on PPC_PSERIES  IBMVIO  !CPU_LITTLE_ENDIAN
default y
select CRYPTO_AES
select CRYPTO_CBC
@@ -12,15 +12,30 @@ config CRYPTO_DEV_NX_ENCRYPT
select CRYPTO_SHA256
select CRYPTO_SHA512
help
- Support for Power7+ in-Nest encryption acceleration. This
- module supports acceleration for AES and SHA2 algorithms. If you
- choose 'M' here, this module will be called nx_crypto.
+ Support for Power in-Nest encryption acceleration. This
+ module supports acceleration for AES and SHA2 algorithms on
+ the pSeries platform.  If you choose 'M' here, this module
+ will be called nx_crypto.
 
 config CRYPTO_DEV_NX_COMPRESS
tristate Compression acceleration support
-   depends on PPC64  IBMVIO
default y
help
- Support for Power7+ in-Nest compression acceleration. This
- module supports acceleration for AES and SHA2 algorithms. If you
- choose 'M' here, this module will be called nx_compress.
+ Support for Power in-Nest compression acceleration. This
+ module supports acceleration for compressing memory with the 842
+ algorithm.  One of the platform drivers must be selected also.
+ If you choose 'M' here, this module will be called nx_compress.
+
+if CRYPTO_DEV_NX_COMPRESS
+
+config CRYPTO_DEV_NX_PSERIES_COMPRESS
+   tristate Compression acceleration support on pSeries platform
+   depends on PPC_PSERIES  IBMVIO  !CPU_LITTLE_ENDIAN
+   default y
+   help
+ Support for Power in-Nest compression acceleration. This
+ module supports acceleration for compressing memory with the 842
+ algorithm.  This supports NX hardware on the pSeries platform.
+ If you choose 'M' here, this module will be called 
nx_compress_pseries.
+
+endif
diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index 8669ffa..bc7b7ea 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -11,4 +11,6 @@ nx-crypto-objs := nx.o \
  nx-sha512.o
 
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o
-nx-compress

[PATCH 04/11] drivers/crypto/nx: move nx-842.c to nx-842-pseries.c

2015-04-07 Thread Dan Streetman
Move the entire NX-842 driver for the pSeries platform from the file
nx-842.c to nx-842-pseries.c.  This is required by later patches that
add NX-842 support for the PowerNV platform.

This patch does not alter the content of the pSeries NX-842 driver at
all, it only changes the filename.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 drivers/crypto/nx/Makefile |2 +-
 drivers/crypto/nx/nx-842-pseries.c | 1603 
 drivers/crypto/nx/nx-842.c | 1603 
 3 files changed, 1604 insertions(+), 1604 deletions(-)
 create mode 100644 drivers/crypto/nx/nx-842-pseries.c
 delete mode 100644 drivers/crypto/nx/nx-842.c

diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index bb770ea..8669ffa 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -11,4 +11,4 @@ nx-crypto-objs := nx.o \
  nx-sha512.o
 
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS) += nx-compress.o
-nx-compress-objs := nx-842.o
+nx-compress-objs := nx-842-pseries.o
diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
new file mode 100644
index 000..887196e
--- /dev/null
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -0,0 +1,1603 @@
+/*
+ * Driver for IBM Power 842 compression accelerator
+ *
+ * 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, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright (C) IBM Corporation, 2012
+ *
+ * Authors: Robert Jennings r...@linux.vnet.ibm.com
+ *  Seth Jennings sjenn...@linux.vnet.ibm.com
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/nx842.h
+#include linux/of.h
+#include linux/slab.h
+
+#include asm/page.h
+#include asm/vio.h
+
+#include nx_csbcpb.h /* struct nx_csbcpb */
+
+#define MODULE_NAME nx-compress
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Robert Jennings r...@linux.vnet.ibm.com);
+MODULE_DESCRIPTION(842 H/W Compression driver for IBM Power processors);
+
+#define SHIFT_4K 12
+#define SHIFT_64K 16
+#define SIZE_4K (1UL  SHIFT_4K)
+#define SIZE_64K (1UL  SHIFT_64K)
+
+/* IO buffer must be 128 byte aligned */
+#define IO_BUFFER_ALIGN 128
+
+struct nx842_header {
+   int blocks_nr; /* number of compressed blocks */
+   int offset; /* offset of the first block (from beginning of header) */
+   int sizes[0]; /* size of compressed blocks */
+};
+
+static inline int nx842_header_size(const struct nx842_header *hdr)
+{
+   return sizeof(struct nx842_header) +
+   hdr-blocks_nr * sizeof(hdr-sizes[0]);
+}
+
+/* Macros for fields within nx_csbcpb */
+/* Check the valid bit within the csbcpb valid field */
+#define NX842_CSBCBP_VALID_CHK(x) (x  BIT_MASK(7))
+
+/* CE macros operate on the completion_extension field bits in the csbcpb.
+ * CE0 0=full completion, 1=partial completion
+ * CE1 0=CE0 indicates completion, 1=termination (output may be modified)
+ * CE2 0=processed_bytes is source bytes, 1=processed_bytes is target bytes */
+#define NX842_CSBCPB_CE0(x)(x  BIT_MASK(7))
+#define NX842_CSBCPB_CE1(x)(x  BIT_MASK(6))
+#define NX842_CSBCPB_CE2(x)(x  BIT_MASK(5))
+
+/* The NX unit accepts data only on 4K page boundaries */
+#define NX842_HW_PAGE_SHIFTSHIFT_4K
+#define NX842_HW_PAGE_SIZE (ASM_CONST(1)  NX842_HW_PAGE_SHIFT)
+#define NX842_HW_PAGE_MASK (~(NX842_HW_PAGE_SIZE-1))
+
+enum nx842_status {
+   UNAVAILABLE,
+   AVAILABLE
+};
+
+struct ibm_nx842_counters {
+   atomic64_t comp_complete;
+   atomic64_t comp_failed;
+   atomic64_t decomp_complete;
+   atomic64_t decomp_failed;
+   atomic64_t swdecomp;
+   atomic64_t comp_times[32];
+   atomic64_t decomp_times[32];
+};
+
+static struct nx842_devdata {
+   struct vio_dev *vdev;
+   struct device *dev;
+   struct ibm_nx842_counters *counters;
+   unsigned int max_sg_len;
+   unsigned int max_sync_size;
+   unsigned int max_sync_sg;
+   enum nx842_status status;
+} __rcu *devdata;
+static DEFINE_SPINLOCK(devdata_mutex);
+
+#define NX842_COUNTER_INC(_x) \
+static inline void nx842_inc_##_x( \
+   const struct nx842_devdata *dev) { \
+   if (dev) \
+   atomic64_inc(dev-counters-_x); \
+}
+NX842_COUNTER_INC(comp_complete);
+NX842_COUNTER_INC(comp_failed);
+NX842_COUNTER_INC(decomp_complete

[PATCH 02/11] powerpc: Add ICSWX instruction

2015-04-07 Thread Dan Streetman
Add the asm ICSWX and ICSWEPX opcodes.  Add definitions for the
Coprocessor Request structures needed to use the icswx calls to
coprocessors.  Add icswx() function to perform the ICSWX asm
using the provided Coprocessor Command Word value and
Coprocessor Request Block structure.

This is required for communication with the NX-842 coprocessor on
a PowerNV system.

Signed-off-by: Dan Streetman ddstr...@ieee.org
---
 arch/powerpc/include/asm/icswx.h  | 184 ++
 arch/powerpc/include/asm/ppc-opcode.h |  13 +++
 2 files changed, 197 insertions(+)
 create mode 100644 arch/powerpc/include/asm/icswx.h

diff --git a/arch/powerpc/include/asm/icswx.h b/arch/powerpc/include/asm/icswx.h
new file mode 100644
index 000..a70ae93
--- /dev/null
+++ b/arch/powerpc/include/asm/icswx.h
@@ -0,0 +1,184 @@
+/*
+ * ICSWX api
+ *
+ * Copyright (C) 2015 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.
+ *
+ * This provides the Initiate Coprocessor Store Word Indexed (ICSWX)
+ * instruction.  This instruction is used to communicate with PowerPC
+ * coprocessors.  This also provides definitions of the structures used
+ * to communicate with the coprocessor.
+ *
+ * The RFC02130: Coprocessor Architecture document is the reference for
+ * everything in this file unless otherwise noted.
+ */
+#ifndef _ARCH_POWERPC_INCLUDE_ASM_ICSWX_H_
+#define _ARCH_POWERPC_INCLUDE_ASM_ICSWX_H_
+
+#include asm/ppc-opcode.h /* for PPC_ICSWX */
+
+/* Chapter 6.5.8 Coprocessor-Completion Block (CCB) */
+
+#define CCB_VALUE  (0x3fff)
+#define CCB_ADDRESS(0xfff8)
+#define CCB_CM (0x0007)
+#define CCB_CM0(0x0004)
+#define CCB_CM12   (0x0003)
+
+#define CCB_CM0_ALL_COMPLETIONS(0x0)
+#define CCB_CM0_LAST_IN_CHAIN  (0x4)
+#define CCB_CM12_STORE (0x0)
+#define CCB_CM12_INTERRUPT (0x1)
+
+#define CCB_SIZE   (0x10)
+#define CCB_ALIGN  CCB_SIZE
+
+struct coprocessor_completion_block {
+   __be64 value;
+   __be64 address;
+} __packed __aligned(CCB_ALIGN);
+
+
+/* Chapter 6.5.7 Coprocessor-Status Block (CSB) */
+
+#define CSB_V  (0x80)
+#define CSB_F  (0x04)
+#define CSB_CH (0x03)
+#define CSB_CE_INCOMPLETE  (0x80)
+#define CSB_CE_TERMINATION (0x40)
+#define CSB_CE_TPBC(0x20)
+
+#define CSB_CC_SUCCESS (0)
+#define CSB_CC_INVALID_ALIGN   (1)
+#define CSB_CC_OPERAND_OVERLAP (2)
+#define CSB_CC_DATA_LENGTH (3)
+#define CSB_CC_TRANSLATION (5)
+#define CSB_CC_PROTECTION  (6)
+#define CSB_CC_RD_EXTERNAL (7)
+#define CSB_CC_INVALID_OPERAND (8)
+#define CSB_CC_PRIVILEGE   (9)
+#define CSB_CC_INTERNAL(10)
+#define CSB_CC_WR_EXTERNAL (12)
+#define CSB_CC_NOSPC   (13)
+#define CSB_CC_EXCESSIVE_DDE   (14)
+#define CSB_CC_WR_TRANSLATION  (15)
+#define CSB_CC_WR_PROTECTION   (16)
+#define CSB_CC_UNKNOWN_CODE(17)
+#define CSB_CC_ABORT   (18)
+#define CSB_CC_TRANSPORT   (20)
+#define CSB_CC_SEGMENTED_DDL   (31)
+#define CSB_CC_PROGRESS_POINT  (32)
+#define CSB_CC_DDE_OVERFLOW(33)
+#define CSB_CC_SESSION (34)
+#define CSB_CC_PROVISION   (36)
+#define CSB_CC_CHAIN   (37)
+#define CSB_CC_SEQUENCE(38)
+#define CSB_CC_HW  (39)
+
+#define CSB_SIZE   (0x10)
+#define CSB_ALIGN  CSB_SIZE
+
+struct coprocessor_status_block {
+   u8 flags;
+   u8 cs;
+   u8 cc;
+   u8 ce;
+   __be32 count;
+   __be64 address;
+} __packed __aligned(CSB_ALIGN);
+
+
+/* Chapter 6.5.10 Data-Descriptor List (DDL)
+ * each list contains one or more Data-Descriptor Entries (DDE)
+ */
+
+#define DDE_P  (0x8000)
+
+#define DDE_SIZE   (16)
+#define DDE_ALIGN  DDE_SIZE
+
+struct data_descriptor_entry {
+   __be16 flags;
+   u8 count;
+   u8 index;
+   __be32 length;
+   __be64 address;
+} __packed __aligned(DDE_ALIGN);
+
+
+/* Chapter 6.5.2 Coprocessor-Request Block (CRB) */
+
+#define CRB_SIZE   (128)
+#define CRB_ALIGN  (256) /* Errata: requires 256 alignment */
+
+/* Coprocessor Status Block field
+ *   ADDRESS   address of CSB
+ *   C CCB is valid
+ *   AT0 = addrs are virtual, 1 = addrs are phys
+ *   M enable perf monitor
+ */
+#define CRB_CSB_ADDRESS(0xfff0)
+#define CRB_CSB_C  (0x0008)
+#define CRB_CSB_AT (0x0002)
+#define CRB_CSB_M  (0x0001)
+
+struct coprocessor_request_block {
+   __be32 ccw;
+   __be32 flags

Re: algif for compression?

2014-04-03 Thread Dan Streetman
On Thu, Apr 3, 2014 at 8:41 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
 Dan Streetman ddstr...@ieee.org wrote:
 I see the algif_hash and algif_blkcipher implementations to allow
 userspace AF_ALG socket access to kernel blkcipher and hash
 algorithms, but has anyone done a algif_compression to allow userspace
 access to compression algs?  I'm asking specifically wrt the 842
 crypto module, which uses the hardware compression coprocessors on
 newer powerpc systems.

 If not, is there any reason against adding a algif_compression to
 provide the access?

 For a start nx-842 isn't even hooked into the crypto layer so
 there is no chance of exporting it through algif as is.

Wait, isn't it?  The crypto/842.c driver connects right to it.  Well,
it connects to the compression part of it, but that's the only part
I'm looking at exporting to userspace right now.



 There is no reason why you couldn't add it of course but that'd
 be a first step.

 Cheers,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


algif for compression?

2014-03-14 Thread Dan Streetman
I see the algif_hash and algif_blkcipher implementations to allow
userspace AF_ALG socket access to kernel blkcipher and hash
algorithms, but has anyone done a algif_compression to allow userspace
access to compression algs?  I'm asking specifically wrt the 842
crypto module, which uses the hardware compression coprocessors on
newer powerpc systems.

If not, is there any reason against adding a algif_compression to
provide the access?

Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html