If userspace provides a puncturing bitmap via the NL80211_ATTR_PUNCT_BITMAP
attribute, the kernel with mac80211_hwsim driver currently rejects the
command with the error: "driver doesn't support puncturing", because the
driver does not advertise support for this feature.

At present, the following hwsim test cases utilize puncturing, but the
bitmap is not sent to the kernel. Instead, the puncturing information is
conveyed only through the beacon data:
 * eht_5ghz_80mhz_puncturing_override_1
 * eht_5ghz_80mhz_puncturing_override_2
 * eht_5ghz_80mhz_puncturing_override_3

A future change in hostapd will begin configuring the puncturing bitmap
explicitly, which will cause these test cases to fail unless the driver
advertises support.

To address this, update mac80211_hwsim driver to advertise puncturing
feature support.

Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
---
 drivers/net/wireless/virtual/mac80211_hwsim.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index 9f856042a67a..cd84dfd5b47e 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -5793,6 +5793,7 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
 		ieee80211_hw_set(hw, NO_AUTO_VIF);
 
 	wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
+	wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_PUNCT);
 
 	for (i = 0; i < ARRAY_SIZE(data->link_data); i++) {
 		hrtimer_setup(&data->link_data[i].beacon_timer, mac80211_hwsim_beacon,

---
base-commit: 94aced6ed9e2630bae0b5631e384a5302c4b6783
change-id: 20251009-hwsim_set_punct_feature_bit-9299a4b30b82

On Fri, 2025-10-17 at 09:32 +0530, Aditya Kumar Singh wrote:
> If userspace provides a puncturing bitmap via the NL80211_ATTR_PUNCT_BITMAP
> attribute, the kernel with mac80211_hwsim driver currently rejects the
> command with the error: "driver doesn't support puncturing", because the
> driver does not advertise support for this feature.
> 
> At present, the following hwsim test cases utilize puncturing, but the
> bitmap is not sent to the kernel. Instead, the puncturing information is
> conveyed only through the beacon data:
>  * eht_5ghz_80mhz_puncturing_override_1
>  * eht_5ghz_80mhz_puncturing_override_2
>  * eht_5ghz_80mhz_puncturing_override_3
> 
> A future change in hostapd will begin configuring the puncturing bitmap
> explicitly, which will cause these test cases to fail unless the driver
> advertises support.
> 
> To address this, update mac80211_hwsim driver to advertise puncturing
> feature support.

This might be a good time to introduce better checks vs. what we have
now in hwsim_chans_compat(), which just uses the control channel rather
than any actual bandwidth/puncturing/etc.

It'd also make the tests actually test more. What do you think?

johannes

On 10/20/2025 7:55 PM, Johannes Berg wrote:
> On Fri, 2025-10-17 at 09:32 +0530, Aditya Kumar Singh wrote:
>> If userspace provides a puncturing bitmap via the NL80211_ATTR_PUNCT_BITMAP
>> attribute, the kernel with mac80211_hwsim driver currently rejects the
>> command with the error: "driver doesn't support puncturing", because the
>> driver does not advertise support for this feature.
>>
>> At present, the following hwsim test cases utilize puncturing, but the
>> bitmap is not sent to the kernel. Instead, the puncturing information is
>> conveyed only through the beacon data:
>>   * eht_5ghz_80mhz_puncturing_override_1
>>   * eht_5ghz_80mhz_puncturing_override_2
>>   * eht_5ghz_80mhz_puncturing_override_3
>>
>> A future change in hostapd will begin configuring the puncturing bitmap
>> explicitly, which will cause these test cases to fail unless the driver
>> advertises support.
>>
>> To address this, update mac80211_hwsim driver to advertise puncturing
>> feature support.
> 
> This might be a good time to introduce better checks vs. what we have
> now in hwsim_chans_compat(), which just uses the control channel rather
> than any actual bandwidth/puncturing/etc.

Comparing those will be equivalent to comparing chandefs instead of 
control channel right? And we already have a helper 
cfg80211_chandef_compatible() to do that. So we just need to pass 
chandefs and call that helper? Or hwsim should be more stricter and just 
use cfg80211_chandef_identical() (this helper is not exported yet!) ?
  >
> It'd also make the tests actually test more. What do you think?

That's true. You want those changes also along with this patch or you'd 
take this one as it is and take those separately?



-- 
Aditya

On Tue, 2025-10-21 at 11:26 +0530, Aditya Kumar Singh wrote:
> On 10/20/2025 7:55 PM, Johannes Berg wrote:
> > On Fri, 2025-10-17 at 09:32 +0530, Aditya Kumar Singh wrote:
> > > If userspace provides a puncturing bitmap via the NL80211_ATTR_PUNCT_BITMAP
> > > attribute, the kernel with mac80211_hwsim driver currently rejects the
> > > command with the error: "driver doesn't support puncturing", because the
> > > driver does not advertise support for this feature.
> > > 
> > > At present, the following hwsim test cases utilize puncturing, but the
> > > bitmap is not sent to the kernel. Instead, the puncturing information is
> > > conveyed only through the beacon data:
> > >   * eht_5ghz_80mhz_puncturing_override_1
> > >   * eht_5ghz_80mhz_puncturing_override_2
> > >   * eht_5ghz_80mhz_puncturing_override_3
> > > 
> > > A future change in hostapd will begin configuring the puncturing bitmap
> > > explicitly, which will cause these test cases to fail unless the driver
> > > advertises support.
> > > 
> > > To address this, update mac80211_hwsim driver to advertise puncturing
> > > feature support.
> > 
> > This might be a good time to introduce better checks vs. what we have
> > now in hwsim_chans_compat(), which just uses the control channel rather
> > than any actual bandwidth/puncturing/etc.
> 
> Comparing those will be equivalent to comparing chandefs instead of 
> control channel right? And we already have a helper 
> cfg80211_chandef_compatible() to do that. So we just need to pass 
> chandefs and call that helper? Or hwsim should be more stricter and just 
> use cfg80211_chandef_identical() (this helper is not exported yet!) ?

I guess it shouldn't be either of those, since if you transmit at a
higher bandwidth, even if cfg80211_chandef_compatible() returns true, it
still shouldn't work? But that's also a rate scaling thing with the
bandwidth actually used.

>   >
> > It'd also make the tests actually test more. What do you think?
> 
> That's true. You want those changes also along with this patch or you'd 
> take this one as it is and take those separately?

Well given what we have now it doesn't really matter I guess, just
thought about it here because of the context.

johannes