From: Hongbo Zhang <hongbo.zhang@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: devicetree@vger.kernel.org, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, djbw@fb.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] DMA: Freescale: eliminate a compiling warning
Date: Thu, 25 Jul 2013 10:46:33 +0800 [thread overview]
Message-ID: <51F09189.9010602@freescale.com> (raw)
In-Reply-To: <1374694411.15592.63@snotra>
On 07/25/2013 03:33 AM, Scott Wood wrote:
> On 07/24/2013 01:21:09 AM, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> The variable cookie is initialized in a list_for_each_entry loop,
>> if(unlikely)
>> the list is empty, this variable will be used uninitialized, so we
>> get a gcc
>> compiling warning about this. This patch fixes this defect by setting an
>> initial value to the varialble cookie.
>>
>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>> ---
>> drivers/dma/fsldma.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>> index 16a9a48..14d68a4 100644
>> --- a/drivers/dma/fsldma.c
>> +++ b/drivers/dma/fsldma.c
>> @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
>> dma_async_tx_descriptor *tx)
>> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
>> struct fsl_desc_sw *child;
>> unsigned long flags;
>> - dma_cookie_t cookie;
>> + dma_cookie_t cookie = 0;
>>
>> spin_lock_irqsave(&chan->desc_lock, flags);
>
> This patch is unrelated to the rest of the patch series...
>
> What are the semantics of this function if there are multiple entries
> in the list? Returning the last cookie seems a bit odd.
>
> Is zero the proper error value? include/linux/dmaengine.h suggests
> that cookies should be < 0 to indicate error.
I found this compiling warning since the beginning of this work, it is
better somebody fixes it sooner or later, so I take it at last.
Yes it was a bit hard to define the initial value, I saw the
dmaengine.h, and I searched all the other DMA drivers with initial value
before making the decision:
drivers/dma/mv_xor.c: dma_cookie_t cookie = 0;
drivers/dma/sh/shdma-base.c: dma_cookie_t cookie = 0;
drivers/dma/mmp_pdma.c: dma_cookie_t cookie = -EBUSY;
drivers/dma/ppc4xx/adma.c: dma_cookie_t cookie = 0;
drivers/dma/iop-adma.c: dma_cookie_t cookie = 0;
most of them using 0, and only one negative value, it seems better? but
-EBUSY isn't so accurate I think.
My thought is to drop this in the next iteration, and back to this after
the first 3 get merged.
>
> -Scott
WARNING: multiple messages have this Message-ID (diff)
From: Hongbo Zhang <hongbo.zhang@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: vinod.koul@intel.com, djbw@fb.com, leoli@freescale.com,
linuxppc-dev@lists.ozlabs.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 4/4] DMA: Freescale: eliminate a compiling warning
Date: Thu, 25 Jul 2013 10:46:33 +0800 [thread overview]
Message-ID: <51F09189.9010602@freescale.com> (raw)
In-Reply-To: <1374694411.15592.63@snotra>
On 07/25/2013 03:33 AM, Scott Wood wrote:
> On 07/24/2013 01:21:09 AM, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> The variable cookie is initialized in a list_for_each_entry loop,
>> if(unlikely)
>> the list is empty, this variable will be used uninitialized, so we
>> get a gcc
>> compiling warning about this. This patch fixes this defect by setting an
>> initial value to the varialble cookie.
>>
>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>> ---
>> drivers/dma/fsldma.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>> index 16a9a48..14d68a4 100644
>> --- a/drivers/dma/fsldma.c
>> +++ b/drivers/dma/fsldma.c
>> @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
>> dma_async_tx_descriptor *tx)
>> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
>> struct fsl_desc_sw *child;
>> unsigned long flags;
>> - dma_cookie_t cookie;
>> + dma_cookie_t cookie = 0;
>>
>> spin_lock_irqsave(&chan->desc_lock, flags);
>
> This patch is unrelated to the rest of the patch series...
>
> What are the semantics of this function if there are multiple entries
> in the list? Returning the last cookie seems a bit odd.
>
> Is zero the proper error value? include/linux/dmaengine.h suggests
> that cookies should be < 0 to indicate error.
I found this compiling warning since the beginning of this work, it is
better somebody fixes it sooner or later, so I take it at last.
Yes it was a bit hard to define the initial value, I saw the
dmaengine.h, and I searched all the other DMA drivers with initial value
before making the decision:
drivers/dma/mv_xor.c: dma_cookie_t cookie = 0;
drivers/dma/sh/shdma-base.c: dma_cookie_t cookie = 0;
drivers/dma/mmp_pdma.c: dma_cookie_t cookie = -EBUSY;
drivers/dma/ppc4xx/adma.c: dma_cookie_t cookie = 0;
drivers/dma/iop-adma.c: dma_cookie_t cookie = 0;
most of them using 0, and only one negative value, it seems better? but
-EBUSY isn't so accurate I think.
My thought is to drop this in the next iteration, and back to this after
the first 3 get merged.
>
> -Scott
WARNING: multiple messages have this Message-ID (diff)
From: Hongbo Zhang <hongbo.zhang@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: <vinod.koul@intel.com>, <djbw@fb.com>, <leoli@freescale.com>,
<linuxppc-dev@lists.ozlabs.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 4/4] DMA: Freescale: eliminate a compiling warning
Date: Thu, 25 Jul 2013 10:46:33 +0800 [thread overview]
Message-ID: <51F09189.9010602@freescale.com> (raw)
In-Reply-To: <1374694411.15592.63@snotra>
On 07/25/2013 03:33 AM, Scott Wood wrote:
> On 07/24/2013 01:21:09 AM, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> The variable cookie is initialized in a list_for_each_entry loop,
>> if(unlikely)
>> the list is empty, this variable will be used uninitialized, so we
>> get a gcc
>> compiling warning about this. This patch fixes this defect by setting an
>> initial value to the varialble cookie.
>>
>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>> ---
>> drivers/dma/fsldma.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>> index 16a9a48..14d68a4 100644
>> --- a/drivers/dma/fsldma.c
>> +++ b/drivers/dma/fsldma.c
>> @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
>> dma_async_tx_descriptor *tx)
>> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
>> struct fsl_desc_sw *child;
>> unsigned long flags;
>> - dma_cookie_t cookie;
>> + dma_cookie_t cookie = 0;
>>
>> spin_lock_irqsave(&chan->desc_lock, flags);
>
> This patch is unrelated to the rest of the patch series...
>
> What are the semantics of this function if there are multiple entries
> in the list? Returning the last cookie seems a bit odd.
>
> Is zero the proper error value? include/linux/dmaengine.h suggests
> that cookies should be < 0 to indicate error.
I found this compiling warning since the beginning of this work, it is
better somebody fixes it sooner or later, so I take it at last.
Yes it was a bit hard to define the initial value, I saw the
dmaengine.h, and I searched all the other DMA drivers with initial value
before making the decision:
drivers/dma/mv_xor.c: dma_cookie_t cookie = 0;
drivers/dma/sh/shdma-base.c: dma_cookie_t cookie = 0;
drivers/dma/mmp_pdma.c: dma_cookie_t cookie = -EBUSY;
drivers/dma/ppc4xx/adma.c: dma_cookie_t cookie = 0;
drivers/dma/iop-adma.c: dma_cookie_t cookie = 0;
most of them using 0, and only one negative value, it seems better? but
-EBUSY isn't so accurate I think.
My thought is to drop this in the next iteration, and back to this after
the first 3 get merged.
>
> -Scott
next prev parent reply other threads:[~2013-07-25 2:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-24 6:21 [PATCH v5 0/4] DMA: Freescale: Add support for 8-channel DMA engine hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` [PATCH v5 1/4] DMA: Freescale: revise device tree binding document hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` [PATCH v5 2/4] DMA: Freescale: Add new 8-channel DMA engine device tree nodes hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 19:29 ` Scott Wood
2013-07-24 19:29 ` Scott Wood
2013-07-24 19:29 ` Scott Wood
2013-07-24 6:21 ` [PATCH v5 3/4] DMA: Freescale: update driver to support 8-channel DMA engine hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 19:30 ` Scott Wood
2013-07-24 19:30 ` Scott Wood
2013-07-24 19:30 ` Scott Wood
2013-07-24 6:21 ` [PATCH v5 4/4] DMA: Freescale: eliminate a compiling warning hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 6:21 ` hongbo.zhang
2013-07-24 19:33 ` Scott Wood
2013-07-24 19:33 ` Scott Wood
2013-07-24 19:33 ` Scott Wood
2013-07-25 2:46 ` Hongbo Zhang [this message]
2013-07-25 2:46 ` Hongbo Zhang
2013-07-25 2:46 ` Hongbo Zhang
2013-07-24 6:34 ` [PATCH v5 0/4] DMA: Freescale: Add support for 8-channel DMA engine Li Yang
2013-07-24 6:47 ` Li Yang
2013-07-24 6:47 ` Li Yang
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=51F09189.9010602@freescale.com \
--to=hongbo.zhang@freescale.com \
--cc=devicetree@vger.kernel.org \
--cc=djbw@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=scottwood@freescale.com \
--cc=vinod.koul@intel.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.