All of lore.kernel.org
 help / color / mirror / Atom feed
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




  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.