[PATCH v3 1/8] initial UHR support

[Raja Mani]

On 4/28/2026 1:11 PM, Johannes Berg wrote:
> On Mon, 2026-04-27 at 16:48 +0530, Raja Mani wrote:
>>
>>> +#ifdef CONFIG_IEEE80211BN
>>> +	if (hapd->iconf->ieee80211bn && !hapd->conf->disable_11bn) {
>>
>> Can the above line replaced with hostapd_is_uhr_enabled(hapd) ?
> 
> I guess. We still don't have that in our internal version, so evidently
> I made an incomplete translation.

hostapd_is_uhr_enabled() implementation is added in this patch and
the same is used other places in this patch. I was thinking why this
place alone missed out.

> 
>>> +		if (hapd->iconf->require_uhr && !(sta->flags & WLAN_STA_UHR)) {
>>> +			hostapd_logger(hapd, sta->addr,
>>> +				       HOSTAPD_MODULE_IEEE80211,
>>> +				       HOSTAPD_LEVEL_INFO,
>>> +				       "Station does not support mandatory UHR PHY - reject association");
>>> +			/* FIXME - need assignment from spec */
>>> +			return WLAN_STATUS_DENIED_EHT_NOT_SUPPORTED;
>>
>> 11bn draft 1.3 has defined the status code 157(DENIED_UHR_NOT_SUPPORTED)
>> in section "9.4.1.9 Status Code field". Can this be replaced with that?
> 
> Oh, right, should be.
> 
>>> @@ -2296,6 +2297,24 @@ static void phy_info_iftype_copy(struct hostapd_hw_modes *mode,
>>>    			  nla_data(tb[NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PPE]),
>>>    			  len);
>>>    	}
>>> +
>>> +	if (!tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC] ||
>>> +	    !tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_PHY])
>>> +		return;
>>> +
>>> +	uhr_capab->uhr_supported = true;
>>> +
>>> +	if (tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC] &&
>>> +	    nla_len(tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC]) >= (int)sizeof(uhr_capab->mac))
>>> +		os_memcpy(uhr_capab->mac,
>>> +			  nla_data(tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC]),
>>> +			  sizeof(uhr_capab->mac));
>>
>> Just to consider minimum possible mac cap size for os_memcpy(),
>> Can this be modified like this?
>>
>>      if (tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC]) {
>>          len = nla_len(tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC]);
>>
>>          if (len > sizeof(uhr_capab->mac))
>>               len = sizeof(uhr_capab->mac);
>>          os_memcpy(uhr_capab->mac,
>> 	         nla_data(tb[NL80211_BAND_IFTYPE_ATTR_UHR_CAP_MAC]),
>>                    len);
>>      }
>>
>> and in the below hunk as well?
> 
> I don't follow. Why?

The suggested style is same as how HE/EHT Phy and Mac bytes copy are
handled in the same function. Nothing new. Would that style be useful
to handle a case when mac80211 sends lesser bytes in Mac/Phy attr than
hostapd expected ? (for ex: mac80211 sends 1 byte info uhr phy cap
and hostapd expects 2 byte phy cap). This is not a problem now.
Such style helpful to handle when mac80211 and hostapd are not in sync ?

> 
> johannes