On Thu, 2012-12-27 at 13:13 +0000, Malcolm Priestley wrote: > upstream commit > 7730492855a2f9c828599bcd8d62760f96d319e4 > > Tested on kernels 2.6.35, 3.0, 3.2, 3.5 & 3.7 > > staging: vt6656: 64 bit fixes : correct all type sizes > > After this patch all BYTE/WORD/DWORD types can be replaced with the > appropriate u sizes. > > Cc: [email protected] # 2.6.35+ > Signed-off-by: Malcolm Priestley <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > diff --git a/drivers/staging/vt6656/ttype.h b/drivers/staging/vt6656/ttype.h > index 0f70562c..dfbf747 100644 > --- a/drivers/staging/vt6656/ttype.h > +++ b/drivers/staging/vt6656/ttype.h > @@ -44,9 +44,9 @@ typedef int BOOL; > > /****** Simple typedefs ***************************************************/ > > -typedef unsigned char BYTE; // 8-bit > -typedef unsigned short WORD; // 16-bit > -typedef unsigned long DWORD; // 32-bit > +typedef u8 BYTE; > +typedef u16 WORD; > +typedef u32 DWORD; > > // QWORD is for those situation that we want > // an 8-byte-aligned 8 byte long structure > @@ -62,8 +62,8 @@ typedef UQuadWord QWORD; // 64-bit > > /****** Common pointer types ***********************************************/ > > -typedef unsigned long ULONG_PTR; // 32-bit > -typedef unsigned long DWORD_PTR; // 32-bit > +typedef u32 ULONG_PTR; > +typedef u32 DWORD_PTR; > > // boolean pointer >
ULONG_PTR and DWORD_PTR were introduced in 64-bit Windows for use where an parameter or field previously declared as ULONG or DWORD was expected to hold a pointer. So I think that unsigned long was the correct definition. This also seems to have no practical effect (at least in 3.2), so I don't think it's suitable for stable. Ben. -- Ben Hutchings The world is coming to an end. Please log off.
signature.asc
Description: This is a digitally signed message part
