[PATCH 0/3] Staging: vt6655: remove PBYTE/PWORD/PDWORD typedef

Greg KH greg at kroah.com
Fri Jun 18 17:52:19 UTC 2010


On Fri, Jun 18, 2010 at 10:40:00AM -0700, Charles Clément wrote:
> On Fri, Jun 18, 2010 at 10:33:15AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Jun 18, 2010 at 10:25:28AM -0700, Greg KH wrote:
> > > On Fri, Jun 18, 2010 at 10:21:03AM -0700, Greg KH wrote:
> > > > On Sat, Jun 05, 2010 at 03:13:46PM -0700, Charles Clément wrote:
> > > > > Remove the following typedef from ttype.h and replace with the actual type:
> > > > > 	PBYTE	->	unsigned char *
> > > > > 	PWORD	->	unsigned short *
> > > > > 	PDWORD	->	unsigned long *
> > > > 
> > > > After applying all of your typedef cleanup patches, I'm getting a bunch
> > > > of compiler warnings on x86-64 like:
> > > > 	drivers/staging/vt6655/iwctl.c: In function ‘iwctl_get_wireless_stats’:
> > > > 	drivers/staging/vt6655/iwctl.c:119:36: warning: cast from pointer to integer of different size
> > > > 
> > > > I'll go see what went wrong...
> > > 
> > > Ah, found it:
> > > 	Staging: vt6655: remove U32 custom macro
> > > was wrong.
> > > 
> > > The line:
> > > 	-typedef unsigned long           U32;    /* 32-bit unsigned integer */
> > > 
> > > was fine, but you then went and made "U32" a "u32" all through the
> > > driver, which you would think would be correct based on the code.  But
> > > it's not, you need to make it a real "unsigned long" instead.
> > > 
> > > I'll go see if I can revert this one by hand or just fix it up...
> > 
> > It's simpler just to fix the few places that this really wanted to be an
> > unsigned long.  Here's the fixup patch I just applied that gets rid of
> > the build warnings, and hopefully makes the code work properly again:
> 
> Thank you, did any warning appeared on x86-64 with that commit:
> 659770d4033373340bc24fc125d1f3ba215e4669 ?

No it didn't.

> I basically did the same modification except for vt6655 instead of
> vt6656. Or probably the vt6656 didn't actually needed unsigned long at
> all.

Looks like this was only needed for 3 fields, so maybe that's why vt6656
didn't have the problem.  They weren't using that field for the wierd
macro, nor for registers they read from the device.

thanks,

greg k-h



More information about the devel mailing list