[PATCHv2 2/2] ath10k: add spectral scan feature

[Kalle Valo]

Simon Wunderlich <sw at simonwunderlich.de> writes:

> Hey Kalle,
>
>> Simon Wunderlich <sw at simonwunderlich.de> 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