Re: [PATCH] crypto: nx-842: Delete an error message for a failed memory allocation in nx842_pseries_init()
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
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
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
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
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
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
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
On Mon, Aug 28, 2017 at 7:25 PM, Michael Ellermanwrote: > 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
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
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
On Sun, Dec 6, 2015 at 2:46 AM, Haren Myneniwrote: > > 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
On Sun, Dec 6, 2015 at 5:57 PM, Daniel Axtenswrote: > 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()
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
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
On Fri, Oct 30, 2015 at 6:45 PM, Ram Paiwrote: > 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
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
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
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
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
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
On Mon, Sep 21, 2015 at 10:26 AM, Herbert Xuwrote: > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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