All of lore.kernel.org
 help / color / mirror / Atom feed
From: yjin <yanjiang.jin@windriver.com>
To: Kim Phillips <kim.phillips@freescale.com>
Cc: <horia.geanta@freescale.com>, <herbert@gondor.apana.org.au>,
	<davem@davemloft.net>, <ruchika.gupta@freescale.com>,
	<cristian.stoica@freescale.com>, <NiteshNarayanLal@freescale.com>,
	<linux-crypto@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<jinyanjiang@gmail.com>
Subject: Re: [PATCH 1/3] crypto: caam: fix some compile warnings
Date: Wed, 4 Mar 2015 12:57:01 +0800	[thread overview]
Message-ID: <54F6909D.8040002@windriver.com> (raw)
In-Reply-To: <54F66EA3.7080506@windriver.com>


On 2015年03月04日 10:32, yjin wrote:
>
> On 2015年03月04日 02:59, Kim Phillips wrote:
>> On Tue, 3 Mar 2015 14:50:51 +0800
>> <yanjiang.jin@windriver.com> wrote:
>>
>>> This commit is to avoid the below warnings:
>>>
>>> drivers/crypto/caam/sg_sw_sec4.h:88:12: warning:
>>> 'dma_map_sg_chained' defined but not used [-Wunused-function]
>>>   static int dma_map_sg_chained(struct device *dev, struct 
>>> scatterlist *sg,
>>>              ^
>>> drivers/crypto/caam/sg_sw_sec4.h:104:12: warning:
>>> 'dma_unmap_sg_chained' defined but not used [-Wunused-function]
>>>   static int dma_unmap_sg_chained(struct device *dev,
>>>              ^
>> I'm not seeing these warnings - both caamalg.c and caamhash.c use
>> those functions fine.
>
> As you said, both caamalg.c and caamhash.c use those functions, so no 
> warning reported.
>
> But if a new file just wants to include "sg_sw_sec4.h", doesn't want 
> to use these functions, the above warnings will appear.
>
> We can find an example in Freescale SDK 1.6:
> caampkc.c includes pkc_desc.h, pkc_desc.h includes sg_sw_sec4.h, but 
> caampkc.c doesn't call those functions.
>
> Without my patch, every file which includes sg_sw_sec4.h must call 
> these two functions in the future, I don't think it is a good idea.
>
> Thanks!
> Yanjiang
>>
>>> -static int dma_map_sg_chained(struct device *dev, struct 
>>> scatterlist *sg,
>>> +static inline int dma_map_sg_chained(struct device *dev, struct 
>>> scatterlist *sg,
>>>                     unsigned int nents, enum dma_data_direction dir,
>>>                     bool chained)
>> not to mention this isn't how to fix a defined but not used warning:
>> marking the functions inline results in different compiler output.
>>
>> NACK from me.
An alternative is moving the definitions to a ".c" file, but I don't 
think it will be fundamental different.
I know I am fixing a potential error which doesn't exist now, it seems 
useless for the current upstream version, we can abandon my patch. But I 
still think the current implementation adds unnecessary restrictions for 
its users.

Thanks!
Yanjiang
>>
>> Kim
>>
>>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

  reply	other threads:[~2015-03-04  4:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03  6:50 [PATCH 0/3] fix some CAAM warnings yanjiang.jin
2015-03-03  6:50 ` [PATCH 1/3] crypto: caam: fix some compile warnings yanjiang.jin
2015-03-03 18:59   ` Kim Phillips
2015-03-04  2:32     ` yjin
2015-03-04  4:57       ` yjin [this message]
2015-03-04  9:03         ` Cristian Stoica
2015-03-04 18:34           ` Kim Phillips
2015-03-05  7:12             ` Cristian Stoica
2015-03-06  0:38               ` Kim Phillips
2015-03-04  8:48       ` Cristian Stoica
2015-03-04  9:11       ` Cristian Stoica
2015-03-03  6:50 ` [PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem yanjiang.jin
2015-03-03 19:31   ` Kim Phillips
2015-03-04  5:33     ` yjin
2015-03-04 18:36       ` Kim Phillips
2015-03-05  2:52         ` yjin
2015-03-06  0:28           ` Kim Phillips
2015-03-03  6:50 ` [PATCH 3/3] crypto: caamhash: - fix uninitialized edesc->sec4_sg_bytes field yanjiang.jin
2015-03-03 13:39 ` [PATCH 0/3] fix some CAAM warnings Horia Geantă

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F6909D.8040002@windriver.com \
    --to=yanjiang.jin@windriver.com \
    --cc=NiteshNarayanLal@freescale.com \
    --cc=cristian.stoica@freescale.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@freescale.com \
    --cc=jinyanjiang@gmail.com \
    --cc=kim.phillips@freescale.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ruchika.gupta@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.