[PATCH net-next] chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's

2016-09-16 Thread Hariprasad Shenai 
Allocate resources dynamically to cxgb4's Upper layer driver's(ULD) like
cxgbit, iw_cxgb4 and cxgb4i. Allocate resources when they register with
cxgb4 driver and free them while unregistering. All the queues and the
interrupts for them will be allocated during ULD probe only and freed
during remove.

Signed-off-by: Hariprasad Shenai 
---
 drivers/crypto/chelsio/chcr_core.c |   10 +-
 drivers/infiniband/hw/cxgb4/device.c   |4 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |   47 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c |  127 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c|  613 +---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c |  223 ++--
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h |   31 +-
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |   18 +-
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |3 +
 drivers/target/iscsi/cxgbit/cxgbit_main.c  |3 +
 10 files changed, 385 insertions(+), 694 deletions(-)

diff --git a/drivers/crypto/chelsio/chcr_core.c 
b/drivers/crypto/chelsio/chcr_core.c
index 2f6156b..fb5f9bb 100644
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -39,12 +39,10 @@ static chcr_handler_func work_handlers[NUM_CPL_CMDS] = {
[CPL_FW6_PLD] = cpl_fw6_pld_handler,
 };
 
-static struct cxgb4_pci_uld_info chcr_uld_info = {
+static struct cxgb4_uld_info chcr_uld_info = {
.name = DRV_MODULE_NAME,
-   .nrxq = 4,
+   .nrxq = MAX_ULD_QSETS,
.rxq_size = 1024,
-   .nciq = 0,
-   .ciq_size = 0,
.add = chcr_uld_add,
.state_change = chcr_uld_state_change,
.rx_handler = chcr_uld_rx_handler,
@@ -205,7 +203,7 @@ static int chcr_uld_state_change(void *handle, enum 
cxgb4_state state)
 
 static int __init chcr_crypto_init(void)
 {
-   if (cxgb4_register_pci_uld(CXGB4_PCI_ULD1, _uld_info)) {
+   if (cxgb4_register_uld(CXGB4_ULD_CRYPTO, _uld_info)) {
pr_err("ULD register fail: No chcr crypto support in cxgb4");
return -1;
}
@@ -228,7 +226,7 @@ static void __exit chcr_crypto_exit(void)
kfree(u_ctx);
}
mutex_unlock(_mutex);
-   cxgb4_unregister_pci_uld(CXGB4_PCI_ULD1);
+   cxgb4_unregister_uld(CXGB4_ULD_CRYPTO);
 }
 
 module_init(chcr_crypto_init);
diff --git a/drivers/infiniband/hw/cxgb4/device.c 
b/drivers/infiniband/hw/cxgb4/device.c
index 071d733..f170b63 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -1475,6 +1475,10 @@ static int c4iw_uld_control(void *handle, enum 
cxgb4_control control, ...)
 
 static struct cxgb4_uld_info c4iw_uld_info = {
.name = DRV_NAME,
+   .nrxq = MAX_ULD_QSETS,
+   .rxq_size = 511,
+   .ciq = true,
+   .lro = false,
.add = c4iw_uld_add,
.rx_handler = c4iw_uld_rx_handler,
.state_change = c4iw_uld_state_change,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 4595569..1f9867d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -437,11 +437,6 @@ enum {
MAX_ETH_QSETS = 32,   /* # of Ethernet Tx/Rx queue sets */
MAX_OFLD_QSETS = 16,  /* # of offload Tx, iscsi Rx queue sets */
MAX_CTRL_QUEUES = NCHAN,  /* # of control Tx queues */
-   MAX_RDMA_QUEUES = NCHAN,  /* # of streaming RDMA Rx queues */
-   MAX_RDMA_CIQS = 32,/* # of  RDMA concentrator IQs */
-
-   /* # of streaming iSCSIT Rx queues */
-   MAX_ISCSIT_QUEUES = MAX_OFLD_QSETS,
 };
 
 enum {
@@ -458,8 +453,7 @@ enum {
 enum {
INGQ_EXTRAS = 2,/* firmware event queue and */
/*   forwarded interrupts */
-   MAX_INGQ = MAX_ETH_QSETS + MAX_OFLD_QSETS + MAX_RDMA_QUEUES +
-  MAX_RDMA_CIQS + MAX_ISCSIT_QUEUES + INGQ_EXTRAS,
+   MAX_INGQ = MAX_ETH_QSETS + INGQ_EXTRAS,
 };
 
 struct adapter;
@@ -704,10 +698,6 @@ struct sge {
struct sge_ctrl_txq ctrlq[MAX_CTRL_QUEUES];
 
struct sge_eth_rxq ethrxq[MAX_ETH_QSETS];
-   struct sge_ofld_rxq iscsirxq[MAX_OFLD_QSETS];
-   struct sge_ofld_rxq iscsitrxq[MAX_ISCSIT_QUEUES];
-   struct sge_ofld_rxq rdmarxq[MAX_RDMA_QUEUES];
-   struct sge_ofld_rxq rdmaciq[MAX_RDMA_CIQS];
struct sge_rspq fw_evtq cacheline_aligned_in_smp;
struct sge_uld_rxq_info **uld_rxq_info;
 
@@ -717,15 +707,8 @@ struct sge {
u16 max_ethqsets;   /* # of available Ethernet queue sets */
u16 ethqsets;   /* # of active Ethernet queue sets */
u16 ethtxq_rover;   /* Tx queue to clean up next */
-   u16 iscsiqsets;  /* # of active iSCSI queue sets */
-   u16 niscsitq;   /* # of available iSCST Rx queues */
-   u16 rdmaqs;

Re: crypto: caam from tasklet to threadirq

2016-09-16 Thread Russell King - ARM Linux 
On Fri, Sep 16, 2016 at 02:01:00PM +, Cata Vasile wrote:
> Hi,
> 
> We've tried to test and benchmark your submitted work[1].
> 
> Cryptographic offloading is also used in IPsec in the Linux Kernel. In
> heavy traffic scenarios, the NIC driver competes with the crypto device
> driver. Most NICs use the NAPI context, which is one of the most
> prioritized context types. In IPsec scenarios  the performance is
> trashed because, although raw data gets in to device, the data is
> encrypted/decrypted and the dequeue code in CAAM driver has a hard time
> being scheduled to actually call the callback to notify the networking
> stack it can continue working with  that data.

Having received a reply from Thomas Gleixner today, there appears to be
some disagreement with your findings, and a suggestion that the problem
needs proper and more in-depth investigation.

Thomas indicates that the NAPI processing shows an improvement when
moved to the same context that threaded interrupts run in, as opposed
to the current softirq context - which also would run the tasklets.

What I would say is that if threaded IRQs are causing harm, then there
seems to be something very wrong somewhere.

> Being this scenario, at heavy load, the Kernel warns on rcu stalls and
> the forwarding path has a lot of latency.  Have you tried benchmarking
> the board you used for testing?

It's way too long ago for me to remember - these patches were created
almost a year ago - October 20th 2015, which is when I'd have tested
them.  So, I'm afraid I can't help very much at this point, apart from
trying to re-run some benchmarks.

I'd suggest testing the openssl (with AF_ALG support), which is probably
what I tested and benchmarked.  However, as I say, it's far too long
ago for me to really remember at this point.

> I have ran some on our other platforms. The after benchmark fails to
> run at the top level of the before results.

Sorry, that last sentence doesn't make any sense to me.

I don't have the bandwidth to look at this, and IPsec doesn't interest
me one bit - I've never been able to work out how to setup IPsec
locally.  From what I remember when I looked into it many years ago,
you had to have significant information about ipsec to get it up and
running.  Maybe things have changed since then, I don't know.

If you want me to reproduce it, please send me a step-by-step idiots
guide on setting up a working test scenario which reproduces your
problem.

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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

crypto: caam from tasklet to threadirq

2016-09-16 Thread Cata Vasile 
Hi,

We've tried to test and benchmark your submitted work[1].

Cryptographic offloading is also used in IPsec in the Linux Kernel. In heavy 
traffic scenarios, the NIC driver competes with the crypto device driver. Most 
NICs use the NAPI context, which is one of the most prioritized context types. 
In IPsec scenarios  the performance is trashed because, although raw data gets 
in to device, the data is encrypted/decrypted and the dequeue code in CAAM 
driver has a hard time being scheduled to actually call the callback to notify 
the networking stack it can continue working with  that data.

Being this scenario, at heavy load, the Kernel warns on rcu stalls and the 
forwarding path has a lot of latency.
Have you tried benchmarking the board you used for testing?

I have ran some on our other platforms. The after benchmark fails to run at the 
top level of the before results. The rcu stall does not always stall in the 
same place. The after ping latency is greater, and oscillates a lot.

It might be a good idea for the codebase to change to a threadirq, but from a 
pragmatic perspective, the whole system has to suffer. That is one the reasons 
most crypto accelerators try to run dequeue primitives in high priority 
contexts.


Regards,
Catalin Vasile


[1] 
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=66d2e2028091a074aa1290d2eeda5ddb1a6c329c
 --
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: caam - fix sg dump

2016-09-16 Thread Horia Geanta Neag 
On 9/16/2016 12:06 PM, Catalin Vasile wrote:
> Ensure scatterlists have a virtual memory mapping before dumping.
> 
> Signed-off-by: Catalin Vasile 
> ---
>  drivers/crypto/caam/caamalg.c | 65 
> +--
>  1 file changed, 50 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> index 6dc5971..49f1ea7 100644
> --- a/drivers/crypto/caam/caamalg.c
> +++ b/drivers/crypto/caam/caamalg.c
> @@ -111,6 +111,41 @@
>  #else
>  #define debug(format, arg...)
>  #endif
> +
> +#ifdef DEBUG
> +#include 
> +
> +static void dbg_dump_sg(const char *level, const char *prefix_str,
> + int prefix_type, int rowsize, int groupsize,
> + struct scatterlist *sg, size_t tlen, bool ascii)
> +{
> + struct scatterlist *it;
> + size_t len;
> + void *buf;
> +
> + for (it = sg; it != NULL && tlen > 0 ; it = sg_next(sg)) {
> + /*
> +  * make sure the scatterlist's page
> +  * has a valid virtual memory mapping
> +  */
> + buf = kmap(sg_page(it));
Even though driver has been updated recently to use threaded irq instead
of tasklet, there are still cases when you are not allowed to sleep here.
You should check this and use kmap_atomic when needed.

Horia
--
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 -next] hwrng: amd - Fix return value check in mod_init()

2016-09-16 Thread PrasannaKumar Muralidharan 
> In case of error, the function devm_kzalloc() or devm_ioport_map()
> return NULL pointer not ERR_PTR(). The IS_ERR() test in the return
> value check should be replaced with NULL test.
>
> Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API")
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/char/hw_random/amd-rng.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/hw_random/amd-rng.c 
> b/drivers/char/hw_random/amd-rng.c
> index 4dbc5aa..4a99ac7 100644
> --- a/drivers/char/hw_random/amd-rng.c
> +++ b/drivers/char/hw_random/amd-rng.c
> @@ -149,8 +149,8 @@ static int __init mod_init(void)
> return -EIO;
>
> priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> -   if (IS_ERR(priv))
> -   return PTR_ERR(priv);
> +   if (!priv)
> +   return -ENOMEM;
>
> if (!devm_request_region(>dev, pmbase + PMBASE_OFFSET,
> PMBASE_SIZE, DRV_NAME)) {
> @@ -161,9 +161,9 @@ static int __init mod_init(void)
>
> priv->iobase = devm_ioport_map(>dev, pmbase + PMBASE_OFFSET,
> PMBASE_SIZE);
> -   if (IS_ERR(priv->iobase)) {
> +   if (!priv->iobase) {
> pr_err(DRV_NAME "Cannot map ioport\n");
> -   return PTR_ERR(priv->iobase);
> +   return -ENOMEM;
> }
>
> amd_rng.priv = (unsigned long)priv;
>

My change introduced this issue. Thanks for fixing it.
--
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 v3 0/8] Add support for SafeXcel IP-76 to OMAP RNG

2016-09-16 Thread Romain Perier 

Hello,

Le 16/09/2016 12:08, Romain Perier a écrit :

The driver omap-rng has a lot of similarity with the IP block SafeXcel
IP-76. A lot of registers are the same and the way that the driver works
is very closed the description of the TRNG EIP76 in its datasheet.

This series refactorize the driver, add support for generating bigger
output random data and add a device variant for SafeXcel IP-76, found
in Armada 8K.

Romain Perier (8):
   dt-bindings: Add vendor prefix for INSIDE Secure
   dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
   hwrng: omap - Switch to non-obsolete read API implementation
   hwrng: omap - Remove global definition of hwrng
   hwrng: omap - Add support for 128-bit output of data
   hwrng: omap - Don't prefix the probe message with OMAP
   hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
   arm64: dts: marvell: add TRNG description for Armada 8K CP

  Documentation/devicetree/bindings/rng/omap_rng.txt |  14 +-
  .../devicetree/bindings/vendor-prefixes.txt|   1 +
  .../boot/dts/marvell/armada-cp110-master.dtsi  |   8 +
  .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |   8 +
  drivers/char/hw_random/Kconfig |   2 +-
  drivers/char/hw_random/omap-rng.c  | 162 -
  6 files changed, 152 insertions(+), 43 deletions(-)



If possible, I would like to get "Tested-by" tags by the omap guys 
before this set of patches is merged, to be sure that there are no 
regressions for the OMAP variant.


Thanks,
Regards,
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: gcm - Fix IV buffer size in crypto_gcm_setkey

2016-09-16 Thread Ondrej Mosnáček 
The cipher block size for GCM is 16 bytes, and thus the CTR transform
used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
the code currently reserves only 8 bytes for the IV, causing
an out-of-bounds access in the CTR transform. This patch fixes
the issue by setting the size of the IV buffer to 16 bytes.

Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
Signed-off-by: Ondrej Mosnacek 
---
I randomly noticed this while going over igcm.c for an unrelated
reason. It seems the wrong buffer size never caused any noticeable
problems (it's been there since 2007), but it should be corrected
nonetheless...

 crypto/gcm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/gcm.c b/crypto/gcm.c
index 70a892e8..f624ac9 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -117,7 +117,7 @@ static int crypto_gcm_setkey(struct crypto_aead
*aead, const u8 *key,
struct crypto_skcipher *ctr = ctx->ctr;
struct {
be128 hash;
-   u8 iv[8];
+   u8 iv[16];

struct crypto_gcm_setkey_result result;

-- 
2.7.4
--
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 v3 2/8] dt-bindings: omap-rng: Document SafeXcel IP-76 device variant

2016-09-16 Thread Romain Perier 
This commits add missing fields in the documentation that are used
by the new device variant. It also includes DT example to show how
the variant should be used.

Signed-off-by: Romain Perier 
---
 Documentation/devicetree/bindings/rng/omap_rng.txt | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt 
b/Documentation/devicetree/bindings/rng/omap_rng.txt
index 6a62acd..4714772 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ b/Documentation/devicetree/bindings/rng/omap_rng.txt
@@ -1,4 +1,4 @@
-OMAP SoC HWRNG Module
+OMAP SoC and Inside-Secure HWRNG Module
 
 Required properties:
 
@@ -6,11 +6,13 @@ Required properties:
   RNG versions:
   - "ti,omap2-rng" for OMAP2.
   - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+  - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block
   Note that these two versions are incompatible.
 - ti,hwmods: Name of the hwmod associated with the RNG module
 - reg : Offset and length of the register set for the module
 - interrupts : the interrupt number for the RNG module.
-   Only used for "ti,omap4-rng".
+   Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
+- clocks: the trng clock source
 
 Example:
 /* AM335x */
@@ -20,3 +22,11 @@ rng: rng@4831 {
reg = <0x4831 0x2000>;
interrupts = <111>;
 };
+
+/* SafeXcel IP-76 */
+trng: rng@f276 {
+   compatible = "inside-secure,safexcel-eip76";
+   reg = <0xf276 0x7d>;
+   interrupts = ;
+   clocks = <_syscon0 1 25>;
+};
-- 
2.9.3

--
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 v3 4/8] hwrng: omap - Remove global definition of hwrng

2016-09-16 Thread Romain Perier 
The omap-rng driver currently assumes that there will only ever be a
single instance of an RNG device. For this reason, there is a statically
allocated struct hwrng, with a fixed name. However, registering two
struct hwrng with the same isn't accepted by the RNG framework, so we
need to switch to a dynamically allocated struct hwrng, each using a
different name. Then, we define the name of this hwrng to "dev_name(dev)",
so the name of the data structure is unique per device.

Signed-off-by: Romain Perier 
---

Changes in v2:
 - Fix the goto label used when there is an error for devm_kstrdup

 drivers/char/hw_random/omap-rng.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index b3f6047..5ea804d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -127,6 +127,7 @@ struct omap_rng_dev {
void __iomem*base;
struct device   *dev;
const struct omap_rng_pdata *pdata;
+   struct hwrng rng;
 };
 
 static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
@@ -187,12 +188,6 @@ static void omap_rng_cleanup(struct hwrng *rng)
priv->pdata->cleanup(priv);
 }
 
-static struct hwrng omap_rng_ops = {
-   .name   = "omap",
-   .read   = omap_rng_do_read,
-   .init   = omap_rng_init,
-   .cleanup= omap_rng_cleanup,
-};
 
 static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
 {
@@ -365,7 +360,11 @@ static int omap_rng_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
-   omap_rng_ops.priv = (unsigned long)priv;
+   priv->rng.read = omap_rng_do_read;
+   priv->rng.init = omap_rng_init;
+   priv->rng.cleanup = omap_rng_cleanup;
+
+   priv->rng.priv = (unsigned long)priv;
platform_set_drvdata(pdev, priv);
priv->dev = dev;
 
@@ -376,6 +375,12 @@ static int omap_rng_probe(struct platform_device *pdev)
goto err_ioremap;
}
 
+   priv->rng.name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+   if (!priv->rng.name) {
+   ret = -ENOMEM;
+   goto err_ioremap;
+   }
+
pm_runtime_enable(>dev);
ret = pm_runtime_get_sync(>dev);
if (ret) {
@@ -389,7 +394,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_ioremap;
 
-   ret = hwrng_register(_rng_ops);
+   ret = hwrng_register(>rng);
if (ret)
goto err_register;
 
@@ -410,7 +415,7 @@ static int omap_rng_remove(struct platform_device *pdev)
 {
struct omap_rng_dev *priv = platform_get_drvdata(pdev);
 
-   hwrng_unregister(_rng_ops);
+   hwrng_unregister(>rng);
 
priv->pdata->cleanup(priv);
 
-- 
2.9.3

--
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 v3 7/8] hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K

2016-09-16 Thread Romain Perier 
This commits adds a device variant for Safexcel,EIP76 found in Marvell
Armada 8k. It defines registers mapping with the good offset and add a
specific initialization function.

Signed-off-by: Romain Perier 
---

Changes in v2:
 - Call pm_runtime_put_sync from the label err_register. When there is an
   EPROBE_DEFER, strange errors can happen because the call to pm_runtime_*
   is not well balanced.

 drivers/char/hw_random/Kconfig|  2 +-
 drivers/char/hw_random/omap-rng.c | 86 ++-
 2 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 56ad5a5..aea3613 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -168,7 +168,7 @@ config HW_RANDOM_IXP4XX
 
 config HW_RANDOM_OMAP
tristate "OMAP Random Number Generator support"
-   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU
default HW_RANDOM
---help---
  This driver provides kernel-side support for the Random Number
diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index bbbce16..43ee8b3 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -63,6 +64,7 @@
 
 #define OMAP2_RNG_OUTPUT_SIZE  0x4
 #define OMAP4_RNG_OUTPUT_SIZE  0x8
+#define EIP76_RNG_OUTPUT_SIZE  0x10
 
 enum {
RNG_OUTPUT_0_REG = 0,
@@ -108,6 +110,23 @@ static const u16 reg_map_omap4[] = {
[RNG_SYSCONFIG_REG] = 0x1FE4,
 };
 
+static const u16 reg_map_eip76[] = {
+   [RNG_OUTPUT_0_REG]  = 0x0,
+   [RNG_OUTPUT_1_REG]  = 0x4,
+   [RNG_OUTPUT_2_REG]  = 0x8,
+   [RNG_OUTPUT_3_REG]  = 0xc,
+   [RNG_STATUS_REG]= 0x10,
+   [RNG_INTACK_REG]= 0x10,
+   [RNG_CONTROL_REG]   = 0x14,
+   [RNG_CONFIG_REG]= 0x18,
+   [RNG_ALARMCNT_REG]  = 0x1c,
+   [RNG_FROENABLE_REG] = 0x20,
+   [RNG_FRODETUNE_REG] = 0x24,
+   [RNG_ALARMMASK_REG] = 0x28,
+   [RNG_ALARMSTOP_REG] = 0x2c,
+   [RNG_REV_REG]   = 0x7c,
+};
+
 struct omap_rng_dev;
 /**
  * struct omap_rng_pdata - RNG IP block-specific data
@@ -130,6 +149,7 @@ struct omap_rng_dev {
struct device   *dev;
const struct omap_rng_pdata *pdata;
struct hwrng rng;
+   struct clk  *clk;
 };
 
 static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
@@ -221,6 +241,38 @@ static inline u32 omap4_rng_data_present(struct 
omap_rng_dev *priv)
return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
 }
 
+static int eip76_rng_init(struct omap_rng_dev *priv)
+{
+   u32 val;
+
+   /* Return if RNG is already running. */
+   if (omap_rng_read(priv, RNG_CONTROL_REG) & RNG_CONTROL_ENABLE_TRNG_MASK)
+   return 0;
+
+   /*  Number of 512 bit blocks of raw Noise Source output data that must
+*  be processed by either the Conditioning Function or the
+*  SP 800-90 DRBG ???BC_DF??? functionality to yield a ???full 
entropy???
+*  output value.
+*/
+   val = 0x5 << RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT;
+
+   /* Number of FRO samples that are XOR-ed together into one bit to be
+* shifted into the main shift register
+*/
+   val |= RNG_CONFIG_MAX_REFIL_CYCLES << RNG_CONFIG_MAX_REFIL_CYCLES_SHIFT;
+   omap_rng_write(priv, RNG_CONFIG_REG, val);
+
+   /* Enable all available FROs */
+   omap_rng_write(priv, RNG_FRODETUNE_REG, 0x0);
+   omap_rng_write(priv, RNG_FROENABLE_REG, RNG_REG_FROENABLE_MASK);
+
+   /* Enable TRNG */
+   val = RNG_CONTROL_ENABLE_TRNG_MASK;
+   omap_rng_write(priv, RNG_CONTROL_REG, val);
+
+   return 0;
+}
+
 static int omap4_rng_init(struct omap_rng_dev *priv)
 {
u32 val;
@@ -290,6 +342,14 @@ static struct omap_rng_pdata omap4_rng_pdata = {
.cleanup= omap4_rng_cleanup,
 };
 
+static struct omap_rng_pdata eip76_rng_pdata = {
+   .regs   = (u16 *)reg_map_eip76,
+   .data_size  = EIP76_RNG_OUTPUT_SIZE,
+   .data_present   = omap4_rng_data_present,
+   .init   = eip76_rng_init,
+   .cleanup= omap4_rng_cleanup,
+};
+
 static const struct of_device_id omap_rng_of_match[] = {
{
.compatible = "ti,omap2-rng",
@@ -299,6 +359,10 @@ static const struct of_device_id omap_rng_of_match[] = {
.compatible = "ti,omap4-rng",
.data   = _rng_pdata,
},
+   {
+   .compatible = "inside-secure,safexcel-eip76",
+   .data   =

[PATCH v3 3/8] hwrng: omap - Switch to non-obsolete read API implementation

2016-09-16 Thread Romain Perier 
The ".data_present" and ".data_read" operations are marked as OBSOLETE
in the hwrng API. We have to use the ".read" operation instead. It makes
the driver simpler and moves the busy loop, that waits until enough data
is generated, to the read function. We simplify this step by only
checking the status of the engine, if there is data, we copy the data to
the output buffer and the amout of copied data is returned to the caller,
otherwise zero is returned. The hwrng core will re-call the read operation
as many times as required until enough data has been copied.

Signed-off-by: Romain Perier 
---

Changes in v3:
 - Re-add code for busy loop that waits until enough data is generated. When no
   data is available, the busy loop is tried several time until the function
   returns to the hw_random core and then schedule_timeout_interruptible(1) is
   called. in v2, schedule_timeout_interruptible(1) was called each time data
   was not available, which added more latency.

 drivers/char/hw_random/omap-rng.c | 41 ---
 1 file changed, 17 insertions(+), 24 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 01d4be2..b3f6047 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -140,41 +140,35 @@ static inline void omap_rng_write(struct omap_rng_dev 
*priv, u16 reg,
__raw_writel(val, priv->base + priv->pdata->regs[reg]);
 }
 
-static int omap_rng_data_present(struct hwrng *rng, int wait)
+
+static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
+   bool wait)
 {
struct omap_rng_dev *priv;
-   int data, i;
+   int i, present;
 
priv = (struct omap_rng_dev *)rng->priv;
 
+   if (max < priv->pdata->data_size)
+   return 0;
+
for (i = 0; i < 20; i++) {
-   data = priv->pdata->data_present(priv);
-   if (data || !wait)
+   present = priv->pdata->data_present(priv);
+   if (present || !wait)
break;
-   /* RNG produces data fast enough (2+ MBit/sec, even
-* during "rngtest" loads, that these delays don't
-* seem to trigger.  We *could* use the RNG IRQ, but
-* that'd be higher overhead ... so why bother?
-*/
+
udelay(10);
}
-   return data;
-}
-
-static int omap_rng_data_read(struct hwrng *rng, u32 *data)
-{
-   struct omap_rng_dev *priv;
-   u32 data_size, i;
-
-   priv = (struct omap_rng_dev *)rng->priv;
-   data_size = priv->pdata->data_size;
+   if (!present)
+   return 0;
 
-   for (i = 0; i < data_size / sizeof(u32); i++)
-   data[i] = omap_rng_read(priv, RNG_OUTPUT_L_REG + i);
+   memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG],
+ priv->pdata->data_size);
 
if (priv->pdata->regs[RNG_INTACK_REG])
omap_rng_write(priv, RNG_INTACK_REG, RNG_REG_INTACK_RDY_MASK);
-   return data_size;
+
+   return priv->pdata->data_size;
 }
 
 static int omap_rng_init(struct hwrng *rng)
@@ -195,8 +189,7 @@ static void omap_rng_cleanup(struct hwrng *rng)
 
 static struct hwrng omap_rng_ops = {
.name   = "omap",
-   .data_present   = omap_rng_data_present,
-   .data_read  = omap_rng_data_read,
+   .read   = omap_rng_do_read,
.init   = omap_rng_init,
.cleanup= omap_rng_cleanup,
 };
-- 
2.9.3

--
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 v3 6/8] hwrng: omap - Don't prefix the probe message with OMAP

2016-09-16 Thread Romain Perier 
So far, this driver was only used for OMAP SoCs. However, if a device
variant is added for an IP block that has nothing to do with the OMAP
platform, the message "OMAP Random Number Generator Ver" is displayed
anyway. Instead of hardcoding "OMAP" into this message, we decide to
only display "Random Number Generator". As dev_info is already
pre-pending the message with the name of the device, we have enough
informations.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/omap-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index a84ab49..bbbce16 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -400,7 +400,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_register;
 
-   dev_info(>dev, "OMAP Random Number Generator ver. %02x\n",
+   dev_info(>dev, "Random Number Generator ver. %02x\n",
 omap_rng_read(priv, RNG_REV_REG));
 
return 0;
-- 
2.9.3

--
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 v3 8/8] arm64: dts: marvell: add TRNG description for Armada 8K CP

2016-09-16 Thread Romain Perier 
This commits adds the devicetree description of the SafeXcel IP-76 TRNG
found in the two Armada CP110.

Signed-off-by: Romain Perier 
---
 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 8 
 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi  | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi 
b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index da31bbb..aaffa24 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -164,6 +164,14 @@
clocks = <_syscon0 1 21>;
status = "disabled";
};
+
+   cpm_trng: trng@76 {
+   compatible = "marvell,armada-8k-rng", 
"inside-secure,safexcel-eip76";
+   reg = <0x76 0x7d>;
+   interrupts = ;
+   clocks = <_syscon0 1 25>;
+   status = "okay";
+   };
};
 
cpm_pcie0: pcie@f260 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi 
b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6ff1201..216de12 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -164,6 +164,14 @@
clocks = <_syscon0 1 21>;
status = "disabled";
};
+
+   cps_trng: trng@76 {
+   compatible = "marvell,armada-8k-rng", 
"inside-secure,safexcel-eip76";
+   reg = <0x76 0x7d>;
+   interrupts = ;
+   clocks = <_syscon0 1 25>;
+   status = "okay";
+   };
};
 
cps_pcie0: pcie@f460 {
-- 
2.9.3

--
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 v3 5/8] hwrng: omap - Add support for 128-bit output of data

2016-09-16 Thread Romain Perier 
So far, this driver only supports up to 64 bits of output data generated
by an RNG. Some IP blocks, like the SafeXcel IP-76 supports up to 128
bits of output data. This commits renames registers descriptions
OUTPUT_L_REG and OUTPUT_H_REG to OUTPUT_0_REG and OUPUT_1_REG,
respectively. It also adds two new values to the enumeration of existing
registers: OUTPUT_2_REG and OUTPUT_3_REG.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/omap-rng.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 5ea804d..a84ab49 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -65,8 +65,10 @@
 #define OMAP4_RNG_OUTPUT_SIZE  0x8
 
 enum {
-   RNG_OUTPUT_L_REG = 0,
-   RNG_OUTPUT_H_REG,
+   RNG_OUTPUT_0_REG = 0,
+   RNG_OUTPUT_1_REG,
+   RNG_OUTPUT_2_REG,
+   RNG_OUTPUT_3_REG,
RNG_STATUS_REG,
RNG_INTMASK_REG,
RNG_INTACK_REG,
@@ -82,7 +84,7 @@ enum {
 };
 
 static const u16 reg_map_omap2[] = {
-   [RNG_OUTPUT_L_REG]  = 0x0,
+   [RNG_OUTPUT_0_REG]  = 0x0,
[RNG_STATUS_REG]= 0x4,
[RNG_CONFIG_REG]= 0x28,
[RNG_REV_REG]   = 0x3c,
@@ -90,8 +92,8 @@ static const u16 reg_map_omap2[] = {
 };
 
 static const u16 reg_map_omap4[] = {
-   [RNG_OUTPUT_L_REG]  = 0x0,
-   [RNG_OUTPUT_H_REG]  = 0x4,
+   [RNG_OUTPUT_0_REG]  = 0x0,
+   [RNG_OUTPUT_1_REG]  = 0x4,
[RNG_STATUS_REG]= 0x8,
[RNG_INTMASK_REG]   = 0xc,
[RNG_INTACK_REG]= 0x10,
@@ -163,7 +165,7 @@ static int omap_rng_do_read(struct hwrng *rng, void *data, 
size_t max,
if (!present)
return 0;
 
-   memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG],
+   memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_0_REG],
  priv->pdata->data_size);
 
if (priv->pdata->regs[RNG_INTACK_REG])
-- 
2.9.3

--
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 v3 1/8] dt-bindings: Add vendor prefix for INSIDE Secure

2016-09-16 Thread Romain Perier 
This commits adds a vendor for the company INSIDE Secure.
See https://www.insidesecure.com, for more details.

Signed-off-by: Romain Perier 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..6a5e872 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -132,6 +132,7 @@ infineon Infineon Technologies
 inforceInforce Computing
 ingenicIngenic Semiconductor
 innoluxInnolux Corporation
+inside-secure  INSIDE Secure
 intel  Intel Corporation
 intercontrol   Inter Control Group
 invensense InvenSense Inc.
-- 
2.9.3

--
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 v3 0/8] Add support for SafeXcel IP-76 to OMAP RNG

2016-09-16 Thread Romain Perier 
The driver omap-rng has a lot of similarity with the IP block SafeXcel
IP-76. A lot of registers are the same and the way that the driver works
is very closed the description of the TRNG EIP76 in its datasheet.

This series refactorize the driver, add support for generating bigger
output random data and add a device variant for SafeXcel IP-76, found
in Armada 8K.

Romain Perier (8):
  dt-bindings: Add vendor prefix for INSIDE Secure
  dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
  hwrng: omap - Switch to non-obsolete read API implementation
  hwrng: omap - Remove global definition of hwrng
  hwrng: omap - Add support for 128-bit output of data
  hwrng: omap - Don't prefix the probe message with OMAP
  hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
  arm64: dts: marvell: add TRNG description for Armada 8K CP

 Documentation/devicetree/bindings/rng/omap_rng.txt |  14 +-
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 .../boot/dts/marvell/armada-cp110-master.dtsi  |   8 +
 .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |   8 +
 drivers/char/hw_random/Kconfig |   2 +-
 drivers/char/hw_random/omap-rng.c  | 162 -
 6 files changed, 152 insertions(+), 43 deletions(-)

-- 
2.9.3

--
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 v2 3/8] hwrng: omap - Switch to non-obsolete read API implementation

2016-09-16 Thread Romain Perier 

Hi,

Le 13/09/2016 11:48, Herbert Xu a écrit :

On Wed, Sep 07, 2016 at 05:57:38PM +0200, Romain Perier wrote:

+
+static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
+   bool wait)
  {
struct omap_rng_dev *priv;
-   int data, i;

priv = (struct omap_rng_dev *)rng->priv;

-   for (i = 0; i < 20; i++) {
-   data = priv->pdata->data_present(priv);
-   if (data || !wait)
-   break;
-   /* RNG produces data fast enough (2+ MBit/sec, even
-* during "rngtest" loads, that these delays don't
-* seem to trigger.  We *could* use the RNG IRQ, but
-* that'd be higher overhead ... so why bother?
-*/
-   udelay(10);


So in the wait case you're changing the driver's behaviour.  Instead
of waiting for 1us you'll now wait for 1s if there is no data.  Is
this what really what you want?

Cheers,



Mhhh, you're right, in this specific case it will add more latency... 
with busy loop, on average, 20 retries will be enough to have data...


Thanks!
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: caam - fix sg dump

2016-09-16 Thread Catalin Vasile 
Ensure scatterlists have a virtual memory mapping before dumping.

Signed-off-by: Catalin Vasile 
---
 drivers/crypto/caam/caamalg.c | 65 +--
 1 file changed, 50 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 6dc5971..49f1ea7 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -111,6 +111,41 @@
 #else
 #define debug(format, arg...)
 #endif
+
+#ifdef DEBUG
+#include 
+
+static void dbg_dump_sg(const char *level, const char *prefix_str,
+   int prefix_type, int rowsize, int groupsize,
+   struct scatterlist *sg, size_t tlen, bool ascii)
+{
+   struct scatterlist *it;
+   size_t len;
+   void *buf;
+
+   for (it = sg; it != NULL && tlen > 0 ; it = sg_next(sg)) {
+   /*
+* make sure the scatterlist's page
+* has a valid virtual memory mapping
+*/
+   buf = kmap(sg_page(it));
+
+   len = min(tlen, it->length);
+   print_hex_dump(level, prefix_str, prefix_type, rowsize,
+  groupsize, sg_virt(it), len, ascii);
+   tlen -= len;
+
+   kunmap(sg_page(it));
+   }
+}
+#else
+static void dbg_dump_sg(const char *level, const char *prefix_str,
+   int prefix_type, int rowsize, int groupsize,
+   struct scatterlist *sg, size_t tlen, bool ascii)
+{
+}
+#endif
+
 static struct list_head alg_list;
 
 struct caam_alg_entry {
@@ -1984,9 +2019,9 @@ static void ablkcipher_encrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
print_hex_dump(KERN_ERR, "dstiv  @"__stringify(__LINE__)": ",
   DUMP_PREFIX_ADDRESS, 16, 4, req->info,
   edesc->src_nents > 1 ? 100 : ivsize, 1);
-   print_hex_dump(KERN_ERR, "dst@"__stringify(__LINE__)": ",
-  DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
-  edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
+   dbg_dump_sg(KERN_ERR, "dst@"__stringify(__LINE__)": ",
+   DUMP_PREFIX_ADDRESS, 16, 4, req->dst,
+   edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
 #endif
 
ablkcipher_unmap(jrdev, edesc, req);
@@ -2016,9 +2051,9 @@ static void ablkcipher_decrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
print_hex_dump(KERN_ERR, "dstiv  @"__stringify(__LINE__)": ",
   DUMP_PREFIX_ADDRESS, 16, 4, req->info,
   ivsize, 1);
-   print_hex_dump(KERN_ERR, "dst@"__stringify(__LINE__)": ",
-  DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
-  edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
+   dbg_dump_sg(KERN_ERR, "dst@"__stringify(__LINE__)": ",
+   DUMP_PREFIX_ADDRESS, 16, 4, req->dst,
+   edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
 #endif
 
ablkcipher_unmap(jrdev, edesc, req);
@@ -2176,9 +2211,9 @@ static void init_ablkcipher_job(u32 *sh_desc, dma_addr_t 
ptr,
print_hex_dump(KERN_ERR, "presciv@"__stringify(__LINE__)": ",
   DUMP_PREFIX_ADDRESS, 16, 4, req->info,
   ivsize, 1);
-   print_hex_dump(KERN_ERR, "src@"__stringify(__LINE__)": ",
-  DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
-  edesc->src_nents ? 100 : req->nbytes, 1);
+   dbg_dump_sg(KERN_ERR, "src@"__stringify(__LINE__)": ",
+   DUMP_PREFIX_ADDRESS, 16, 4, req->src,
+   edesc->src_nents ? 100 : req->nbytes, 1);
 #endif
 
len = desc_len(sh_desc);
@@ -2233,9 +2268,9 @@ static void init_ablkcipher_giv_job(u32 *sh_desc, 
dma_addr_t ptr,
print_hex_dump(KERN_ERR, "presciv@" __stringify(__LINE__) ": ",
   DUMP_PREFIX_ADDRESS, 16, 4, req->info,
   ivsize, 1);
-   print_hex_dump(KERN_ERR, "src@" __stringify(__LINE__) ": ",
-  DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
-  edesc->src_nents ? 100 : req->nbytes, 1);
+   dbg_dump_sg(KERN_ERR, "src@" __stringify(__LINE__) ": ",
+   DUMP_PREFIX_ADDRESS, 16, 4, req->src,
+   edesc->src_nents ? 100 : req->nbytes, 1);
 #endif
 
len = desc_len(sh_desc);
@@ -2512,9 +2547,9 @@ static int aead_decrypt(struct aead_request *req)
return PTR_ERR(edesc);
 
 #ifdef DEBUG
-   print_hex_dump(KERN_ERR, "dec src@"__stringify(__LINE__)": ",
-  DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
-  req->assoclen + req->cryptlen, 1);
+   dbg_dump_sg(KERN_ERR, "dec src@"__stringify(__LINE__)": ",
+   DUMP_PREFIX_ADDRESS, 16, 4, req->src,
+   req->assoclen + req->cryptlen, 1);