[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54F6909D.8040002@windriver.com>
Date: Wed, 4 Mar 2015 12:57:01 +0800
From: yjin <yanjiang.jin@...driver.com>
To: Kim Phillips <kim.phillips@...escale.com>
CC: <horia.geanta@...escale.com>, <herbert@...dor.apana.org.au>,
<davem@...emloft.net>, <ruchika.gupta@...escale.com>,
<cristian.stoica@...escale.com>, <NiteshNarayanLal@...escale.com>,
<linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<jinyanjiang@...il.com>
Subject: Re: [PATCH 1/3] crypto: caam: fix some compile warnings
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@...driver.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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists