This if statement is reversed so we end up either leaking or Oopsing on
error.

Fixes: dbe24620 ('crypto: omap-sham - Use dma_request_chan() for requesting DMA channel')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

With the new dma_request_chan() the client driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the driver can now support deferred probing
against DMA.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: David S. Miller <davem@davemloft.net>
CC: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NDan Williams <dan.j.williams@intel.com>
[hch: split from a larger patch by Dan]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJens Axboe <axboe@fb.com>

omap3 support is same as omap2, just with different IO address (specified in DT)
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Function pm_runtime_get_sync could fail and we need to check return
value to prevent kernel crash.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

kmap_atomic() gives only the page address of the input page.
Driver should take care of adding the offset of the scatterlist
within the page to the returned page address.
omap-sham driver is not adding the offset to page and directly operates
on the return vale of kmap_atomic(), because of which the following
error comes when running crypto tests:

00000000: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
[    2.338169] 00000010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
[    2.344008] alg: hash: Chunking test 1 failed for omap-sha256

So adding the scatterlist offset to vaddr.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

omap_sham_handle_queue() can be called as part of done_task tasklet.
During this its atomic and any calls to pm functions cannot sleep.

But there is a call to pm_runtime_get_sync() (which can sleep) in
omap_sham_handle_queue(), because of which the following appears:
" [  116.169969] BUG: scheduling while atomic: kworker/0:2/2676/0x00000100"

Add pm_runtime_irq_safe() to avoid this.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.

The new code can be compiled with both gcc and clang.
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>

HIGHMEM pages may not be mapped so we must kmap them before accessing.
This resolves a random OOPs error that was showing up during OpenSSL SHA tests.
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Command "tcrypt sec=1 mode=403" give the follwoing error for Polling
mode:
root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403
[...]

[  346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):   4352 opers/sec,  17825792 bytes/sec
[  347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):   7095 opers/sec,  29061120 bytes/sec
[  349.002667] test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates):
[  349.010882] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  349.020037] pgd = ddeac000
[  349.022884] [00000000] *pgd=9dcb4831, *pte=00000000, *ppte=00000000
[  349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[  349.035482] Modules linked in: tcrypt(+)
[  349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted 3.12.4-01566-g6279006-dirty #38
[  349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000
[  349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238
[  349.058544] LR is at omap_sham_xmit_dma+0x38/0x238
[  349.063570] pc : [<c04eb7cc>]    lr : [<c04eb798>]    psr: 20000013
[  349.063570] sp : ddcd3c78  ip : 00000000  fp : 9d8980b8
[  349.075610] r10: 00000000  r9 : 00000000  r8 : 00000000
[  349.081090] r7 : 00001000  r6 : dd898000  r5 : 00000040  r4 : ddb10550
[  349.087935] r3 : 00000004  r2 : 00000010  r1 : 53100080  r0 : 00000000
[  349.094783] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  349.102268] Control: 10c5387d  Table: 9deac019  DAC: 00000015
[  349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248)

[...]

This is because polling_mode is not enabled for ctx without FLAGS_FINUP.

For polling mode the bufcnt is made 0 unconditionally. But it should be made 0
only if it is a final update or a total is not zero(This condition is similar
to what is done in DMA case). Because of this wrong hashes are produced.

Fixing the same.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In omap_sham_probe() and omap_sham_remove(), 'dd->dma_lch'
is released without checking to see if it was successfully
requested or not.  This is a bug and was identified and
reported by Dan Carpenter here:

	http://www.spinics.net/lists/devicetree/msg11023.html

Add code to only release 'dd->dma_lch' when its not NULL
(that is, when it was successfully requested).
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
CC: Joel Fernandes <joelf@ti.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NJoni Lapilainen <joni.lapilainen@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Replace some instances of of_irq_map_one()/irq_create_of_mapping() and
of_irq_to_resource() by the simpler equivalent irq_of_parse_and_map().
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
[grant.likely: resolved conflicts with core code renames]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

Each cycle of SHA512 operates on 32 data words where as
SHA256 operates on 16 data words. This needs to be updated
while configuring DMA channels. Doing the same.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

For writing input buffer into DATA_IN register current driver
has the following state machine:
-> if input buffer < 9 : use fallback driver
-> else if input buffer < block size : Copy input buffer into data_in regs
-> else use dma transfer.

In cases where requesting for DMA channels fails for some reason,
or channel numbers are not provided in DT or platform data, probe
also fails. Instead of returning from driver use cpu polling mode.
In this mode processor polls on INPUT_READY bit and writes data into
data_in regs when it equals 1. This operation is repeated until the
length of message.

Now the state machine looks like:
-> if input buffer < 9 : use fallback driver
-> else if input buffer < block size : Copy input buffer into data_in regs
-> else if dma enabled: use dma transfer
	   else use cpu polling mode.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use devm_kzalloc() to make cleanup paths simpler.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Using devm_request_irq() rather than request_irq().
So removing free_irq() calls from the probe error
path and the remove handler.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for the OMAP5 version of the SHAM module
that is present on OMAP5 and AM43xx SoCs.

This module is very simialar to OMAP4 version of SHAM module,
and adds SHA384 SHA512 hardware-accelerated hash functions to it.
To handle the higher digest size of SHA512, few SHA512_DIGEST_i
(i=1-16, and first 8 registers are duplicated from SHA_DIGEST_i
registers) registers are added at the end of register set.
So adding the above register offsets and module info in pdata.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224
SHA256 that the omap sha module supports.

In order to add the support
- Removed hard coded register offsets and passing offsets from pdata
- Updating Flag offsets so that they can be used for SHA256 and SHA512
- Adding the algo info.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Replace calls to deprecated devm_request_and_ioremap by devm_ioremap_resource.

Found with coccicheck and this semantic patch:
 scripts/coccinelle/api/devm_request_and_ioremap.cocci.
Signed-off-by: NLaurent Navet <laurent.navet@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

module_platform_driver() makes the code simpler by eliminating boilerplate
code.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

After DMA is complete, the omap_sham_finish_req function is called as
a part of the done_task tasklet. During this its atomic and any calls
to pm functions should not assume they wont sleep.

The patch replaces a call to pm_runtime_put_sync (which can sleep) with
pm_runtime_put thus fixing a kernel panic observed on AM33xx SoC during
SHA operation.

Tested on an AM33xx SoC device (beaglebone board).
To reproduce the problem, used the tcrypt kernel module as:
modprobe tcrypt sec=2 mode=403
Signed-off-by: NJoel A Fernandes <joelagnel@ti.com>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Fix the compile errors created by commit 2545e8d
(crypto: omap-sham - Add Device Tree Support)
when CONFIG_OF is not defined.  This includes
changing omap_sham_get_res_dev() to omap_sham_get_res_of()
and creating an empty version of omap_sham_of_match[].
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We still need to fix up few places for multiplatform support,
but that can proceed separately. Fix the issue by making the
problem drivers depends !ARCH_MULTIPLATFORM for now.

The remaining pieces that are not multiplatform compatible
for omap2+ SoCs are:

1. Some drivers are using custom omap_dm_timer calls

There are two drivers that are directly usign omap hardware
timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and
drivers/staging/tidspbridge/core/dsp-clock.c. These can be
fixed for multiplatform by allowing a minimal set of hardware
timers to be accessed, and for some functionality by using the
hrtimer framework.

2. Hardware OMAP4_ERRATA_I688 needs to be fixed up

This can't be enabled for multiplatform configurations in
it's current form. It may be possible to fix it up to do
instruction replacement early on during init. Luckily it
looks like this errata does not seem to get hit with
mainline kernel code alone at least currently.

3. Legacy header needed for omap-sham.c

Looks like it still needs mach/irqs.h for omap1 that
does not exist for multiplatform systems. Just ifdef
it for now.

4. Mailbox is waiting to get moved to drivers

Disable it for now to avoid adding a dependency to the
mailbox patches.

Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
Cc: Sean Young <sean@mess.org>
Cc: "Víctor Manuel Jáquez Leal" <vjaquez@igalia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
[tony@atomide.com: updated to disable mailbox]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP4/AM33xx version of the SHAM crypto module
supports SHA224 and SHA256 in addition to MD5 and
SHA1 that the OMAP2 version of the module supports.

To add this support, use the platform_data introduced
in an ealier commit to hold the list of algorithms
supported by the current module.  The probe routine
will use that list to register the correct algorithms.

Note: The code being integrated is from the TI AM33xx SDK
and was written by Greg Turner <gkmturner@gmail.com> and
Herman Schuurman (current email unknown) while at TI.

CC: Greg Turner <gkmturner@gmail.com>
CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for the OMAP4 version of the SHAM module
that is present on OMAP4 and AM33xx SoCs.

The modules have several differences including register
offsets, hardware XORing, and how DMA is triggered.
To handle these differences, a platform_data structure
is defined and contains routine pointers, register offsets,
bit shifts within registers, and flags to indicate whether
the hardware supports XORing and provides SHA1 results in
big or little endian.  OMAP2/OMAP3-specific routines are
suffixed with '_omap2' and OMAP4/AM33xx routines are suffixed
with '_omap4'.

Note: The code being integrated is from the TI AM33xx SDK
and was written by Greg Turner <gkmturner@gmail.com> and
Herman Schuurman (current email unknown) while at TI.

CC: Greg Turner <gkmturner@gmail.com>
CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use the dma_request_slave_channel_compat() call instead of
the dma_request_channel() call to request a DMA channel.
This allows the omap-sham driver use different DMA engines.

CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add Device Tree suport to the omap-sham crypto
driver.  Currently, only support for OMAP2 and
OMAP3 is being added but support for OMAP4 will
be added in a subsequent patch.

CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.

CC: Russell King <rmk+kernel@arm.linux.org.uk>
CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API.  The API to use is chosen by
defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.

This is a transitional change and the code that uses
the private DMA API will be removed in an upcoming
commit.

CC: Russell King <rmk+kernel@arm.linux.org.uk>
CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add suspend/resume support to the OMAP SHAM driver.

CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Convert the omap-sham crypto driver to use the
pm_runtime API instead of the clk API.

CC: Kevin Hilman <khilman@deeprootsystems.com>
CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Remove the unnecessary pr_info() call in omap_sham_mod_init().

CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Kent Yoder <key@linux.vnet.ibm.com>
Cc: Jamie Iles <jamie@jamieiles.com>
Cc: Kim Phillips <kim.phillips@freescale.com>
Cc: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Cc: Alex Porosanu <alexandru.porosanu@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Based on earlier discussions[1] we attempted to find a suitable
location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
to dmaengine is complete.

Unfortunately that was before I was able to try to test compile
of the ARM multiplatform builds for omap2+, and the end result
was not very good.

So I'm creating yet another all over the place patch to cut the
last dependency for building omap2+ for ARM multiplatform. After
this, we have finally removed the driver dependencies to the
arch/arm code, except for few drivers that are being worked on.

The other option was to make the <plat-omap/dma-omap.h> path
to work, but we'd have to add some new header directory to for
multiplatform builds.

Or we would have to manually include arch/arm/plat-omap/include
again from arch/arm/Makefile for omap2+.

Neither of these alternatives sound appealing as they will
likely lead addition of various other headers exposed to the
drivers, which we want to avoid for the multiplatform kernels.

Since we already have a minimal include/linux/omap-dma.h,
let's just use that instead and add a note to it to not
use the custom omap DMA functions any longer where possible.

Note that converting omap DMA to dmaengine depends on
dmaengine supporting automatically incrementing the FIFO
address at the device end, and converting all the remaining
legacy drivers. So it's going to be few more merge windows.

[1] https://patchwork.kernel.org/patch/1519591/#

cc: Russell King <linux@arm.linux.org.uk>
cc: Kevin Hilman <khilman@ti.com>
cc: "Benoît Cousson" <b-cousson@ti.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Vinod Koul <vinod.koul@intel.com>
cc: Dan Williams <djbw@fb.com>
cc: Mauro Carvalho Chehab <mchehab@infradead.org>
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
cc: Hans Verkuil <hans.verkuil@cisco.com>
cc: Vaibhav Hiremath <hvaibhav@ti.com>
cc: Lokesh Vutla <lokeshvutla@ti.com>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
cc: Afzal Mohammed <afzal@ti.com>
cc: linux-crypto@vger.kernel.org
cc: linux-media@vger.kernel.org
cc: linux-mtd@lists.infradead.org
cc: linux-usb@vger.kernel.org
cc: linux-fbdev@vger.kernel.org
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Drivers should not use cpu_is_omap or cpu_class_is_omap macros,
they should be private to the platform init code. And we'll be
removing plat/cpu.h and only have a private soc.h for the
arch/arm/*omap* code.

This patch is intended as preparation for the core omap changes
and removes the need to include plat/cpu.h from several drivers.
This is needed for the ARM common zImage support.

These changes are OK to do because:

- omap-rng.c does not need plat/cpu.h

- omap-aes.c and omap-sham.c get the proper platform_data
  passed to them so they don't need extra checks in the driver

- omap-dma.c and omap-pcm.c can test the arch locally as
  omap1 and omap2 cannot be compiled together because of
  conflicting compiler flags

Cc: Deepak Saxena <dsaxena@plexity.net>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkatraman S <svenkatr@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: linux-kernel@vger.kernel.org
[tony@atomide.com: mmc changes folded in to an earlier patch]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The added CRYPTO_ALG_KERN_DRIVER_ONLY indicates whether a cipher
is only available via a kernel driver. If the cipher implementation
might be available by using an instruction set or by porting the
kernel code, then it must not be set.
Signed-off-by: NNikos Mavrogiannopoulos <nmav@gnutls.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>