[U-Boot] [Patch v2 08/16] net/fm: fix compile warnings for 64-bit platform

[Hou Zhiqiang]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: 2015年9月25日 10:34
> To: Hou Zhiqiang-B48286
> Cc: Gong Qianyu-B52263; u-boot at lists.denx.de; Hu Mingkai-B21284; Sun
> York-R58495; Song Wenbin-B53747; Xie Shaohui-B21989
> Subject: Re: [Patch v2 08/16] net/fm: fix compile warnings for 64-bit
> platform
> 
> On Thu, 2015-09-24 at 21:22 -0500, Hou Zhiqiang-B48286 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: 2015年9月18日 2:14
> > > To: Gong Qianyu-B52263
> > > Cc: u-boot at lists.denx.de; Hu Mingkai-B21284; Sun York-R58495; Hou
> > > Zhiqiang-B48286; Song Wenbin-B53747; Xie Shaohui-B21989; Wood Scott-
> > > B07421
> > > Subject: Re: [Patch v2 08/16] net/fm: fix compile warnings for
> > > 64-bit platform
> > >
> > > On Thu, 2015-09-17 at 15:06 +0800, Gong Qianyu wrote:
> > > > This patch fixes such compile warnings:
> > > >
> > > > drivers/net/fm/eth.c: In function 'fm_eth_recv':
> > > > drivers/net/fm/eth.c:549:11: warning: cast to pointer from integer
> > > > of different size [-Wint-to-pointer-cast]
> > > >       data = (u8 *)in_be32(&rxbd->buf_ptr_lo);
> > > > drivers/net/fm/fm.c: In function 'fm_muram_alloc':
> > > > drivers/net/fm/fm.c:52:9: warning: cast to pointer from integer of
> > > > different size [-Wint-to-pointer-cast]
> > > >       memset((void *)ret, 0, size);
> > > > drivers/net/fm/fm.c: In function 'fm_init_muram':
> > > > drivers/net/fm/fm.c:59:13: warning: cast from pointer to integer
> > > > of different size [-Wpointer-to-int-cast]
> > > >       u32 base = (u32)reg;
> > > >
> > > > Just make the cast explicit for them.
> > > >
> > > > Signed-off-by: Gong Qianyu <Qianyu.Gong at freescale.com>
> > > > ---
> > > >  drivers/net/fm/eth.c | 31 ++++++++++++++++---------------
> > > > drivers/net/fm/fm.c  |  4 ++--
> > > >  2 files changed, 18 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index
> > > > 12eb9b8..6ef0afb 100644
> > > > --- a/drivers/net/fm/eth.c
> > > > +++ b/drivers/net/fm/eth.c
> > > > @@ -120,12 +120,12 @@ static int tgec_is_fibre(struct eth_device
> > > > *dev)
> > > >
> > > >  static u16 muram_readw(u16 *addr)  {
> > > > -     u32 base = (u32)addr & ~0x3;
> > > > +     ulong base = (ulong)addr & ~0x3;
> > >
> > > This will still truncate the address at 32 bits.  It needs to be
> ~0x3UL.
> > >
> > >
> > > >       u32 val32 = in_be32((u32 *)base);
> > > >       int byte_pos;
> > > >       u16 ret;
> > > >
> > > > -     byte_pos = (u32)addr & 0x3;
> > > > +     byte_pos = (ulong)addr & 0x3;
> > > >       if (byte_pos)
> > > >               ret = (u16)(val32 & 0x0000ffff);
> > > >       else
> > > > @@ -136,12 +136,12 @@ static u16 muram_readw(u16 *addr)
> > > >
> > > >  static void muram_writew(u16 *addr, u16 val)  {
> > > > -     u32 base = (u32)addr & ~0x3;
> > > > +     ulong base = (ulong)addr & ~0x3;
> > > >       u32 org32 = in_be32((u32 *)base);
> > > >       u32 val32;
> > > >       int byte_pos;
> > > >
> > > > -     byte_pos = (u32)addr & 0x3;
> > > > +     byte_pos = (ulong)addr & 0x3;
> > > >       if (byte_pos)
> > > >               val32 = (org32 & 0xffff0000) | val;
> > > >       else
> > > > @@ -217,12 +217,12 @@ static int
> > > > fm_eth_rx_port_parameter_init(struct
> > > > fm_eth *fm_eth)
> > > >       int i;
> > > >
> > > >       /* alloc global parameter ram at MURAM */
> > > > -     pram = (struct fm_port_global_pram *)fm_muram_alloc(fm_eth-
> > > > fm_index,
> > > > -             FM_PRAM_SIZE, FM_PRAM_ALIGN);
> > > > +     pram = (struct fm_port_global_pram *)(ulong)fm_muram_alloc(
> > > > +                     fm_eth->fm_index, FM_PRAM_SIZE,
> > > > + FM_PRAM_ALIGN);
> > >
> > > Make fm_muram_alloc() return a pointer instead.  If muram were >= 4
> > > GiB the above would fail.
> > >
> >
> > The muram is a region included in CCSR.
> > So does we take muram >= 4GiB into account make sense?
> 
> The fact that currently, we run U-Boot as 32-bit on platforms where CCSR
> is
> >= 4GiB is not a good excuse to be sloppy with types.
> 

ok.

Thanks,
Zhiqiang