Re: [RFC/RFT 3/4] mt76x02: do not set protection on set_rts_threshold callback

[Stanislaw Gruszka <sgruszka@redhat.com>]

On Fri, Nov 09, 2018 at 10:23:56AM +0100, Lorenzo Bianconi wrote:
> > Use set_rts_threshold calback to enable/disable threshold only for
> > legacy traffic. RTS/CTS threshold for HT TXOP make make no sense
> > to me since used protection (RTS/CTS , CTS-to-self or none)
> > should be determined by HT capabilities and applied to any HT
> > frames.
> > 
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > ---
> >  drivers/net/wireless/mediatek/mt76/mt76x02_mac.c  | 16 +---------------
> >  drivers/net/wireless/mediatek/mt76/mt76x02_mac.h  |  2 +-
> >  drivers/net/wireless/mediatek/mt76/mt76x02_util.c |  2 +-
> >  3 files changed, 3 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > index 59b336e34cb5..567a7ab47fab 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> > @@ -737,7 +737,7 @@ void mt76x02_tx_complete_skb(struct mt76_dev *mdev, struct mt76_queue *q,
> >  }
> >  EXPORT_SYMBOL_GPL(mt76x02_tx_complete_skb);
> >  
> > -void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val)
> > +void mt76x02_mac_set_rts_thresh(struct mt76x02_dev *dev, u32 val)
> >  {
> >  	u32 data = 0;
> >  
> > @@ -751,20 +751,6 @@ void mt76x02_mac_set_tx_protection(struct mt76x02_dev *dev, u32 val)
> >  		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> >  	mt76_rmw(dev, MT_OFDM_PROT_CFG,
> >  		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> 
> Do we need to configure MT_OFDM_PROT_CFG and MT_CCK_PROT_CFG here? (since they
> are already configured in 4/4 (mt76x02: set protection according to ht
> capabilities))

Only OFDM_PROT_CFG is configured there based on legacy proto
value. I'm not sure how handle CCK_PROT_CFG.

> > -	mt76_rmw(dev, MT_MM20_PROT_CFG,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -	mt76_rmw(dev, MT_MM40_PROT_CFG,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -	mt76_rmw(dev, MT_GF20_PROT_CFG,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -	mt76_rmw(dev, MT_GF40_PROT_CFG,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -	mt76_rmw(dev, MT_TX_PROT_CFG6,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -	mt76_rmw(dev, MT_TX_PROT_CFG7,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> > -	mt76_rmw(dev, MT_TX_PROT_CFG8,
> > -		 MT_PROT_CFG_CTRL | MT_PROT_CFG_RTS_THRESH, data);
> 
> Removing these lines we are no longer able to configure protection for VHT
> rates. Do we have an equivalent for them in vht_capab?

Actually it's not based on HT capabilities but by on ht operation and
it's modified dynamically by hostapd based on what stations are
associated. For STA mode it's provided by remote AP via HT operation IE.

VHT Operation IE do not define protection. Seems interoperability with
legacy STA's is not allowed for VHT, so leaving default values from
initvals where PROT bits are 0 (none protection) is right thing to do.

Regards
Stanislaw