Re: [PATCH] prism54usb: Fix hail of warnings on 64bit platforms

Re: [PATCH] prism54usb: Fix hail of warnings on 64bit platforms

[Mark Lord]

Alan Cox wrote:
> If you want to cast a pointer to a small value then start by turning it
> into an unsigned long so the compiler knows what is going on.
> 
> Personally I find the whole approach used by this driver for types of
> registers (which are really USB register numbers) utterly perverse...
...
>
>	err = p54u_write(priv, buf, type,\
> -				 cpu_to_le32((u32)addr), data);\
> +				 cpu_to_le32((u32)(unsigned long)addr), data);\
...

What exactly are those "addr" parameters -- memory addresses ?

-ml

[PATCH] prism54usb: Fix hail of warnings on 64bit platforms

[Alan Cox]

If you want to cast a pointer to a small value then start by turning it
into an unsigned long so the compiler knows what is going on.

Personally I find the whole approach used by this driver for types of
registers (which are really USB register numbers) utterly perverse...

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.21-rc2-mm2/drivers/net/wireless/mac80211/p54/prism54usb.c linux-2.6.21-rc2-mm2/drivers/net/wireless/mac80211/p54/prism54usb.c
--- linux.vanilla-2.6.21-rc2-mm2/drivers/net/wireless/mac80211/p54/prism54usb.c	2007-03-06 23:09:47.000000000 +0000
+++ linux-2.6.21-rc2-mm2/drivers/net/wireless/mac80211/p54/prism54usb.c	2007-03-06 19:15:52.000000000 +0000
@@ -533,7 +533,7 @@
 #define P54U_WRITE(type, addr, data) \
 	do {\
 		err = p54u_write(priv, buf, type,\
-				 cpu_to_le32((u32)addr), data);\
+				 cpu_to_le32((u32)(unsigned long)addr), data);\
 		if (err) \
 			goto fail;\
 	} while (0)
@@ -541,7 +541,7 @@
 #define P54U_READ(type, addr) \
 	do {\
 		err = p54u_read(priv, buf, type,\
-				cpu_to_le32((u32)addr), &reg);\
+				cpu_to_le32((u32)(unsigned long)addr), &reg);\
 		if (err)\
 			goto fail;\
 	} while (0)
@@ -648,16 +648,16 @@
 			   cpu_to_le32(0xc0000f00));
 
 		P54U_WRITE(NET2280_DEV_U32,
-			   0x0020 | (u32)&devreg->direct_mem_win, 0);
+			   0x0020 | (unsigned long)&devreg->direct_mem_win, 0);
 		P54U_WRITE(NET2280_DEV_U32,
-			   0x0020 | (u32)&devreg->direct_mem_win,
+			   0x0020 | (unsigned long)&devreg->direct_mem_win,
 			   cpu_to_le32(1));
 
 		P54U_WRITE(NET2280_DEV_U32,
-			   0x0024 | (u32)&devreg->direct_mem_win,
+			   0x0024 | (unsigned long)&devreg->direct_mem_win,
 			   cpu_to_le32(block_len));
 		P54U_WRITE(NET2280_DEV_U32,
-			   0x0028 | (u32)&devreg->direct_mem_win,
+			   0x0028 | (unsigned long)&devreg->direct_mem_win,
 			   cpu_to_le32(offset));
 
 		P54U_WRITE(NET2280_DEV_U32, &devreg->dma_addr,
@@ -670,7 +670,7 @@
 		mdelay(10);
 
 		P54U_READ(NET2280_DEV_U32,
-			  0x002C | (u32)&devreg->direct_mem_win);
+			  0x002C | (unsigned long)&devreg->direct_mem_win);
 		if (!(reg & cpu_to_le32(ISL38XX_DMA_STATUS_DONE)) ||
 		    !(reg & cpu_to_le32(ISL38XX_DMA_STATUS_READY))) {
 			printk(KERN_ERR "prism54usb: firmware DMA transfer "

Re: [PATCH] prism54usb: Fix hail of warnings on 64bit platforms

[Alan Cox]

On Wed, 07 Mar 2007 10:42:57 -0500
Mark Lord <lkml@rtr.ca> wrote:

> Alan Cox wrote:
> > If you want to cast a pointer to a small value then start by turning it
> > into an unsigned long so the compiler knows what is going on.
> > 
> > Personally I find the whole approach used by this driver for types of
> > registers (which are really USB register numbers) utterly perverse...
> ...
> >
> >	err = p54u_write(priv, buf, type,\
> > -				 cpu_to_le32((u32)addr), data);\
> > +				 cpu_to_le32((u32)(unsigned long)addr), data);\
> ...
> 
> What exactly are those "addr" parameters -- memory addresses ?
>

They end up being passed as small values over the USB link to the chip
the other end. 

Alan

Re: [PATCH] prism54usb: Fix hail of warnings on 64bit platforms

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Wednesday 07 March 2007 11:40, Alan Cox wrote:
> If you want to cast a pointer to a small value then start by turning it
> into an unsigned long so the compiler knows what is going on.
>
I already have a fix for that - just haven't pushed it up to wireless-dev yet.

> Personally I find the whole approach used by this driver for types of
> registers (which are really USB register numbers) utterly perverse...
>
The same register offsets are used in the PCI driver since version 1 usb 
devices are really just the PCI device with a usb->pci bridge chip attached.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]