netdev - RE: [PATCH net-next 2/3] drivers: net: xilinx_emaclite: Fix -Wpointer-to-int-cast warnings with W=1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR02MB56388293FE47BE39604EB115C7100@BYAPR02MB5638.namprd02.prod.outlook.com>
Date:   Mon, 2 Nov 2020 07:31:16 +0000
From:   Radhey Shyam Pandey <radheys@...inx.com>
To:     Michal Simek <michals@...inx.com>, Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <kuba@...nel.org>
CC:     netdev <netdev@...r.kernel.org>, Michal Simek <michals@...inx.com>
Subject: RE: [PATCH net-next 2/3] drivers: net: xilinx_emaclite: Fix
 -Wpointer-to-int-cast warnings with W=1

> -----Original Message-----
> From: Michal Simek <michal.simek@...inx.com>
> Sent: Monday, November 2, 2020 12:51 PM
> To: Andrew Lunn <andrew@...n.ch>; Jakub Kicinski <kuba@...nel.org>
> Cc: netdev <netdev@...r.kernel.org>; Michal Simek <michals@...inx.com>;
> Radhey Shyam Pandey <radheys@...inx.com>
> Subject: Re: [PATCH net-next 2/3] drivers: net: xilinx_emaclite: Fix -Wpointer-
> to-int-cast warnings with W=1
> 
> 
> 
> On 31. 10. 20 18:47, Andrew Lunn wrote:
> > drivers/net/ethernet//xilinx/xilinx_emaclite.c:341:35: warning: cast from
> pointer to integer of different size [-Wpointer-to-int-cast]
> >   341 |   addr = (void __iomem __force *)((u32 __force)addr ^
> >
> > Use long instead of u32 to avoid problems on 64 bit systems.
> >
> > Signed-off-by: Andrew Lunn <andrew@...n.ch>
> > ---
> >  drivers/net/ethernet/xilinx/xilinx_emaclite.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> > b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> > index 2c98e4cc07a5..f56c1fd01061 100644
> > --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> > +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> > @@ -97,7 +97,7 @@
> >  #define ALIGNMENT		4
> >
> >  /* BUFFER_ALIGN(adr) calculates the number of bytes to the next
> > alignment. */ -#define BUFFER_ALIGN(adr) ((ALIGNMENT - ((u32)adr)) %
> > ALIGNMENT)
> > +#define BUFFER_ALIGN(adr) ((ALIGNMENT - ((long)adr)) % ALIGNMENT)
> 
> I can't see any reason to change unsigned type to signed one.
Agree. Also, I think we can get rid of this custom BUFFER_ALIGN
macro and simply calling skb_reserve(skb, NET_IP_ALIGN)
will make the protocol header to be aligned on at 
least a 4-byte boundary?

> 
> >
> >  #ifdef __BIG_ENDIAN
> >  #define xemaclite_readl		ioread32be
> > @@ -338,7 +338,7 @@ static int xemaclite_send_data(struct net_local
> *drvdata, u8 *data,
> >  		 * if it is configured in HW
> >  		 */
> >
> > -		addr = (void __iomem __force *)((u32 __force)addr ^
> > +		addr = (void __iomem __force *)((long __force)addr ^
> 
> ditto.
> 
> >  						 XEL_BUFFER_OFFSET);
> >  		reg_data = xemaclite_readl(addr + XEL_TSR_OFFSET);
> >
> > @@ -399,7 +399,7 @@ static u16 xemaclite_recv_data(struct net_local
> *drvdata, u8 *data, int maxlen)
> >  		 * will correct on subsequent calls
> >  		 */
> >  		if (drvdata->rx_ping_pong != 0)
> > -			addr = (void __iomem __force *)((u32 __force)addr ^
> > +			addr = (void __iomem __force *)((long __force)addr
> ^
> 
> ditto.
> 
> >
> XEL_BUFFER_OFFSET);
> >  		else
> >  			return 0;	/* No data was available */
> > @@ -1192,9 +1192,9 @@ static int xemaclite_of_probe(struct
> platform_device *ofdev)
> >  	}
> >
> >  	dev_info(dev,
> > -		 "Xilinx EmacLite at 0x%08X mapped to 0x%08X, irq=%d\n",
> > +		 "Xilinx EmacLite at 0x%08X mapped to 0x%08lX, irq=%d\n",
> >  		 (unsigned int __force)ndev->mem_start,
> > -		 (unsigned int __force)lp->base_addr, ndev->irq);
> > +		 (unsigned long __force)lp->base_addr, ndev->irq);
> 
> This is different case but I don't think address can be signed type here too.
> 
> >  	return 0;
> >
> >  error:
> >
> 
> Thanks,
> Michal