On Wed, 2022-02-16 at 15:35 +0530, Venkateswara Naralasetty wrote: > Channel Frequency Response feature is to get the channel state > information from the hardware based on the user configurations > and send the CSI data to user space. > > CSI data is further processed in user space which can be used to > identify the motion of the objects. > > Add vendor command support to configure per peer CFR parameters. > > An example of usage: > iw dev wlanx vendor send 0x1374 0xad cfr-en <val> bw <bw> method <method> > periodicity <period> addr <mac_addr> > > 0x1374: vendor id > 0xad: : vendor subcmd id > val: 0 to disable CFR capture > 1 to enable CFR capture > > bw: CFR capture bandwidth(use the values in enum nl80211_chan_width) > 1 - 20MHZ > 2 - 40MHZ > 3 - 80MHZ > > method: Method used by hardware to collect the CFR dump > 0 - from the ACKs of QOS NULL packets > 1 - from the ACKs of QOS NULL packets with phase > 2 - from the ACK of probe response packet > > periodicity: Periodicity in ms at which CFR dump need to be collect > 0 - single shot capture > non zero - for Periodic captures > > mac_addr: mac address of the peer for which CFR capture is requested. > > Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@xxxxxxxxxxx> > --- > v2: > * Updated the commit log. > That's a bit better, thanks. However, it still doesn't address the question of why it needs to be vendor specific API. Is this something fundamentally tied to the hardware? Fundamentally vendor specific? I'm not sure I see why it would be? johannes
