> > 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. > > 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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
