On Wed, Jun 23, 2010 at 03:16:16PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jun 23, 2010 at 09:47:44AM +0200, Jiri Slaby wrote:
> > On 06/23/2010 01:56 AM, Charles Clément wrote:
> > > Replace all occurrences with unsigned long type.
> >
> > At least this:
> >
> > > --- a/drivers/staging/vt6655/desc.h
> > > +++ b/drivers/staging/vt6655/desc.h
> > ...
> > > @@ -391,13 +391,13 @@ typedef const STxDesc *PCSTxDesc;
> > > typedef struct tagSTxSyncDesc {
> > > volatile STDES0 m_td0TD0;
> > > volatile STDES1 m_td1TD1;
> > > - volatile DWORD buff_addr; // pointer to logical buffer
> > > - volatile DWORD next_desc; // pointer to next logical descriptor
> > > + volatile unsigned long buff_addr; // pointer to logical buffer
> > > + volatile unsigned long next_desc; // pointer to next logical descriptor
> > > volatile WORD m_wFIFOCtl;
> > > volatile WORD m_wTimeStamp;
> > > struct tagSTxSyncDesc* next; //4 bytes
> > > volatile PDEVICE_TD_INFO pTDInfo;//4 bytes
> > > - volatile DWORD m_dwReserved2;
> > > + volatile unsigned long m_dwReserved2;
> > > } __attribute__ ((__packed__))
> >
> > and this:
> >
> > > --- a/drivers/staging/vt6655/ttype.h
> > > +++ b/drivers/staging/vt6655/ttype.h
> > > @@ -70,15 +70,14 @@ typedef int BOOL;
> > >
> > > typedef unsigned char BYTE; // 8-bit
> > > typedef unsigned short WORD; // 16-bit
> > > -typedef unsigned long DWORD; // 32-bit
> > >
> > > // QWORD is for those situation that we want
> > > // an 8-byte-aligned 8 byte long structure
> > > // which is NOT really a floating point number.
> > > typedef union tagUQuadWord {
> > > struct {
> > > - DWORD dwLowDword;
> > > - DWORD dwHighDword;
> > > + unsigned long dwLowDword;
> > > + unsigned long dwHighDword;
> > > } u;
> > > double DoNotUseThisField;
> > > } UQuadWord;
> >
> > is wrong. DWORD should be replaced by u32 or unsigned int. Not long.
> > Otherwise it doesn't make sense. For the former, it's a packed structure
> > so it changes size on 64-bit, for the latter the union is not anymore
> > the same on 64-bit. One of the u members contains the whole double there.
>
> Yeah, but unfortunatly, this is just preserving the problems that were
> already there for the 64-bit version of this driver. We ran into this
> before with this type of thing, which makes me believe that the driver
> was never run on a 64bit processor (which makes sense as via doesn't
> have them.)
>
> Charles, care to fix this up and resend this series?
Yes, no problem, although won't just changing these to u32 for the first
case take the problem elsewhere in the driver?
>
> thanks,
>
> greg k-h
--
Charles Clément
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
