Re: [PATCH] staging: ccree: ssi_aead: fixed all coding style warnings.

2017-12-06 Thread Gilad Ben-Yossef 
Hi Sunil,

On Thu, Dec 7, 2017 at 12:08 AM, SUNIL KALLUR RAMEGOWDA
 wrote:
> My first kernel patch, fixed warnings.
>

Congratulations and may there be many more! :-)

Please note that in addition to what Greg's patch-bot already
mentioned I'm pretty sure you are looking
at Linus's tree and not Greg's staging-next tree which already
contains fixes for many of the issues
your patch is addressing.

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: ccree: ssi_aead: fixed all coding style warnings.

2017-12-06 Thread Greg KH 
On Wed, Dec 06, 2017 at 11:08:09PM +0100, SUNIL KALLUR RAMEGOWDA wrote:
> My first kernel patch, fixed warnings.
> 
> Signed-off-by: SUNIL KALLUR RAMEGOWDA 
> ---
>  drivers/staging/ccree/ssi_aead.c | 179 
> +++
>  1 file changed, 123 insertions(+), 56 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ccree: ssi_aead: fixed all coding style warnings.

2017-12-06 Thread SUNIL KALLUR RAMEGOWDA 
My first kernel patch, fixed warnings.

Signed-off-by: SUNIL KALLUR RAMEGOWDA 
---
 drivers/staging/ccree/ssi_aead.c | 179 +++
 1 file changed, 123 insertions(+), 56 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index ba0954e..afb0036 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -100,7 +100,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
 
/* Unmap enckey buffer */
if (ctx->enckey) {
-   dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey, 
ctx->enckey_dma_addr);
+   dma_free_coherent(dev, AES_MAX_KEY_SIZE,
+ ctx->enckey, ctx->enckey_dma_addr);
dev_dbg(dev, "Freed enckey DMA buffer enckey_dma_addr=%pad\n",
>enckey_dma_addr);
ctx->enckey_dma_addr = 0;
@@ -225,7 +226,8 @@ static int ssi_aead_init(struct crypto_aead *tfm)
return -ENOMEM;
 }
 
-static void ssi_aead_complete(struct device *dev, void *ssi_req, void __iomem 
*cc_base)
+static void ssi_aead_complete(struct device *dev, void *ssi_req,
+ void __iomem *cc_base)
 {
struct aead_request *areq = (struct aead_request *)ssi_req;
struct aead_req_ctx *areq_ctx = aead_request_ctx(areq);
@@ -258,12 +260,20 @@ static void ssi_aead_complete(struct device *dev, void 
*ssi_req, void __iomem *c
 ctx->authsize),
SSI_SG_FROM_BUF);
 
-   /* If an IV was generated, copy it back to the user provided 
buffer. */
+   /* If an IV was generated,
+* copy it back to the user provided buffer.
+*/
if (areq_ctx->backup_giv) {
if (ctx->cipher_mode == DRV_CIPHER_CTR)
-   memcpy(areq_ctx->backup_giv, areq_ctx->ctr_iv + 
CTR_RFC3686_NONCE_SIZE, CTR_RFC3686_IV_SIZE);
+   memcpy(areq_ctx->backup_giv,
+  areq_ctx->ctr_iv +
+   CTR_RFC3686_NONCE_SIZE,
+   CTR_RFC3686_IV_SIZE);
else if (ctx->cipher_mode == DRV_CIPHER_CCM)
-   memcpy(areq_ctx->backup_giv, areq_ctx->ctr_iv + 
CCM_BLOCK_IV_OFFSET, CCM_BLOCK_IV_SIZE);
+   memcpy(areq_ctx->backup_giv,
+  areq_ctx->ctr_iv +
+   CCM_BLOCK_IV_OFFSET,
+   CCM_BLOCK_IV_SIZE);
}
}
 
@@ -274,8 +284,8 @@ static int xcbc_setkey(struct cc_hw_desc *desc, struct 
ssi_aead_ctx *ctx)
 {
/* Load the AES key */
hw_desc_init([0]);
-   /* We are using for the source/user key the same buffer as for the 
output keys,
-* because after this key loading it is not needed anymore
+   /* We are using for the source/user key the same buffer as for the
+* output keys, because after this key loading it is not needed anymore
 */
set_din_type([0], DMA_DLLI,
 ctx->auth_state.xcbc.xcbc_keys_dma_addr, ctx->auth_keylen,
@@ -427,7 +437,8 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
  * (copy to intenral buffer or hash in case of key longer than block
  */
 static int
-ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *key, unsigned int 
keylen)
+ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *key,
+  unsigned int keylen)
 {
dma_addr_t key_dma_addr = 0;
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
@@ -458,9 +469,11 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 
*key, unsigned int keyl
}
 
if (likely(keylen != 0)) {
-   key_dma_addr = dma_map_single(dev, (void *)key, keylen, 
DMA_TO_DEVICE);
+   key_dma_addr = dma_map_single(dev, (void *)key,
+ keylen, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, key_dma_addr))) {
-   dev_err(dev, "Mapping key va=0x%p len=%u for DMA 
failed\n",
+   dev_err(dev,
+   "Mapping key va=0x%p len=%u for DMA failed\n",
key, keylen);
return -ENOMEM;
}
@@ -586,7 +599,8 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key, 
unsigned int keylen)
/* Copy nonce from last 4 bytes in CTR key to
 *  first 4 bytes in CTR IV
 */
-   memcpy(ctx->ctr_nonce, key + ctx->auth_keylen + 
ctx->enc_keylen -
+   memcpy(ctx->ctr_nonce, key +
+   ctx->auth_keylen +