[PATCH v3 1/8] initial UHR support

[Johannes Berg]

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.

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