On Tue, Apr 24, 2007 at 08:49:04AM -0700, Kristen Carlson Accardi wrote: > On Tue, 24 Apr 2007 12:23:04 +0200 > Olivier Galibert <galibert@xxxxxxxxx> wrote: > > > Sorry for replying to Alan's reply, I missed the original mail. > > > > > > +#define ata_id_has_AN(id) \ > > > > + ((id[76] && (~id[76])) & ((id)[78] & (1 << 5))) > > > > (a && ~a) & (b & 32) > > > > I don't think that does what you think it does, because at that point > > it's a funny way to write 0 ((0 or 1) binary-and (0 or 32)). > > > > I'm not even sure what it is you want. If for the first part you > > wanted (id[76] != 0x00 && id[76] != 0xff), please write just that, > > thanks :-) > > > > OG. > > > > >From the serial ata spec, we have: > > 13.2.1.18 Word 78: Serial ATA features supported > If Word 76 is not 0000h or FFFFh, Word 78 reports the optional features > supported by the device. Support for this word is optional and if not > supported the word shall be zero indicating the device has no support for new > Serial ATA capabilities. > > so, basically yes, I'm really testing to make sure that word 76 isn't 0 or all > one then using that value & with value of bit in work 78 to determine AN > support - if you think this is really obfuscated, I've got no problem changing > it - there's obviously many ways to mess around with bits. & is not &&, so right now it's really incorrect. 1 & 32 is 0. ((id)[76] != 0x0000 && (id)[76] != 0xffff && ((id)[78] & (1 << 5))) The implicit typing of id looks dangerous to me, but you're not the one who has started it. OG. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
