[PATCH v3 1/8] initial UHR support

[Raja Mani]

On 5/7/2026 10:33 PM, Johannes Berg wrote:
> Hi,
> 
>>>>> +	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 ?
> 
> Sorry, was making adjustments and realised I never replied to this.

No problem

> 
> I'm not sure I really agree, if it's inconsistent between the two then
> something bad happened, no? Even the >= is a bit questionable to me, if
> the driver thinks the MAC capabilities should be bigger, then both are
> working off different drafts of the spec, and things can't really be
> good anyway ...
> 
> johannes

Ok, Let's go with your logic. The whole V4 series looks fine to me.

Raja