[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Simon Glass]

This series fixes some warnings which seem to still be left over from
all the warning-squashing efforts for 2011.12. If patches exist for some
of these already then please ignore.

The alias problem in USB is a bit odd, since I thought it was already
fixed. But perhaps it has come back.


Simon Glass (9):
  usb: Fix strict-aliasing warning in host/ohci-hcd.c
  Fix strict-aliasing warning in dlmalloc
  mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c
  ppc4xx: Fix strict-aliasing warnings in usb_ohci.c
  sandbox: sort header files in os.c
  sandbox: Add required header to os.c
  Remove CONFIG_SYS_EXTBDINFO from snapper9260.h
  m68k: Change memsz to a signed char to avoid warning
  ppc: Change memsz variable to signed char

 arch/m68k/lib/board.c               |    2 +-
 arch/powerpc/cpu/mpc5xxx/usb_ohci.c |   79 ++++++++++++++++++++--------------
 arch/powerpc/cpu/ppc4xx/usb_ohci.c  |   81 ++++++++++++++++++++--------------
 arch/powerpc/lib/board.c            |    7 +--
 arch/sandbox/cpu/os.c               |   11 +++--
 common/dlmalloc.c                   |    8 ++--
 drivers/usb/host/ohci-hcd.c         |   26 ++++++------
 include/configs/snapper9260.h       |    1 -
 8 files changed, 122 insertions(+), 93 deletions(-)

-- 
1.7.3.1

[U-Boot] [PATCH 1/9] usb: Fix strict-aliasing warning in host/ohci-hcd.c

[Simon Glass]

This fixes these warnings seen with my gcc 4.6 compiler.

ohci-hcd.c: In function 'submit_control_msg':
ohci-hcd.c:1307: warning: dereferencing pointer 'pretmp.729' does break strict-aliasing rules
cc1: note: initialized from here
ohci-hcd.c:1310: warning: dereferencing pointer 'pretmp.729' does break strict-aliasing rules
cc1: note: initialized from here
ohci-hcd.c:1313: warning: dereferencing pointer 'pretmp.729' does break strict-aliasing rules

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 drivers/usb/host/ohci-hcd.c |   26 +++++++++++++-------------
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index cf906b4..2cbb326 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1261,20 +1261,18 @@ static int ohci_submit_rh_msg(struct usb_device *dev, unsigned long pipe,
 	int leni = transfer_len;
 	int len = 0;
 	int stat = 0;
-	__u32 datab[4];
+	u8 *dataptr = NULL;
 	union {
-		void *ptr;
-		__u8 *u8;
-		__u16 *u16;
-		__u32 *u32;
+		/* data will be in here when dataptr stays as NULL */
+		__u8 u8[16];
+		__u16 u16[8];
+		__u32 u32[3];
 	} databuf;
 	__u16 bmRType_bReq;
 	__u16 wValue;
 	__u16 wIndex;
 	__u16 wLength;
 
-	databuf.u32 = (__u32 *)datab;
-
 #ifdef DEBUG
 pkt_print(NULL, dev, pipe, buffer, transfer_len,
 	  cmd, "SUB(rh)", usb_pipein(pipe));
@@ -1381,14 +1379,14 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len,
 					min_t(unsigned int,
 					sizeof(root_hub_dev_des),
 					wLength));
-			databuf.ptr = root_hub_dev_des; OK(len);
+			dataptr = root_hub_dev_des; OK(len);
 		case (0x02): /* configuration descriptor */
 			len = min_t(unsigned int,
 					leni,
 					min_t(unsigned int,
 					sizeof(root_hub_config_des),
 					wLength));
-			databuf.ptr = root_hub_config_des; OK(len);
+			dataptr = root_hub_config_des; OK(len);
 		case (0x03): /* string descriptors */
 			if (wValue == 0x0300) {
 				len = min_t(unsigned int,
@@ -1396,7 +1394,7 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len,
 						min_t(unsigned int,
 						sizeof(root_hub_str_index0),
 						wLength));
-				databuf.ptr = root_hub_str_index0;
+				dataptr = root_hub_str_index0;
 				OK(len);
 			}
 			if (wValue == 0x0301) {
@@ -1405,7 +1403,7 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len,
 						min_t(unsigned int,
 						sizeof(root_hub_str_index1),
 						wLength));
-				databuf.ptr = root_hub_str_index1;
+				dataptr = root_hub_str_index1;
 				OK(len);
 		}
 		default:
@@ -1469,8 +1467,10 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len,
 #endif
 
 	len = min_t(int, len, leni);
-	if (data != databuf.ptr)
-		memcpy(data, databuf.ptr, len);
+	if (dataptr)
+		memcpy(data, dataptr, len);
+	else
+		memcpy(data, &databuf, len);
 	dev->act_len = len;
 	dev->status = stat;
 
-- 
1.7.3.1

[U-Boot] [PATCH 1/9] usb: Fix strict-aliasing warning in host/ohci-hcd.c

[Mike Frysinger]

On Thursday 05 January 2012 22:54:49 Simon Glass wrote:
>  	len = min_t(int, len, leni);
> -	if (data != databuf.ptr)
> -		memcpy(data, databuf.ptr, len);
> +	if (dataptr)
> +		memcpy(data, dataptr, len);
> +	else
> +		memcpy(data, &databuf, len);

this doesn't seem to be equivalent ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120108/4f780a19/attachment.pgp>

[U-Boot] [PATCH 1/9] usb: Fix strict-aliasing warning in host/ohci-hcd.c

[Simon Glass]

Hi Mike,

On Sun, Jan 8, 2012 at 1:32 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 05 January 2012 22:54:49 Simon Glass wrote:
>> ? ? ? len = min_t(int, len, leni);
>> - ? ? if (data != databuf.ptr)
>> - ? ? ? ? ? ? memcpy(data, databuf.ptr, len);
>> + ? ? if (dataptr)
>> + ? ? ? ? ? ? memcpy(data, dataptr, len);
>> + ? ? else
>> + ? ? ? ? ? ? memcpy(data, &databuf, len);
>
> this doesn't seem to be equivalent ?
> -mike

I believe it is if you look at the entire change, but I might have
missed something. dataptr is used only when we want to pull in the USB
descriptor info. Otherwise we use our local databuf union.

Regards,
Simon

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Simon Glass]

This fixes the following warnings in dlmalloc seen with my gcc 4.6.

dlmalloc.c: In function 'malloc_bin_reloc':
dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
dlmalloc.c:1490: note: initialized from here
dlmalloc.c:1493: note: initialized from here

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/dlmalloc.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index c645d73..0a719b4 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1487,11 +1487,11 @@ static mbinptr av_[NAV * 2 + 2] = {
 #ifdef CONFIG_NEEDS_MANUAL_RELOC
 void malloc_bin_reloc (void)
 {
-	unsigned long *p = (unsigned long *)(&av_[2]);
+	mbinptr *p = &av_[2];
 	int i;
-	for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) {
-		*p++ += gd->reloc_off;
-	}
+
+	for (i = 2; i < ARRAY_SIZE(av_); ++i)
+		*p = (mbinptr)((ulong)*p + gd->reloc_off);
 }
 #endif
 
-- 
1.7.3.1

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Wolfgang Denk]

Dear Simon Glass,

In message <1325822097-15227-3-git-send-email-sjg@chromium.org> you wrote:
> This fixes the following warnings in dlmalloc seen with my gcc 4.6.

Which exact version is this?

> dlmalloc.c: In function 'malloc_bin_reloc':
> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
> dlmalloc.c:1490: note: initialized from here
> dlmalloc.c:1493: note: initialized from here

Can you please tell me at least one board configuration that throws
this error (preferrably ppc, arm or mips) ?

Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in
usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c"
patches?

I wonder why I don't see any such warnings.  Which exact commit ID are
you building?

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Make it right before you make it faster.

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Simon Glass]

Hi Wolfgang,

On Thu, Jan 5, 2012 at 10:48 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1325822097-15227-3-git-send-email-sjg@chromium.org> you wrote:
>> This fixes the following warnings in dlmalloc seen with my gcc 4.6.
>
> Which exact version is this?
>
>> dlmalloc.c: In function 'malloc_bin_reloc':
>> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
>> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
>> dlmalloc.c:1490: note: initialized from here
>> dlmalloc.c:1493: note: initialized from here
>
> Can you please tell me at least one board configuration that throws
> this error (preferrably ppc, arm or mips) ?

I can't see one with those architectures. It does happen for others though:

$ (for b in $(cd ~/cosarm/buildall/logs.master.9a42098 && grep -l 1493
*ERR |sed 's/.ERR//'); do grep $b boards.cfg; done ) |awk '{print $2,
$1}'
avr32 atngw100
avr32 atstk1002
avr32 atstk1003
avr32 atstk1004
avr32 atstk1006
mips dbau1000
mips dbau1100
mips dbau1500
mips dbau1550
mips dbau1550_el
avr32 favr-32-ezkit
avr32 grasshopper
mips gth2
avr32 hammerhead
mips incaip
mips incaip_100MHz
mips incaip_133MHz
mips incaip_150MHz
m68k M54451EVB
m68k M54451EVB_stmicro
m68k M54451EVB_stmicro
m68k M54455EVB_a66
m68k M54455EVB
m68k M54455EVB_a66
m68k M54455EVB_i66
m68k M54455EVB_intel
m68k M54455EVB_stm33
m68k M54455EVB_i66
m68k M54455EVB_intel
m68k M54455EVB_stm33
m68k M5475AFE
m68k M5475BFE
m68k M5475CFE
m68k M5475DFE
m68k M5475EFE
m68k M5475FFE
m68k M5475GFE
m68k M5485AFE
m68k M5485BFE
m68k M5485CFE
m68k M5485DFE
m68k M5485EFE
m68k M5485FFE
m68k M5485GFE
m68k M5485HFE
avr32 mimc200
mips qemu_mips
mips vct_platinumavc
mips vct_platinumavc_onenand
mips vct_platinumavc_onenand_small
mips vct_platinumavc_small
mips vct_platinumavc_onenand
mips vct_platinumavc_onenand_small
mips vct_platinumavc_onenand_small
mips vct_platinumavc_small
mips vct_platinum
mips vct_platinumavc
mips vct_platinumavc_onenand
mips vct_platinumavc_onenand_small
mips vct_platinumavc_small
mips vct_platinum_onenand
mips vct_platinum_onenand_small
mips vct_platinum_small
mips vct_platinum_onenand
mips vct_platinum_onenand_small
mips vct_platinum_onenand_small
mips vct_platinum_small
mips vct_premium
mips vct_premium_onenand
mips vct_premium_onenand_small
mips vct_premium_small
mips vct_premium_onenand
mips vct_premium_onenand_small
mips vct_premium_onenand_small
mips vct_premium_small

Using built-in specs.
Target: mips-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=mips-linux --enable-targets=all
--prefix=/opt/cross/gcc-4.4.4-nolibc/mips-linux/ --enable-languages=c
--with-newlib --without-headers --enable-sjlj-exceptions
--with-system-libunwind --disable-nls --disable-threads
--disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --enable-checking=release
--with-mpfr=/home/tony/buildall/src/sys
--with-gmp=/home/tony/buildall/src/sys
Thread model: single
gcc version 4.4.4 (GCC)

Using built-in specs.
Target: m68k-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=m68k-linux --enable-targets=all
--prefix=/opt/cross/gcc-4.4.4-nolibc/m68k-linux/ --enable-languages=c
--with-newlib --without-headers --enable-sjlj-exceptions
--with-system-libunwind --disable-nls --disable-threads
--disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --enable-checking=release
--with-mpfr=/home/tony/buildall/src/sys
--with-gmp=/home/tony/buildall/src/sys
Thread model: single
gcc version 4.4.4 (GCC)

Using built-in specs.
Target: powerpc-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=powerpc-linux --enable-targets=all
--prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/
--enable-languages=c --with-newlib --without-headers
--enable-sjlj-exceptions --with-system-libunwind --disable-nls
--disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--enable-checking=release --with-mpfr=/home/tony/buildall/src/sys
--with-gmp=/home/tony/buildall/src/sys
Thread model: single
gcc version 4.4.4 (GCC)

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ1OxJJsSEodSM-fqTN791mW-UezqWjFLQBAS-4RbFHJkQ@mail.gmail.com> you wrote:
> 
> > Can you please tell me at least one board configuration that throws
> > this error (preferrably ppc, arm or mips) ?
> 
> I can't see one with those architectures. It does happen for others though:
...

Strange.  Both MIPS and PPC build without a single warning for me.

I cannot test avr32 or m68k here.

> > Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in
> > usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c"
> > patches?

None here.

I am tempted to blame your tool chain for the problems.

Is anybody else seing these warnings? With which tool chain versions?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you fail to plan, plan to fail.

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Simon Glass]

Hi Wolfgang,

On Fri, Jan 6, 2012 at 3:37 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ1OxJJsSEodSM-fqTN791mW-UezqWjFLQBAS-4RbFHJkQ@mail.gmail.com> you wrote:
>>
>> > Can you please tell me at least one board configuration that throws
>> > this error (preferrably ppc, arm or mips) ?
>>
>> I can't see one with those architectures. It does happen for others though:
> ...
>
> Strange. ?Both MIPS and PPC build without a single warning for me.
>
> I cannot test avr32 or m68k here.
>
>> > Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in
>> > usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c"
>> > patches?
>
> None here.
>
> I am tempted to blame your tool chain for the problems.

Could be - well you can download it for yourself if you want to try it.

http://dev.gentoo.org/~vapier/u-boot/

The warnings seems mostly reasonable (i.e. correct) to me, except for
the new USB alias one AFTER Marek's fix. That one I don't quite
understand.

>
> Is anybody else seing these warnings? With which tool chain versions?

Will wait to hear from people.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> If you fail to plan, plan to fail.

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Mike Frysinger]

On Friday 06 January 2012 15:39:08 Simon Glass wrote:
> On Thu, Jan 5, 2012 at 10:48 PM, Wolfgang Denk wrote:
> > Simon Glass wrote:
> >> This fixes the following warnings in dlmalloc seen with my gcc 4.6.
> > 
> > Which exact version is this?
> > 
> >> dlmalloc.c: In function 'malloc_bin_reloc':
> >> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break
> >> strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer
> >> 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized
> >> from here
> >> dlmalloc.c:1493: note: initialized from here
> > 
> > Can you please tell me at least one board configuration that throws
> > this error (preferrably ppc, arm or mips) ?
> 
> I can't see one with those architectures. It does happen for others though:

yes, there have been reports and patches posted in the past iirc.  first by 
Kumar i think.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120108/82c155ff/attachment.pgp>

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Andreas Bießmann]

Dear Simon Glass,

On 06.01.2012 04:54, Simon Glass wrote:
> This fixes the following warnings in dlmalloc seen with my gcc 4.6.
> 
> dlmalloc.c: In function 'malloc_bin_reloc':
> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
> dlmalloc.c:1490: note: initialized from here
> dlmalloc.c:1493: note: initialized from here

This is really annoying, but ...

> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  common/dlmalloc.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
> index c645d73..0a719b4 100644
> --- a/common/dlmalloc.c
> +++ b/common/dlmalloc.c
> @@ -1487,11 +1487,11 @@ static mbinptr av_[NAV * 2 + 2] = {
>  #ifdef CONFIG_NEEDS_MANUAL_RELOC
>  void malloc_bin_reloc (void)
>  {
> -	unsigned long *p = (unsigned long *)(&av_[2]);
> +	mbinptr *p = &av_[2];
>  	int i;
> -	for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) {
> -		*p++ += gd->reloc_off;
> -	}
> +
> +	for (i = 2; i < ARRAY_SIZE(av_); ++i)
> +		*p = (mbinptr)((ulong)*p + gd->reloc_off);

your patch breaks avr32 boards at runtime:

---8<---
U-Boot 2012.07-00134-g6073aab (Aug 13 2012 - 17:16:34)

U-Boot code: 00000000 -> 00013588  data: 0001ab70 -> 00050448
VMR table @ 0x107ca4bc
DMA: Using memory from 0x1076b000 to 0x1076f000
Flash: 8 MiB at address 0x00000000
DRAM Configuration:
Bank #0: 10000000 8 MiB

 *** Unhandled exception 24 at PC=0x107b442e [0000542e]
MMU exception at address 0x7af1ade4
   pc: 107b442e    lr: 0001b1c8    sp: 1076aecc   r12: 00000001
  r11: 00000000   r10: 00000079    r9: 107c9de8    r8: 107c9de0
   r7: 00010000    r6: 107ca9ac    r5: 1076af90    r4: 0000007e
   r3: 7af1ade0    r2: 107cb8f0    r1: 00000000    r0: 107cb908
Flags: qvnzc
Mode bits: hrje....g
CPU Mode: Supervisor
--->8---

A working solution is http://patchwork.ozlabs.org/patch/176885/

Would be great to remove this aliasing warning in 2012.10

Best regards

Andreas Bie?mann

[U-Boot] [PATCH 2/9] Fix strict-aliasing warning in dlmalloc

[Andreas Bießmann]

Dear Simon Glas,

On 13.08.2012 17:25, Andreas Bie?mann wrote:
> Dear Simon Glass,
>
> On 06.01.2012 04:54, Simon Glass wrote:
>> This fixes the following warnings in dlmalloc seen with my gcc 4.6.
>>
>> dlmalloc.c: In function 'malloc_bin_reloc':
>> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
>> dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules
>> dlmalloc.c:1490: note: initialized from here
>> dlmalloc.c:1493: note: initialized from here
>
> This is really annoying, but ...
>
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>   common/dlmalloc.c |    8 ++++----
>>   1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
>> index c645d73..0a719b4 100644
>> --- a/common/dlmalloc.c
>> +++ b/common/dlmalloc.c
>> @@ -1487,11 +1487,11 @@ static mbinptr av_[NAV * 2 + 2] = {
>>   #ifdef CONFIG_NEEDS_MANUAL_RELOC
>>   void malloc_bin_reloc (void)
>>   {
>> -	unsigned long *p = (unsigned long *)(&av_[2]);
>> +	mbinptr *p = &av_[2];
>>   	int i;
>> -	for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) {
>> -		*p++ += gd->reloc_off;
>> -	}
>> +
>> +	for (i = 2; i < ARRAY_SIZE(av_); ++i)
>> +		*p = (mbinptr)((ulong)*p + gd->reloc_off);
------------------^

Ouch ... isn't there something missing? Who increments the pointer? ;)

> your patch breaks avr32 boards at runtime:

Will send a new version which supersedes this one and 
http://patchwork.ozlabs.org/patch/176885/

Best regards

Andreas Bie?mann

[U-Boot] [PATCH 3/9] mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c

[Simon Glass]

This fixes warnings seen with my gcc 4.6.

usb_ohci.c: In function 'submit_control_msg':
usb_ohci.c:1041: warning: dereferencing pointer 'data_buf.70' does break
 strict-aliasing rules
usb_ohci.c:1041: note: initialized from here
usb_ohci.c:1043: warning: dereferencing pointer 'data_buf.70' does break
 strict-aliasing rules
usb_ohci.c:1043: note: initialized from here
usb_ohci.c:1045: warning: dereferencing pointer 'data_buf.70' does break
 strict-aliasing rules

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/powerpc/cpu/mpc5xxx/usb_ohci.c |   79 +++++++++++++++++++++--------------
 1 files changed, 47 insertions(+), 32 deletions(-)

diff --git a/arch/powerpc/cpu/mpc5xxx/usb_ohci.c b/arch/powerpc/cpu/mpc5xxx/usb_ohci.c
index d250c19..d78badc 100644
--- a/arch/powerpc/cpu/mpc5xxx/usb_ohci.c
+++ b/arch/powerpc/cpu/mpc5xxx/usb_ohci.c
@@ -1005,12 +1005,19 @@ static int ohci_submit_rh_msg(struct usb_device *dev, unsigned long pipe,
 	int len = 0;
 	int stat = 0;
 	__u32 datab[4];
-	__u8 *data_buf = (__u8 *)datab;
+	union {
+		void *ptr;
+		__u8 *u8;
+		__u16 *u16;
+		__u32 *u32;
+	} databuf;
 	__u16 bmRType_bReq;
 	__u16 wValue;
 	__u16 wIndex;
 	__u16 wLength;
 
+	databuf.u32 = (__u32 *)datab;
+
 #ifdef DEBUG
 urb_priv.actual_length = 0;
 pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
@@ -1038,17 +1045,21 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 	*/
 
 	case RH_GET_STATUS:
-			*(__u16 *) data_buf = m16_swap (1); OK (2);
+		databuf.u16[0] = m16_swap(1);
+		OK(2);
 	case RH_GET_STATUS | RH_INTERFACE:
-			*(__u16 *) data_buf = m16_swap (0); OK (2);
+		databuf.u16[0] = m16_swap(0);
+		OK(2);
 	case RH_GET_STATUS | RH_ENDPOINT:
-			*(__u16 *) data_buf = m16_swap (0); OK (2);
+		databuf.u16[0] = m16_swap(0);
+		OK(2);
 	case RH_GET_STATUS | RH_CLASS:
-			*(__u32 *) data_buf = m32_swap (
-				RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE));
-			OK (4);
+		databuf.u32[0] = m32_swap(
+			RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE));
+		OK(4);
 	case RH_GET_STATUS | RH_OTHER | RH_CLASS:
-			*(__u32 *) data_buf = m32_swap (RD_RH_PORTSTAT); OK (4);
+		databuf.u32[0] = m32_swap(RD_RH_PORTSTAT);
+		OK(4);
 
 	case RH_CLEAR_FEATURE | RH_ENDPOINT:
 		switch (wValue) {
@@ -1113,14 +1124,14 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 					  min_t(unsigned int,
 					      sizeof (root_hub_dev_des),
 					      wLength));
-				data_buf = root_hub_dev_des; OK(len);
+				databuf.ptr = root_hub_dev_des; OK(len);
 			case (0x02): /* configuration descriptor */
 				len = min_t(unsigned int,
 					  leni,
 					  min_t(unsigned int,
 					      sizeof (root_hub_config_des),
 					      wLength));
-				data_buf = root_hub_config_des; OK(len);
+				databuf.ptr = root_hub_config_des; OK(len);
 			case (0x03): /* string descriptors */
 				if(wValue==0x0300) {
 					len = min_t(unsigned int,
@@ -1128,7 +1139,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 						  min_t(unsigned int,
 						      sizeof (root_hub_str_index0),
 						      wLength));
-					data_buf = root_hub_str_index0;
+					databuf.ptr = root_hub_str_index0;
 					OK(len);
 				}
 				if(wValue==0x0301) {
@@ -1137,7 +1148,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 						  min_t(unsigned int,
 						      sizeof (root_hub_str_index1),
 						      wLength));
-					data_buf = root_hub_str_index1;
+					databuf.ptr = root_hub_str_index1;
 					OK(len);
 			}
 			default:
@@ -1149,38 +1160,42 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 	    {
 		    __u32 temp = roothub_a (&gohci);
 
-		    data_buf [0] = 9;		/* min length; */
-		    data_buf [1] = 0x29;
-		    data_buf [2] = temp & RH_A_NDP;
-		    data_buf [3] = 0;
+		    databuf.u8[0] = 9;		/* min length; */
+		    databuf.u8[1] = 0x29;
+		    databuf.u8[2] = temp & RH_A_NDP;
+		    databuf.u8[3] = 0;
 		    if (temp & RH_A_PSM)	/* per-port power switching? */
-			data_buf [3] |= 0x1;
+			databuf.u8[3] |= 0x1;
 		    if (temp & RH_A_NOCP)	/* no overcurrent reporting? */
-			data_buf [3] |= 0x10;
+			databuf.u8[3] |= 0x10;
 		    else if (temp & RH_A_OCPM)	/* per-port overcurrent reporting? */
-			data_buf [3] |= 0x8;
+			databuf.u8[3] |= 0x8;
 
 		    /* corresponds to data_buf[4-7] */
-		    datab [1] = 0;
-		    data_buf [5] = (temp & RH_A_POTPGT) >> 24;
+		    databuf.u32[1] = 0;
+		    databuf.u8[5] = (temp & RH_A_POTPGT) >> 24;
 		    temp = roothub_b (&gohci);
-		    data_buf [7] = temp & RH_B_DR;
-		    if (data_buf [2] < 7) {
-			data_buf [8] = 0xff;
+		    databuf.u8[7] = temp & RH_B_DR;
+		    if (databuf.u8[2] < 7) {
+			databuf.u8[8] = 0xff;
 		    } else {
-			data_buf [0] += 2;
-			data_buf [8] = (temp & RH_B_DR) >> 8;
-			data_buf [10] = data_buf [9] = 0xff;
+			databuf.u8[0] += 2;
+			databuf.u8[8] = (temp & RH_B_DR) >> 8;
+			databuf.u8[10] = databuf.u8[9] = 0xff;
 		    }
 
 		    len = min_t(unsigned int, leni,
-			      min_t(unsigned int, data_buf [0], wLength));
+			      min_t(unsigned int, databuf.u8[0], wLength));
 		    OK (len);
 		}
 
-	case RH_GET_CONFIGURATION:	*(__u8 *) data_buf = 0x01; OK (1);
+	case RH_GET_CONFIGURATION:
+		databuf.u8[0] = 0x01;
+		OK(1);
 
-	case RH_SET_CONFIGURATION:	WR_RH_STAT (0x10000); OK (0);
+	case RH_SET_CONFIGURATION:
+		WR_RH_STAT(0x10000);
+		OK(0);
 
 	default:
 		dbg ("unsupported root hub command");
@@ -1192,8 +1207,8 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 #endif
 
 	len = min_t(int, len, leni);
-	if (data != data_buf)
-	    memcpy (data, data_buf, len);
+	if (data != databuf.ptr)
+		memcpy(data, databuf.ptr, len);
 	dev->act_len = len;
 	dev->status = stat;
 
-- 
1.7.3.1

[U-Boot] [PATCH 4/9] ppc4xx: Fix strict-aliasing warnings in usb_ohci.c

[Simon Glass]

This fixes warnings seen with my gcc 4.6.

usb_ohci.c: In function 'submit_control_msg':
usb_ohci.c:1046: warning: dereferencing pointer 'data_buf.70' does break
strict-aliasing rules
usb_ohci.c:1046: note: initialized from here
usb_ohci.c:1048: warning: dereferencing pointer 'data_buf.70' does break
strict-aliasing rules
usb_ohci.c:1048: note: initialized from here
usb_ohci.c:1050: warning: dereferencing pointer 'data_buf.70' does break
strict-aliasing rules

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/powerpc/cpu/ppc4xx/usb_ohci.c |   81 +++++++++++++++++++++---------------
 1 files changed, 48 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/cpu/ppc4xx/usb_ohci.c b/arch/powerpc/cpu/ppc4xx/usb_ohci.c
index 4fb7031..57fa24f 100644
--- a/arch/powerpc/cpu/ppc4xx/usb_ohci.c
+++ b/arch/powerpc/cpu/ppc4xx/usb_ohci.c
@@ -1010,12 +1010,19 @@ static int ohci_submit_rh_msg(struct usb_device *dev, unsigned long pipe,
 	int len = 0;
 	int stat = 0;
 	__u32 datab[4];
-	__u8 *data_buf = (__u8 *)datab;
+	union {
+		void *ptr;
+		__u8 *u8;
+		__u16 *u16;
+		__u32 *u32;
+	} databuf;
 	__u16 bmRType_bReq;
 	__u16 wValue;
 	__u16 wIndex;
 	__u16 wLength;
 
+	databuf.u32 = (__u32 *)datab;
+
 #ifdef DEBUG
 urb_priv.actual_length = 0;
 pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
@@ -1043,17 +1050,21 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 	*/
 
 	case RH_GET_STATUS:
-			*(__u16 *) data_buf = m16_swap (1); OK (2);
+		databuf.u16[0] = m16_swap(1);
+		OK(2);
 	case RH_GET_STATUS | RH_INTERFACE:
-			*(__u16 *) data_buf = m16_swap (0); OK (2);
+		databuf.u16[0] = m16_swap(0);
+		OK(2);
 	case RH_GET_STATUS | RH_ENDPOINT:
-			*(__u16 *) data_buf = m16_swap (0); OK (2);
+		databuf.u16[0] = m16_swap(0);
+		OK(2);
 	case RH_GET_STATUS | RH_CLASS:
-			*(__u32 *) data_buf = m32_swap (
-				RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE));
-			OK (4);
+		databuf.u32[0] = m32_swap(
+			RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE));
+		OK(4);
 	case RH_GET_STATUS | RH_OTHER | RH_CLASS:
-			*(__u32 *) data_buf = m32_swap (RD_RH_PORTSTAT); OK (4);
+		databuf.u32[0] = m32_swap(RD_RH_PORTSTAT);
+		OK(4);
 
 	case RH_CLEAR_FEATURE | RH_ENDPOINT:
 		switch (wValue) {
@@ -1118,14 +1129,14 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 					  min_t(unsigned int,
 					      sizeof (root_hub_dev_des),
 					      wLength));
-				data_buf = root_hub_dev_des; OK(len);
+				databuf.ptr = root_hub_dev_des; OK(len);
 			case (0x02): /* configuration descriptor */
 				len = min_t(unsigned int,
 					  leni,
 					  min_t(unsigned int,
 					      sizeof (root_hub_config_des),
 					      wLength));
-				data_buf = root_hub_config_des; OK(len);
+				databuf.ptr = root_hub_config_des; OK(len);
 			case (0x03): /* string descriptors */
 				if(wValue==0x0300) {
 					len = min_t(unsigned int,
@@ -1133,7 +1144,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 						  min_t(unsigned int,
 						      sizeof (root_hub_str_index0),
 						      wLength));
-					data_buf = root_hub_str_index0;
+					databuf.ptr = root_hub_str_index0;
 					OK(len);
 				}
 				if(wValue==0x0301) {
@@ -1142,7 +1153,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 						  min_t(unsigned int,
 						      sizeof (root_hub_str_index1),
 						      wLength));
-					data_buf = root_hub_str_index1;
+					databuf.ptr = root_hub_str_index1;
 					OK(len);
 			}
 			default:
@@ -1154,38 +1165,42 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 	    {
 		    __u32 temp = roothub_a (&gohci);
 
-		    data_buf [0] = 9;		/* min length; */
-		    data_buf [1] = 0x29;
-		    data_buf [2] = temp & RH_A_NDP;
-		    data_buf [3] = 0;
+		    databuf.u8[0] = 9;		/* min length; */
+		    databuf.u8[1] = 0x29;
+		    databuf.u8[2] = temp & RH_A_NDP;
+		    databuf.u8[3] = 0;
 		    if (temp & RH_A_PSM)	/* per-port power switching? */
-			data_buf [3] |= 0x1;
+			databuf.u8[3] |= 0x1;
 		    if (temp & RH_A_NOCP)	/* no overcurrent reporting? */
-			data_buf [3] |= 0x10;
+			databuf.u8[3] |= 0x10;
 		    else if (temp & RH_A_OCPM)	/* per-port overcurrent reporting? */
-			data_buf [3] |= 0x8;
+			databuf.u8[3] |= 0x8;
 
 		    /* corresponds to data_buf[4-7] */
-		    datab [1] = 0;
-		    data_buf [5] = (temp & RH_A_POTPGT) >> 24;
+		    databuf.u32[1] = 0;
+		    databuf.u8[5] = (temp & RH_A_POTPGT) >> 24;
 		    temp = roothub_b (&gohci);
-		    data_buf [7] = temp & RH_B_DR;
-		    if (data_buf [2] < 7) {
-			data_buf [8] = 0xff;
+		    databuf.u8[7] = temp & RH_B_DR;
+		    if (databuf.u8[2] < 7) {
+			databuf.u8[8] = 0xff;
 		    } else {
-			data_buf [0] += 2;
-			data_buf [8] = (temp & RH_B_DR) >> 8;
-			data_buf [10] = data_buf [9] = 0xff;
+			databuf.u8[0] += 2;
+			databuf.u8[8] = (temp & RH_B_DR) >> 8;
+			databuf.u8[10] = databuf.u8[9] = 0xff;
 		    }
 
 		    len = min_t(unsigned int, leni,
-			      min_t(unsigned int, data_buf [0], wLength));
-		    OK (len);
+			      min_t(unsigned int, databuf.u8[0], wLength));
+		    OK(len);
 		}
 
-	case RH_GET_CONFIGURATION:	*(__u8 *) data_buf = 0x01; OK (1);
+	case RH_GET_CONFIGURATION:
+		databuf.u8[0] = 0x01;
+		OK(1);
 
-	case RH_SET_CONFIGURATION:	WR_RH_STAT (0x10000); OK (0);
+	case RH_SET_CONFIGURATION:
+		WR_RH_STAT(0x10000);
+		OK(0);
 
 	default:
 		dbg ("unsupported root hub command");
@@ -1197,8 +1212,8 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
 #endif
 
 	len = min_t(int, len, leni);
-	if (data != data_buf)
-	    memcpy (data, data_buf, len);
+	if (data != databuf.ptr)
+		memcpy(data, databuf.ptr, len);
 	dev->act_len = len;
 	dev->status = stat;
 
-- 
1.7.3.1

[U-Boot] [PATCH 4/9] ppc4xx: Fix strict-aliasing warnings in usb_ohci.c

[Marek Vasut]

Dear Simon Glass,

> This fixes warnings seen with my gcc 4.6.
> 
> usb_ohci.c: In function 'submit_control_msg':
> usb_ohci.c:1046: warning: dereferencing pointer 'data_buf.70' does break
> strict-aliasing rules
> usb_ohci.c:1046: note: initialized from here
> usb_ohci.c:1048: warning: dereferencing pointer 'data_buf.70' does break
> strict-aliasing rules
> usb_ohci.c:1048: note: initialized from here
> usb_ohci.c:1050: warning: dereferencing pointer 'data_buf.70' does break
> strict-aliasing rules
[...]

Are we still seeing these?

Best regards,
Marek Vasut

[U-Boot] [PATCH 4/9] ppc4xx: Fix strict-aliasing warnings in usb_ohci.c

[Simon Glass]

Hi Marek,

On Mon, Oct 15, 2012 at 11:28 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Simon Glass,
>
>> This fixes warnings seen with my gcc 4.6.
>>
>> usb_ohci.c: In function 'submit_control_msg':
>> usb_ohci.c:1046: warning: dereferencing pointer 'data_buf.70' does break
>> strict-aliasing rules
>> usb_ohci.c:1046: note: initialized from here
>> usb_ohci.c:1048: warning: dereferencing pointer 'data_buf.70' does break
>> strict-aliasing rules
>> usb_ohci.c:1048: note: initialized from here
>> usb_ohci.c:1050: warning: dereferencing pointer 'data_buf.70' does break
>> strict-aliasing rules
> [...]
>
> Are we still seeing these?

I see them with my compiler, but I might be in a minority of one here.
I am working on getting a new powerpc tool chain.

Regards,
Simon

>
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 5/9] sandbox: sort header files in os.c

[Simon Glass]

Tidy this up as the list is long and likely to get longer.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/sandbox/cpu/os.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 6d55b5c..700c1a7 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -19,16 +19,16 @@
  * MA 02111-1307 USA
  */
 
+#include <errno.h>
 #include <fcntl.h>
+#include <linux/types.h>
 #include <stdlib.h>
 #include <termios.h>
-#include <unistd.h>
 #include <time.h>
-#include <errno.h>
-#include <sys/types.h>
-#include <sys/stat.h>
+#include <unistd.h>
 #include <sys/mman.h>
-#include <linux/types.h>
+#include <sys/stat.h>
+#include <sys/types.h>
 
 #include <os.h>
 
-- 
1.7.3.1

[U-Boot] [PATCH 5/9] sandbox: sort header files in os.c

[Mike Frysinger]

On Thursday 05 January 2012 22:54:53 Simon Glass wrote:
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
> 
> +#include <errno.h>
>  #include <fcntl.h>
> +#include <linux/types.h>
>  #include <stdlib.h>
>  #include <termios.h>
> -#include <unistd.h>
>  #include <time.h>
> -#include <errno.h>
> -#include <sys/types.h>
> -#include <sys/stat.h>
> +#include <unistd.h>
>  #include <sys/mman.h>
> -#include <linux/types.h>
> +#include <sys/stat.h>
> +#include <sys/types.h>


the order should generally be:
	- stuff in include/
	- stuff in sys/
	- stuff in linux/
	- stuff in asm/
each sub-region can be sorted, but i don't think we should go against the 
subdir rule
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120108/f2fef496/attachment.pgp>

[U-Boot] [PATCH 5/9] sandbox: sort header files in os.c

[Simon Glass]

Hi Mike,

On Sun, Jan 8, 2012 at 12:49 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 05 January 2012 22:54:53 Simon Glass wrote:
>> --- a/arch/sandbox/cpu/os.c
>> +++ b/arch/sandbox/cpu/os.c
>>
>> +#include <errno.h>
>> ?#include <fcntl.h>
>> +#include <linux/types.h>
>> ?#include <stdlib.h>
>> ?#include <termios.h>
>> -#include <unistd.h>
>> ?#include <time.h>
>> -#include <errno.h>
>> -#include <sys/types.h>
>> -#include <sys/stat.h>
>> +#include <unistd.h>
>> ?#include <sys/mman.h>
>> -#include <linux/types.h>
>> +#include <sys/stat.h>
>> +#include <sys/types.h>
>
>
> the order should generally be:
> ? ? ? ?- stuff in include/
> ? ? ? ?- stuff in sys/
> ? ? ? ?- stuff in linux/
> ? ? ? ?- stuff in asm/
> each sub-region can be sorted, but i don't think we should go against the
> subdir rule

OK done, thanks.

Regards,
Simon

> -mike

[U-Boot] [PATCH 6/9] sandbox: Add required header to os.c

[Simon Glass]

We should include sys/time.h header to avoid warnings.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/sandbox/cpu/os.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 700c1a7..ebd0ff1 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -28,6 +28,7 @@
 #include <unistd.h>
 #include <sys/mman.h>
 #include <sys/stat.h>
+#include <sys/time.h>
 #include <sys/types.h>
 
 #include <os.h>
-- 
1.7.3.1

[U-Boot] [PATCH 6/9] sandbox: Add required header to os.c

[Mike Frysinger]

On Thursday 05 January 2012 22:54:54 Simon Glass wrote:
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
>
>  #include <unistd.h>
>  #include <sys/mman.h>
>  #include <sys/stat.h>
> +#include <sys/time.h>
>  #include <sys/types.h>
> 
>  #include <os.h>

guess this will need a rebase once 5/9 is rewritten
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120108/5a23172a/attachment.pgp>

[U-Boot] [PATCH 6/9] sandbox: Add required header to os.c

[Simon Glass]

Hi Mike,

On Sun, Jan 8, 2012 at 12:49 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 05 January 2012 22:54:54 Simon Glass wrote:
>> --- a/arch/sandbox/cpu/os.c
>> +++ b/arch/sandbox/cpu/os.c
>>
>> ?#include <unistd.h>
>> ?#include <sys/mman.h>
>> ?#include <sys/stat.h>
>> +#include <sys/time.h>
>> ?#include <sys/types.h>
>>
>> ?#include <os.h>
>
> guess this will need a rebase once 5/9 is rewritten

Yes that right, will resubmit.

Regards,
Simon

> -mike

[U-Boot] [PATCH 7/9] Remove CONFIG_SYS_EXTBDINFO from snapper9260.h

[Simon Glass]

This feature is not available on ARM, so it is an error to define it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/configs/snapper9260.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/configs/snapper9260.h b/include/configs/snapper9260.h
index cb3c674..cee65d1 100644
--- a/include/configs/snapper9260.h
+++ b/include/configs/snapper9260.h
@@ -157,7 +157,6 @@
 #define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE +		\
 					 sizeof(CONFIG_SYS_PROMPT) + 16)
 #define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_EXTBDINFO
 #define CONFIG_CMDLINE_EDITING
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_SYS_HUSH_PARSER
-- 
1.7.3.1

[U-Boot] [PATCH 7/9] Remove CONFIG_SYS_EXTBDINFO from snapper9260.h

[Stefano Babic]

On 06/01/2012 04:54, Simon Glass wrote:
> This feature is not available on ARM, so it is an error to define it.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  include/configs/snapper9260.h |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/include/configs/snapper9260.h b/include/configs/snapper9260.h
> index cb3c674..cee65d1 100644
> --- a/include/configs/snapper9260.h
> +++ b/include/configs/snapper9260.h
> @@ -157,7 +157,6 @@
>  #define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE +		\
>  					 sizeof(CONFIG_SYS_PROMPT) + 16)
>  #define CONFIG_SYS_LONGHELP
> -#define CONFIG_SYS_EXTBDINFO
>  #define CONFIG_CMDLINE_EDITING
>  #define CONFIG_AUTO_COMPLETE
>  #define CONFIG_SYS_HUSH_PARSER

Acked-by: Stefano Babic <sbabic@denx.de>

Best regards,
Stefano Babic


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 7/9] Remove CONFIG_SYS_EXTBDINFO from snapper9260.h

[Anatolij Gustschin]

On Thu,  5 Jan 2012 19:54:55 -0800
Simon Glass <sjg@chromium.org> wrote:

> This feature is not available on ARM, so it is an error to define it.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  include/configs/snapper9260.h |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)

Applied to u-boot-staging/agust at denx.de, thanks!

Anatolij

[U-Boot] [PATCH 8/9] m68k: Change memsz to a signed char to avoid warning

[Simon Glass]

There doesn't seem to be any reason for using uchar here, so change it
to char. This fixes a warning:

pointer targets in passing argument 1 of 'sprintf' differ in signedness

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/m68k/lib/board.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/m68k/lib/board.c b/arch/m68k/lib/board.c
index 259b71c..1526967 100644
--- a/arch/m68k/lib/board.c
+++ b/arch/m68k/lib/board.c
@@ -639,7 +639,7 @@ void board_init_r (gd_t *id, ulong dest_addr)
 	 */
 	{
 		ulong pram = 0;
-		uchar memsz[32];
+		char memsz[32];
 
 #ifdef CONFIG_PRAM
 		pram = getenv_ulong("pram", 10, CONFIG_PRAM);
-- 
1.7.3.1

[U-Boot] [PATCH 8/9] m68k: Change memsz to a signed char to avoid warning

[Mike Frysinger]

Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120108/99291001/attachment.pgp>

[U-Boot] [PATCH 8/9] m68k: Change memsz to a signed char to avoid warning

[Stefano Babic]

On 06/01/2012 04:54, Simon Glass wrote:
> There doesn't seem to be any reason for using uchar here, so change it
> to char. This fixes a warning:
> 
> pointer targets in passing argument 1 of 'sprintf' differ in signedness
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---

Applied to u-boot-staging, sbabic at denx.de branch, thanks.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 9/9] ppc: Change memsz variable to signed char

[Simon Glass]

This seems to be unsigned char for no good reason. Tidy this up and
remove the casts.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/powerpc/lib/board.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index ff5888e..3f9af1d 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -1021,7 +1021,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	 */
 	{
 		ulong pram = 0;
-		uchar memsz[32];
+		char memsz[32];
 
 #ifdef CONFIG_PRAM
 		pram = getenv_ulong("pram", 10, CONFIG_PRAM);
@@ -1032,9 +1032,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
 		pram += (LOGBUFF_LEN + LOGBUFF_OVERHEAD) / 1024;
 #endif
 #endif
-		sprintf((char *) memsz, "%ldk",
-			(bd->bi_memsize / 1024) - pram);
-		setenv("mem", (char *) memsz);
+		sprintf(memsz, "%ldk", (bd->bi_memsize / 1024) - pram);
+		setenv("mem", memsz);
 	}
 #endif
 
-- 
1.7.3.1

[U-Boot] [PATCH 9/9] ppc: Change memsz variable to signed char

[Mike Frysinger]

Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120108/a116464c/attachment.pgp>

[U-Boot] [PATCH 9/9] ppc: Change memsz variable to signed char

[Stefano Babic]

On 06/01/2012 04:54, Simon Glass wrote:
> This seems to be unsigned char for no good reason. Tidy this up and
> remove the casts.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---

Applied to u-boot-staging, sbabic at denx.de branch, thanks.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Wolfgang Denk]

Dear Simon Glass,

In message <1325822097-15227-1-git-send-email-sjg@chromium.org> you wrote:
> This series fixes some warnings which seem to still be left over from
> all the warning-squashing efforts for 2011.12. If patches exist for some
> of these already then please ignore.
> 
> The alias problem in USB is a bit odd, since I thought it was already
> fixed. But perhaps it has come back.

Can you please let me know which tool chain is throwing these errors?
I built "master" yesterday, and before adding the commit that
introduced the ``"_LINUX_CONFIG_H" redefined'' issue the PPC tree was
built clean - with ELDK 4.2 (gcc 4.2.2), ELDK 5.1 (gcc 4.6.1) and with
ELDK 5.2 (gcc 4.6.3).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Simon Glass]

Hi Wolfgang,

On Thu, Jan 5, 2012 at 10:20 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1325822097-15227-1-git-send-email-sjg@chromium.org> you wrote:
>> This series fixes some warnings which seem to still be left over from
>> all the warning-squashing efforts for 2011.12. If patches exist for some
>> of these already then please ignore.
>>
>> The alias problem in USB is a bit odd, since I thought it was already
>> fixed. But perhaps it has come back.
>
> Can you please let me know which tool chain is throwing these errors?
> I built "master" yesterday, and before adding the commit that
> introduced the ``"_LINUX_CONFIG_H" redefined'' issue the PPC tree was
> built clean - with ELDK 4.2 (gcc 4.2.2), ELDK 5.1 (gcc 4.6.1) and with
> ELDK 5.2 (gcc 4.6.3).

I just check that - actually my PowerPC one is v4.4.4:

Using built-in specs.
Target: powerpc-linux
Configured with: /home/tony/buildall/src/gcc/configure
--target=powerpc-linux --enable-targets=all
--prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/
--enable-languages=c --with-newlib --without-headers
--enable-sjlj-exceptions --with-system-libunwind --disable-nls
--disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--enable-checking=release --with-mpfr=/home/tony/buildall/src/sys
--with-gmp=/home/tony/buildall/src/sys
Thread model: single
gcc version 4.4.4 (GCC)

I got this from Mike F (from the Gentoo site).

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Documentation is like sex: when it is good, it is ?very, ?very ?good;
> and when it is bad, it is better than nothing. ? ? ? ? - Dick Brandon

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Simon Glass]

Hi Wolfgang / Stefano,

On Thu, Jan 5, 2012 at 10:28 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Wolfgang,
>
> On Thu, Jan 5, 2012 at 10:20 PM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Simon Glass,
>>
>> In message <1325822097-15227-1-git-send-email-sjg@chromium.org> you wrote:
>>> This series fixes some warnings which seem to still be left over from
>>> all the warning-squashing efforts for 2011.12. If patches exist for some
>>> of these already then please ignore.
>>>
>>> The alias problem in USB is a bit odd, since I thought it was already
>>> fixed. But perhaps it has come back.
>>
>> Can you please let me know which tool chain is throwing these errors?
>> I built "master" yesterday, and before adding the commit that
>> introduced the ``"_LINUX_CONFIG_H" redefined'' issue the PPC tree was
>> built clean - with ELDK 4.2 (gcc 4.2.2), ELDK 5.1 (gcc 4.6.1) and with
>> ELDK 5.2 (gcc 4.6.3).
>
> I just check that - actually my PowerPC one is v4.4.4:
>
> Using built-in specs.
> Target: powerpc-linux
> Configured with: /home/tony/buildall/src/gcc/configure
> --target=powerpc-linux --enable-targets=all
> --prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/
> --enable-languages=c --with-newlib --without-headers
> --enable-sjlj-exceptions --with-system-libunwind --disable-nls
> --disable-threads --disable-shared --disable-libmudflap
> --disable-libssp --disable-libgomp --disable-decimal-float
> --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys
> --with-gmp=/home/tony/buildall/src/sys
> Thread model: single
> gcc version 4.4.4 (GCC)
>
> I got this from Mike F (from the Gentoo site).
>

What should we do about this series? I still see these warnings with
the toolchains I use [1]. Does anyone else?

Regards,
Simon

[1] http://dev.gentoo.org/~vapier/u-boot/

> Regards,
> Simon
>
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --
>> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>> Documentation is like sex: when it is good, it is ?very, ?very ?good;
>> and when it is bad, it is better than nothing. ? ? ? ? - Dick Brandon

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Stefano Babic]

On 20/02/2012 19:49, Simon Glass wrote:
> Hi Wolfgang / Stefano,
> 

Hi Simon,

>> I just check that - actually my PowerPC one is v4.4.4:
>>
>> Using built-in specs.
>> Target: powerpc-linux
>> Configured with: /home/tony/buildall/src/gcc/configure
>> --target=powerpc-linux --enable-targets=all
>> --prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/
>> --enable-languages=c --with-newlib --without-headers
>> --enable-sjlj-exceptions --with-system-libunwind --disable-nls
>> --disable-threads --disable-shared --disable-libmudflap
>> --disable-libssp --disable-libgomp --disable-decimal-float
>> --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys
>> --with-gmp=/home/tony/buildall/src/sys
>> Thread model: single
>> gcc version 4.4.4 (GCC)
>>
>> I got this from Mike F (from the Gentoo site).
>>
> 
> What should we do about this series? I still see these warnings with
> the toolchains I use [1]. Does anyone else?

I read the whole thread, and it seems that it is not clear if the
warnings are real or must be related to the used toolchain.

I will try myself with mips, as this is one of the architectures
reporting warnings.

However, current toolchains based on more restrictive compilers
(I mean, GCC >= 4.6) seem to be happy with the code. At least a couple
of patches reassembles code that seems correct...

IMHO if the code cannot be built with an older toolchain we can try to
fix, and also we must drop warnings with newer and current toolchains (a
lot of patches fixed gcc 4.6 warnings). I am aware that we cannot
support every toolchain, even if we try to do it. And maybe (only my
opinion) it is acceptable to have some warnings with older toolchains.

So tendentially my vote is not to take these patches, but Wolfgang has
the last word on them.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Stefano Babic]

On 21/02/2012 11:20, Stefano Babic wrote:

> 
> I will try myself with mips, as this is one of the architectures
> reporting warnings.

Just to report this: a "MAKEALL mips" reports no warning with a ggc 4.6
compiler : gcc version 4.6.1 20110627 (prerelease) (GCC)

It seems to me that the warnings are more related to the selected toolchain.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Mike Frysinger]

On Tuesday 21 February 2012 05:20:47 Stefano Babic wrote:
> I will try myself with mips, as this is one of the architectures
> reporting warnings.

i don't think Simon did say that mips was throwing these warnings, so testing 
that arch and looking for these warnings won't help
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120221/fc9a41dd/attachment.pgp>

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Stefano Babic]

On 21/02/2012 18:06, Mike Frysinger wrote:
> On Tuesday 21 February 2012 05:20:47 Stefano Babic wrote:
>> I will try myself with mips, as this is one of the architectures 
>> reporting warnings.
> 
> i don't think Simon did say that mips was throwing these warnings,
> so testing that arch and looking for these warnings won't help

In the thread I read that Simon got warnings with both mips and
powerpc, as well as with avr32 and m68k. But mips and powerpc are free
of warnings when I build with gcc 4.6.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Simon Glass]

Hi Stefano,

On Tue, Feb 21, 2012 at 9:15 AM, Stefano Babic <sbabic@denx.de> wrote:
> On 21/02/2012 18:06, Mike Frysinger wrote:
>> On Tuesday 21 February 2012 05:20:47 Stefano Babic wrote:
>>> I will try myself with mips, as this is one of the architectures
>>> reporting warnings.
>>
>> i don't think Simon did say that mips was throwing these warnings,
>> so testing that arch and looking for these warnings won't help

Part of the problem is that I mislabeled the commits, claiming that I
was using a 4.6 compiler when in fact mostly it was 4.4.4.
>
> In the thread I read that Simon got warnings with both mips and
> powerpc, as well as with avr32 and m68k. But mips and powerpc are free
> of warnings when I build with gcc 4.6.

Yes but not just those. There are detailed notes with each patch, but
here is a summary. I think 6 out of 9 patches should be applied
regardless of toolchain.

68k only:
 arch/m68k/lib/board.c               |    2 +-
- I believe this fix is sensible for the reasons described in the
patch, regardless of what the toolchain does.

PPC only:
 arch/powerpc/cpu/mpc5xxx/usb_ohci.c |   79 ++++++++++++++++++++--------------
 arch/powerpc/cpu/ppc4xx/usb_ohci.c  |   81 ++++++++++++++++++++--------------
- These two seem not to happen with a later toolchain. Please skip
these if you like.

 arch/powerpc/lib/board.c            |    7 +--
- Similar to the68k patch, again I think it makes sense to apply this.
The variable is unsigned char for no good reason.

Sandbox:
 arch/sandbox/cpu/os.c               |   11 +++--
- This should be applied as it is not toolchain dependent (Mike may
have picked it up already)

 common/dlmalloc.c                   |    8 ++--
- These happen with MIPS, AVR, 68k for me (with Mike's toolchains).
Does not happen on 4.6 ARM.

ARM and PPC:
 drivers/usb/host/ohci-hcd.c         |   26 ++++++------
- These happen with my 4.4.4 compiler, apparently not on 4.6. Drop
them if you like.

ARM:
 include/configs/snapper9260.h       |    1 -
- This fixes a real problem regardless of toolchain.

Regards,
Simon

>
> Stefano
>
> --
> =====================================================================
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 ?Email: office at denx.de
> =====================================================================

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Mike Frysinger]

On Tuesday 21 February 2012 13:40:36 Simon Glass wrote:
> 68k only:
>  arch/m68k/lib/board.c               |    2 +-
> - I believe this fix is sensible for the reasons described in the
> patch, regardless of what the toolchain does.
> 
>  arch/powerpc/lib/board.c            |    7 +--
> - Similar to the68k patch, again I think it makes sense to apply this.
> The variable is unsigned char for no good reason.

i agree

> Sandbox:
>  arch/sandbox/cpu/os.c               |   11 +++--
> - This should be applied as it is not toolchain dependent (Mike may
> have picked it up already)

i have

>  common/dlmalloc.c                   |    8 ++--
> - These happen with MIPS, AVR, 68k for me (with Mike's toolchains).

what boards ?  i tried a bunch of m68k ones and aren't seeing it ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120222/700b0fde/attachment.pgp>

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Stefano Babic]

On 21/02/2012 19:40, Simon Glass wrote:

> Yes but not just those. There are detailed notes with each patch, but
> here is a summary. I think 6 out of 9 patches should be applied
> regardless of toolchain.
> 
> 68k only:
>  arch/m68k/lib/board.c               |    2 +-
> - I believe this fix is sensible for the reasons described in the
> patch, regardless of what the toolchain does.

Agree - I will send my ACK and merge it into my u-boot-staging

>  arch/powerpc/lib/board.c            |    7 +--
> - Similar to the68k patch, again I think it makes sense to apply this.
> The variable is unsigned char for no good reason.

Agree, there is no reason. I will merge also this one into u-boot-staging.

> 
> Sandbox:
>  arch/sandbox/cpu/os.c               |   11 +++--
> - This should be applied as it is not toolchain dependent (Mike may
> have picked it up already)

Ok, the patch has already found its way to mainline

> 
> ARM and PPC:
>  drivers/usb/host/ohci-hcd.c         |   26 ++++++------
> - These happen with my 4.4.4 compiler, apparently not on 4.6. Drop
> them if you like.
> 
> ARM:
>  include/configs/snapper9260.h       |    1 -
> - This fixes a real problem regardless of toolchain.

Right. I will send my ACK with CC to Albert. He can pick-up it directly
into u-boot-arm.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ0Mb=LJBE3JSs0zOqivHY5pRfYNGpS3vnfs6O=SQXu9vQ@mail.gmail.com> you wrote:
> 
> Yes but not just those. There are detailed notes with each patch, but
> here is a summary. I think 6 out of 9 patches should be applied
> regardless of toolchain.

Then please re-test these and re-submit them, clearly indicating which
errors / warnings these are supposed to fix.

> PPC only:
>  arch/powerpc/cpu/mpc5xxx/usb_ohci.c |   79 ++++++++++++++++++++-----------=
> ---
>  arch/powerpc/cpu/ppc4xx/usb_ohci.c  |   81 ++++++++++++++++++++-----------=
> ---
> - These two seem not to happen with a later toolchain. Please skip
> these if you like.

They also seem not to happen with older tool chains (like GCC 4.2.2).

>  common/dlmalloc.c                   |    8 ++--
> - These happen with MIPS, AVR, 68k for me (with Mike's toolchains).
> Does not happen on 4.6 ARM.

Not seen with GCC 4.2.2 nor with GCC 4.6.

> ARM and PPC:
>  drivers/usb/host/ohci-hcd.c         |   26 ++++++------
> - These happen with my 4.4.4 compiler, apparently not on 4.6. Drop
> them if you like.

Not seen with GCC 4.2.2 nor with GCC 4.6.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The optimum committee has no members.
                                                   - Norman Augustine

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Marek Vasut]

Dear Simon Glass,

> This series fixes some warnings which seem to still be left over from
> all the warning-squashing efforts for 2011.12. If patches exist for some
> of these already then please ignore.
> 
> The alias problem in USB is a bit odd, since I thought it was already
> fixed. But perhaps it has come back.
> 
> 
> Simon Glass (9):
>   usb: Fix strict-aliasing warning in host/ohci-hcd.c
>   Fix strict-aliasing warning in dlmalloc
>   mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c
>   ppc4xx: Fix strict-aliasing warnings in usb_ohci.c
>   sandbox: sort header files in os.c
>   sandbox: Add required header to os.c
>   Remove CONFIG_SYS_EXTBDINFO from snapper9260.h
>   m68k: Change memsz to a signed char to avoid warning
>   ppc: Change memsz variable to signed char
> 
>  arch/m68k/lib/board.c               |    2 +-
>  arch/powerpc/cpu/mpc5xxx/usb_ohci.c |   79
> ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c  |  
> 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c           
> |    7 +--
>  arch/sandbox/cpu/os.c               |   11 +++--
>  common/dlmalloc.c                   |    8 ++--
>  drivers/usb/host/ohci-hcd.c         |   26 ++++++------
>  include/configs/snapper9260.h       |    1 -
>  8 files changed, 122 insertions(+), 93 deletions(-)

Can you please split out the USB part and send it to me (I became new usb 
maint.) please?

Thanks in advance!

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Simon Glass]

Hi Marek,

On Mon, Mar 5, 2012 at 10:22 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Simon Glass,
>
>> This series fixes some warnings which seem to still be left over from
>> all the warning-squashing efforts for 2011.12. If patches exist for some
>> of these already then please ignore.
>>
>> The alias problem in USB is a bit odd, since I thought it was already
>> fixed. But perhaps it has come back.
>>
>>
>> Simon Glass (9):
>> ? usb: Fix strict-aliasing warning in host/ohci-hcd.c
>> ? Fix strict-aliasing warning in dlmalloc
>> ? mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c
>> ? ppc4xx: Fix strict-aliasing warnings in usb_ohci.c
>> ? sandbox: sort header files in os.c
>> ? sandbox: Add required header to os.c
>> ? Remove CONFIG_SYS_EXTBDINFO from snapper9260.h
>> ? m68k: Change memsz to a signed char to avoid warning
>> ? ppc: Change memsz variable to signed char
>>
>> ?arch/m68k/lib/board.c ? ? ? ? ? ? ? | ? ?2 +-
>> ?arch/powerpc/cpu/mpc5xxx/usb_ohci.c | ? 79
>> ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c ?|
>> 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c
>> | ? ?7 +--
>> ?arch/sandbox/cpu/os.c ? ? ? ? ? ? ? | ? 11 +++--
>> ?common/dlmalloc.c ? ? ? ? ? ? ? ? ? | ? ?8 ++--
>> ?drivers/usb/host/ohci-hcd.c ? ? ? ? | ? 26 ++++++------
>> ?include/configs/snapper9260.h ? ? ? | ? ?1 -
>> ?8 files changed, 122 insertions(+), 93 deletions(-)
>
> Can you please split out the USB part and send it to me (I became new usb
> maint.) please?
>
> Thanks in advance!

Of course - I think you want to look at this one:

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

The two PowerPC ones apparently only happen with the 4.4 toolchain, so
I think we are going to drop those and I am going to upgrade my
toolchain instead :-)

Regards,
Simon

>
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Andy Pont]

Hi Simon,

<snip>

> >> ?arch/powerpc/cpu/mpc5xxx/usb_ohci.c | ? 79
> >> ++++++++++++++++++++--------------
> arch/powerpc/cpu/ppc4xx/usb_ohci.c ?|
> >> 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c

<snip>

> The two PowerPC ones apparently only happen with the 4.4 toolchain, so
> I think we are going to drop those and I am going to upgrade my
> toolchain instead :-)

This has just grabbed my attention with the comment regarding the 4.4
toolchain as I know that MontaVista ship a version of the 4.4.0 toolchain
for PowerPC with one of their embedded Linux products.  Is there a generic
issue with 4.4.x versions or just a rogue board or two?

Regards,

Andy.

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Wolfgang Denk]

Dear "Andy Pont",

In message <00e201ccfaff$bbc8b840$335a28c0$@pont@sdcsystems.com> you wrote:
> 
> This has just grabbed my attention with the comment regarding the 4.4
> toolchain as I know that MontaVista ship a version of the 4.4.0 toolchain
> for PowerPC with one of their embedded Linux products.  Is there a generic
> issue with 4.4.x versions or just a rogue board or two?

The problem appears to pop up only for some boards, but that means I
would not trust this tool chain at all.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon

[U-Boot] [PATCH 0/9] Fix a few warnings that bug me

[Marek Vasut]

Dear Simon Glass,

> Hi Marek,
> 
> On Mon, Mar 5, 2012 at 10:22 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Simon Glass,
> > 
> >> This series fixes some warnings which seem to still be left over from
> >> all the warning-squashing efforts for 2011.12. If patches exist for some
> >> of these already then please ignore.
> >> 
> >> The alias problem in USB is a bit odd, since I thought it was already
> >> fixed. But perhaps it has come back.
> >> 
> >> 
> >> Simon Glass (9):
> >>   usb: Fix strict-aliasing warning in host/ohci-hcd.c
> >>   Fix strict-aliasing warning in dlmalloc
> >>   mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c
> >>   ppc4xx: Fix strict-aliasing warnings in usb_ohci.c
> >>   sandbox: sort header files in os.c
> >>   sandbox: Add required header to os.c
> >>   Remove CONFIG_SYS_EXTBDINFO from snapper9260.h
> >>   m68k: Change memsz to a signed char to avoid warning
> >>   ppc: Change memsz variable to signed char
> >> 
> >>  arch/m68k/lib/board.c               |    2 +-
> >>  arch/powerpc/cpu/mpc5xxx/usb_ohci.c |   79
> >> ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c  |
> >> 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c
> >> 
> >> |    7 +--
> >> 
> >>  arch/sandbox/cpu/os.c               |   11 +++--
> >>  common/dlmalloc.c                   |    8 ++--
> >>  drivers/usb/host/ohci-hcd.c         |   26 ++++++------
> >>  include/configs/snapper9260.h       |    1 -
> >>  8 files changed, 122 insertions(+), 93 deletions(-)
> > 
> > Can you please split out the USB part and send it to me (I became new usb
> > maint.) please?
> > 
> > Thanks in advance!
> 
> Of course - I think you want to look at this one:
> 
> http://patchwork.ozlabs.org/patch/134600/
> 
> The two PowerPC ones apparently only happen with the 4.4 toolchain, so
> I think we are going to drop those and I am going to upgrade my
> toolchain instead :-)
> 

Can you actually paste the MAKEALL output for those boards where you observe the 
issue please?

I took a look at that patch and I'm not yet completely convinced by the memcpy 
business there. Also, I don't want to pick patches from the middle of a 
patchset, so can you please resend what you consider eligible?

Thanks!

Best regards,
Marek Vasut