On 2013-05-09, at 2:03 PM, Andrew Morton wrote: [...] >> +static int w1_f29_disable_test_mode(struct w1_slave *sl) >> +{ >> + int res; >> + u8 magic[10] = {0x96, }; >> + u64 rn = le64_to_cpu(*((u64*)&sl->reg_num)); >> + memcpy(&magic[1], &rn, 8); >> + magic[9] = 0x3C; > > (please put a blank line between end-of-locals and start-of-code) > > The casting looks decidedly dodgy. I guess it won't cause an unalignned > exception due to reg_num's alignment, but it appears to defeat the > endianness handling in the definotion of `struct w1_reg_num'. > > Are you sure this will work OK with all architectures and both > __LITTLE_ENDIAN_BITFIELD and __BIG_ENDIAN_BITFIELD?
To be honest, I didn't really thought about it that much, I just copy pasted that from Evgeniy Polyakov's hunk at drivers/w1/w1_io.c, function w1_reset_select_slave(struct w1_slave *sl) exept I changed the MATCH_ROM with magic 0x96 and appended magic 0x3C. I have tested it only on the available platform I have which is x86. I agree it looks dodgy. Do you have an alternative? You are certainly more familiar with the kernel's fancy bit and endian tools than I am. I'd be willing to test prior to sending V3. struct w1_reg_num { #if defined(__LITTLE_ENDIAN_BITFIELD) __u64 family:8, id:48, crc:8; #elif defined(__BIG_ENDIAN_BITFIELD) __u64 crc:8, id:48, family:8; #else #error "Please fix <asm/byteorder.h>" #endif }; On the wire, the family byte should be sent first, then the MSB of id, then the rest of id and finally the crc. Perhaps Evgeniy can chime in here? Cheers, /jfd-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/