On Mon, 2008-06-09 at 19:24 +0200, Johannes Berg wrote: > > > So I guess will we converting idioms > > > u16 fc = le16_to_cpu(hdr->frame_control); > > > int hdr_len = ieee80211_get_hdrlen(fc); > > > to > > > int hdr_len = ieee80211_hdrlen(hdr->frame_control) > > > > > > This is how it used in driver code so it make sense to export this > > > function and remove ieee80211_get_hdrlen(fc) > > > > Yes, that was my thinking, I just did it this way to avoid the flag day > > change, I'll trickle the changes in and then remove _get_hdrlen. > > Sounds good to me. > OK, will keep going on this then. > > > Since all fc operations are bitwise 'and' and 'or' > > > u16 rx->fc can be dropped in future as well > > > > I was going to convert it to a __le16, but if it is just a copy of the > > ->frame_control in the header, I'll look at removing it instead. > > Yeah, I think rx->fc was meant to be a cpu-byteorder copy of > hdr->frame_control to avoid repeated byteswapping. If we do all > operations on the constants instead as you're doing with this series, we > ought to be able to remove it. Bonus point: that gets rid of the > possible "rx->fc is out of sync" issue we had to fix once already. That and be arches eliminate a bunch of byteswaps. Cheers, Harvey -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
