> > > > > > Since 80p80MHz is not supprted in mt7921, we should not register > > > this > > > capability to mac80211. When the feature coming, we may have a > > > new > > > config cap.has_bw80p80 to adapte the new flow. > > > > > > > Then, how to tell 80p80M and 160M apart with only checking > > IEEE80211_STA_RX_BW_160? > > > > * @IEEE80211_STA_RX_BW_160: station can receive up to 160 MHz > > * (including 80+80 MHz) > > > > Maybe move has_bw80p80 into mt7921_dev as it is not generic to me? > > > > As you noted, both 80p80M and 160M are included in > IEEE80211_STA_RX_BW_160. We may not check two features > by IEEE80211_STA_RX_BW_160 only. That is why I prefer to have > .has_bw160 and .has_80p80 at next stage. > > With the new feature, HW should report different result in the flow > of > chip capability check. The check point should start from > mt76_connac_mcu_parse_XXXX_cap() and then we can know the real > capabilities of this HW chip. > What about using device id? I think we can easily determine the BW without adding .has_xx in to common core, and it looks more like a 7921specific stuff though.