On Wed, Dec 01, 2010 at 01:30:55PM -0500, Mike Frysinger wrote: > On Tuesday, November 30, 2010 20:43:57 Greg KH wrote: > > On Thu, Nov 18, 2010 at 06:03:45PM -0500, Mike Frysinger wrote: > > > On Thursday, November 18, 2010 17:04:38 Greg KH wrote: > > > > On Thu, Nov 18, 2010 at 04:08:26PM -0500, Mike Frysinger wrote: > > > > > -#if (__BYTE_ORDER == __LITTLE_ENDIAN) > > > > > - #define le16_to_cpu(x) (x) > > > > > -#elif (__BYTE_ORDER == __BIG_ENDIAN) > > > > > - #define le16_to_cpu(x) bswap_16(x) > > > > > -#else > > > > > - #error missing BYTE_ORDER > > > > > -#endif > > > > > +#define le16_to_cpu(x) libusb_cpu_to_le16(libusb_cpu_to_le16(x)) > > > > > > > > This line causes warnings when building. And are you sure it's right? > > > > Is that how libusb wants to be used? Why not just use the > > > > libusb_le16_to_cpu() macro instead? > > > > > > it isnt causing warings for me ... what warnings are you seeing ? > > > > CC lsusb-lsusb.o > > lsusb.c: In function âdump_configâ: > > lsusb.c:487:9: warning: declaration of â_tmpâ shadows a previous local > > lsusb.c:487:9: warning: shadowed declaration is here > > lsusb.c:487:9: warning: declaration of â_tmp2â shadows a previous local > > lsusb.c:487:9: warning: shadowed declaration is here > > lsusb.c: In function âdump_endpointâ: > > lsusb.c:745:18: warning: declaration of â_tmpâ shadows a previous local > > lsusb.c:745:18: warning: shadowed declaration is here > > lsusb.c:745:18: warning: declaration of â_tmp2â shadows a previous local > > lsusb.c:745:18: warning: shadowed declaration is here > > i guess you're using -Wshadow ? or your compiler enables that by default ? > my understanding is that shadow warnings are not typically enabled by default > due to the commonness of false positives. I'm using: gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] which might have enabled that by default, I don't really know. > > > it's doubled up because because it seems like the code wants to turn > > > "le16 to cpu" but libusb is doing "cpu to le16". but looking at the > > > usage of this macro, perhaps i'm reading too much into the name. > > > > > > i'll try and find a big endian machine with usable USB ... > > > > What do you suggest we do? Why can't we rely on the libusb version > > instead here? > > when i eyeballed the code before, the two funcs did not appear to be doing the > same thing. if they are indeed, the same thing (but just poor naming), then > there's no reason for this local macro to exist. but i dont personally have > any big endian systems anymore for me to verify the behavior with actual > hardware. my quad G5's cooling system decided to kill itself. > > so i suggest someone step up who is running Linux on a PPC and verify with > some actual USB devices that this macro is not necessary and the libusb one is > sufficient. Ok, I'll try releasing a version with the existing code to see if we get any complaints :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
