On 22.06.23 18:41, Johannes Berg wrote:
On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote:
On 22.06.23 18:07, Johannes Berg wrote:
> On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote:
> > Since AP_VLAN interfaces are not pushed to the driver,
> >
> That's a mac80211 thing though.
>
> > the driver should not
> > be expected to register iftype data for them.
> > Map them to the regular AP iftype on lookup.
>
> And this is in cfg80211 - not sure that seems right?
>
> OTOH I'd expect no callers with VLAN here, it doesn't really make sense
> since they're not a standalone mode that actually has HE/EHT, but still,
> seems odd this way?
>
> What's actually calling it? I'm guessing somewhere in mac80211?
Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix
because that's what the header file belongs to.
I made the patch in response to this:
https://patchwork.kernel.org/project/linux-wireless/patch/20230605152141.17434-4-shayne.chen@xxxxxxxxxxxx/
OK, sure, that also doesn't really make sense.
I found that there are several calls to ieee80211_get_he_iftype_cap and
ieee80211_get_eht_iftype_cap, which could be affected by this issue.
I thought dealing with this in a single place would be better than playing
whac-a-mole by fixing it at the call sites.
I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so
it shouldn't be that bad? Looks like I forgot some though.
I guess one advantage in using my fix would be that it's way easier to
backport.
How about using my fix initially (with a changed prefix if you prefer),
and then replace it once the call sites have been switched over to
ieee80211_get_he_iftype_cap_vif?
- Felix
