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?
thanks,
greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
