Simon Wunderlich <sw@xxxxxxxxxxxxxxxxxx> writes:
> Hey Kalle,
>
>> Simon Wunderlich <sw@xxxxxxxxxxxxxxxxxx> writes:
>> >> > +struct fft_sample_ath10k {
>> >> > + struct fft_sample_tlv tlv;
>> >> > + u8 chan_width_mhz;
>> >> > + __be16 freq1;
>> >> > + __be16 freq2;
>> >> > + __be16 noise;
>> >> > + __be16 max_magnitude;
>> >> > + __be16 total_gain_db;
>> >> > + __be16 base_pwr_db;
>> >> > + __be64 tsf;
>> >> > + s8 max_index;
>> >> > + u8 rssi;
>> >> > + u8 relpwr_db;
>> >> > + u8 avgpwr_db;
>> >> > + u8 max_exp;
>> >> > +
>> >> > + u8 data[0];
>> >> > +} __packed;
>> >>
>> >> __be16, that's a first. Just making sure that this really is big endian?
>> >
>> > As the __le32 you use in other ath10k structs, this is just for checking
>> > - at least sparse should check that, maybe other tools as well.
>>
>> Sorry, I didn't understand your comment here. But basically I was asking
>> is the fft sample really in big endian? I assume it would be little
>> endian as everything else coming from the firmware.
>
> Yeah that is intended - we are also using big endian in ath9k to send fft
> samples to userspace, because that is the network byte order and we then just
> use ntohs() and friends in userspace to read samples from any system.
> Therefore we intent to use the same encoding in ath10k. :)
Ah, this is the struct going to user space? I thought it's coming from
the firmware. Then forget my question :)
--
Kalle Valo
--
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
