On Tue, 2017-10-24 at 06:36 -0700, Ben Greear wrote: > > On 10/23/2017 10:54 PM, Johannes Berg wrote: > > On Mon, 2017-10-23 at 13:59 -0700, Ben Greear wrote: > > > > > > The CSI data has variable length [1] but it's fundamentally always tied > > > > to a specific frame and as such we've always attached it to that frame > > > > using a radiotap vendor namespace. > > > > > > > > You can easily implement that in a mac80211 driver since it has support > > > > for that via RX_FLAG_RADIOTAP_VENDOR_DATA and the associated struct > > > > ieee80211_vendor_radiotap that you put into the skb's head. > > > > > > > > Why should anything else be needed? > > > > > > So this would only show up in user-space in something like a pkt-capture? > > > > Sure. But since you can easily add virtual monitor interfaces at any > > time, that doesn't really mean anything. > > Adding a monitor device is a pretty big hammer on ath10k, at least, and > probably not something one would want running continuously in a production > environment. We keep having this discussion. You need to fix this, it should be really simple to fix this - just remove all checks for CONF_MONITOR from ath10k and make it use WANT_MONITOR_VIF instead if it doesn't already. > The CSI data is one part, but tx-beamforming is another area of interest. > > If I get a chance, I'll try to add a way to pass some of this opaque > info up through netlink events. I'm thinking something like: > > mac80211_nl_send_opaque_event(mac80211-handle, int data-type, u8* data, int data_len); I will not accept this upstream. johannes
