[U-Boot,v3,00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements

On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
> Here is v2 of my patch series to be applied on top of Ian's recently merged
> basic sun7i support.

For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:

arch/arm/cpu/armv7/sunxi/board.c: In function ‘cpu_eth_init’:
arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable
‘rc’ [-Wunused-variable]
  int rc;
      ^
because they both have neither EMAC or GMAC. This resolves it:

8<------------------

From 4eed69132de51d07586e7b070eda72297825a674 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ijc@hellion.org.uk>
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warning

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
---
 arch/arm/cpu/armv7/sunxi/board.c | 2 ++
 1 file changed, 2 insertions(+)

Hi Ian,

Slightly off-topic, but... When you provide some code excerpt, you
should make sure it doesn't look like a git patch, because if it does,
then our Patchwork, which reads the list, will think it is actually a
patch submission:

http://patchwork.ozlabs.org/patch/367391/ 

Amicalement,
Albert.

On Sun, 06 Jul 2014 20:12:17 +0100, Ian Campbell
<ijc@hellion.org.uk> wrote:

> On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
> > Here is v2 of my patch series to be applied on top of Ian's recently merged
> > basic sun7i support.
> 
> For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
> 
> arch/arm/cpu/armv7/sunxi/board.c: In function ‘cpu_eth_init’:
> arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable
> ‘rc’ [-Wunused-variable]
>   int rc;
>       ^
> because they both have neither EMAC or GMAC. This resolves it:
> 
> 8<------------------
> 
> From 4eed69132de51d07586e7b070eda72297825a674 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ijc@hellion.org.uk>
> Date: Sun, 6 Jul 2014 20:03:20 +0100
> Subject: [PATCH] sunxi: Avoid unused variable warning
> 
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> ---
>  arch/arm/cpu/armv7/sunxi/board.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
> index 1e506b5..f8db9e8 100644
> --- a/arch/arm/cpu/armv7/sunxi/board.c
> +++ b/arch/arm/cpu/armv7/sunxi/board.c
> @@ -115,7 +115,9 @@ void enable_caches(void)
>   */
>  int cpu_eth_init(bd_t *bis)
>  {
> +#if defined(CONFIG_SUNXI_EMAC) || defined(CONFIG_SUNXI_GMAC)
>  	int rc;
> +#endif
>  
>  #ifdef CONFIG_SUNXI_EMAC
>  	rc = sunxi_emac_initialize(bis);

On Sun, 2014-07-06 at 21:18 +0200, Albert ARIBAUD wrote:
> Hi Ian,
> 
> Slightly off-topic, but... When you provide some code excerpt, you
> should make sure it doesn't look like a git patch, because if it does,
> then our Patchwork, which reads the list, will think it is actually a
> patch submission:

I suppose this was a submission, although I was mostly planning to short
circuit it straight into the appropriate branch.

How much do I need to corrupt something before patchwork will ignore it?

Ian.

Hi Ian,

On Sun, 06 Jul 2014 20:22:31 +0100, Ian Campbell <ijc@hellion.org.uk>
wrote:

> On Sun, 2014-07-06 at 21:18 +0200, Albert ARIBAUD wrote:
> > Hi Ian,
> > 
> > Slightly off-topic, but... When you provide some code excerpt, you
> > should make sure it doesn't look like a git patch, because if it does,
> > then our Patchwork, which reads the list, will think it is actually a
> > patch submission:
> 
> I suppose this was a submission, although I was mostly planning to short
> circuit it straight into the appropriate branch.

Hmm, short-circuiting a code change is risky -- all U-Boot code should
go through the list and be reviewed.

If your post was a submission, then it should be the pure result of a
git format-patch or of a patman command.

> How much do I need to corrupt something before patchwork will ignore it?

Basically, if you can (try to) 'git apply' the post, chances are PW
will consider it a submission.

> Ian.

Amicalement,

On Sun, 2014-07-06 at 22:54 +0200, Albert ARIBAUD wrote:
> Hi Ian,
> 
> On Sun, 06 Jul 2014 20:22:31 +0100, Ian Campbell <ijc@hellion.org.uk>
> wrote:
> 
> > On Sun, 2014-07-06 at 21:18 +0200, Albert ARIBAUD wrote:
> > > Hi Ian,
> > > 
> > > Slightly off-topic, but... When you provide some code excerpt, you
> > > should make sure it doesn't look like a git patch, because if it does,
> > > then our Patchwork, which reads the list, will think it is actually a
> > > patch submission:
> > 
> > I suppose this was a submission, although I was mostly planning to short
> > circuit it straight into the appropriate branch.
> 
> Hmm, short-circuiting a code change is risky -- all U-Boot code should
> go through the list and be reviewed.

Oh, I didn't mean to suggest skipping all that good stuff, just that the
patch is already in a local branch ready to go when it is acked so I
don't need to fetch it from patchwork.

Getting it reviewed was why I posted it.

> If your post was a submission, then it should be the pure result of a
> git format-patch or of a patman command.

The thing I posted was the output of git format-patch.

> > How much do I need to corrupt something before patchwork will ignore it?
> 
> Basically, if you can (try to) 'git apply' the post, chances are PW
> will consider it a submission.

I think that is what I wanted on this occasion.

Ian.

Dear Ian Campbell,

In message <1404682080.11284.33.camel@dagon.hellion.org.uk> you wrote:
>
> Oh, I didn't mean to suggest skipping all that good stuff, just that the
> patch is already in a local branch ready to go when it is acked so I
> don't need to fetch it from patchwork.

It is a very good thiong to fetch patches from PW, as this will allow
you to automatically also fetch all ACKs you get from other people.
If you don't use PW, you will have to track the mailing list and
insert all Acked-by: and Tested-By: etc. manually.  I don;t think you
want to do that.


Best regards,

Wolfgang Denk

Hi Ian,

On 07/06/2014 09:12 PM, Ian Campbell wrote:
> On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
>> Here is v2 of my patch series to be applied on top of Ian's recently merged
>> basic sun7i support.
> 
> For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
> 
> arch/arm/cpu/armv7/sunxi/board.c: In function ‘cpu_eth_init’:
> arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable
> ‘rc’ [-Wunused-variable]
>   int rc;
>       ^
> because they both have neither EMAC or GMAC. This resolves it:
> 
> 8<------------------
> 
> From 4eed69132de51d07586e7b070eda72297825a674 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ijc@hellion.org.uk>
> Date: Sun, 6 Jul 2014 20:03:20 +0100
> Subject: [PATCH] sunxi: Avoid unused variable warning
> 
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> ---
>  arch/arm/cpu/armv7/sunxi/board.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
> index 1e506b5..f8db9e8 100644
> --- a/arch/arm/cpu/armv7/sunxi/board.c
> +++ b/arch/arm/cpu/armv7/sunxi/board.c
> @@ -115,7 +115,9 @@ void enable_caches(void)
>   */
>  int cpu_eth_init(bd_t *bis)
>  {
> +#if defined(CONFIG_SUNXI_EMAC) || defined(CONFIG_SUNXI_GMAC)
>  	int rc;
> +#endif
>  
>  #ifdef CONFIG_SUNXI_EMAC
>  	rc = sunxi_emac_initialize(bis);

AFAIK we will never define both EMAC and GMAC for the same board,
so IMHO a better fix would be to change this line:

  	rc = sunxi_emac_initialize(bis);

to:

  	int rc = sunxi_emac_initialize(bis);

And the same for gmac.

Regards,

Hans

On Mon, 2014-07-07 at 14:50 +0200, Hans de Goede wrote:
> AFAIK we will never define both EMAC and GMAC for the same board,

If we are sure of this (and I suspect this is the case, since IIRC they
share some pins) then I agree with your suggestion.

> so IMHO a better fix would be to change this line:
> 
>   	rc = sunxi_emac_initialize(bis);
> 
> to:
> 
>   	int rc = sunxi_emac_initialize(bis);
> 
> And the same for gmac.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
>

On Mon, Jul 07, 2014 at 04:10:42PM +0100, Ian Campbell wrote:
> On Mon, 2014-07-07 at 14:50 +0200, Hans de Goede wrote:
> > AFAIK we will never define both EMAC and GMAC for the same board,
> 
> If we are sure of this (and I suspect this is the case, since IIRC they
> share some pins) then I agree with your suggestion.
> 
> > so IMHO a better fix would be to change this line:
> > 
> >   	rc = sunxi_emac_initialize(bis);
> > 
> > to:
> > 
> >   	int rc = sunxi_emac_initialize(bis);

That's not how we like things to look however when we can help it.  Just
toss a __maybe_unused in front of the declaration (and make sure we have
<linux/compiler.h> included.