From: Johannes Berg <johannes@sipsolutions.net>
To: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
Date: Sat, 24 Nov 2018 19:48:17 +0100 [thread overview]
Message-ID: <3ce0f8352354900cd89074bcafe6ac45c29abd78.camel@sipsolutions.net> (raw)
In-Reply-To: <1542798228-3293-1-git-send-email-mpubbise@codeaurora.org>
This looks good to me, just a few nits below
On Wed, 2018-11-21 at 16:33 +0530, Manikanta Pubbisetty wrote:
> As per the current design, for sw crypto controlled devices, it is
> the device which has to advertise the support for AP/VLAN iftype
> based on it's capability to tranmsit packets encrypted in software
> (In VLAN functionality, group traffic generated for a specific
> VLAN group is always encrypted in software). Commit db3bdcb9c3ff
> ("mac80211: allow AP_VLAN operation on crypto controlled devices")
> has introduced this change.
>
> Since 4addr AP operation also uses AP/VLAN iftype, this conditional
> way of advertising AP/VLAN support has broken 4addr AP mode operation on
> crypto controlled devices which do not support VLAN functionality.
>
> For example:
> In the case of ath10k driver, not all firmwares have support for VLAN
> functionality but all can support 4addr AP operation. Because AP/VLAN
> support is not advertised for these devices, 4addr AP operations are
> also blocked.
>
> Fix this by allowing 4addr opertion on devices which do not advertise
operation
> AP/VLAN iftype but which can support 4addr operation (the desicion is
decision
> taken based on the wiphy flag WIPHY_FLAG_4ADDR_AP).
> Fixes: Commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on
> crypto controlled devices")
I think it'd be better not to wrap this
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -1394,8 +1394,13 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
> }
> break;
> case NETDEV_PRE_UP:
> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
> - return notifier_from_errno(-EOPNOTSUPP);
> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) {
> + if (!(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
> + wdev->use_4addr))
> + return notifier_from_errno(-EOPNOTSUPP);
> + }
Maybe that could be combined into one condition? It's kinda hard to read
either way though. I was thinking of making it positive, but then the
ERFKILL
> if (rfkill_blocked(rdev->rfkill))
> return notifier_from_errno(-ERFKILL);
would have to be _before_ it, and I'm not sure we want to change that.
So maybe make it
if (!(interface_modes & BIT() ||
(iftype == AP_VLAN && use_4addr && wiphy.flags & 4ADDR_AP)))
return ...(-EOPNOTSUPP);
instead?
I feel that's still easier to read than the double conditional with both
things being negated.
> +++ b/net/wireless/nl80211.c
> @@ -3383,8 +3383,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
> if (info->attrs[NL80211_ATTR_IFTYPE])
> type = nla_get_u32(info->attrs[NL80211_ATTR_IFTYPE]);
>
> - if (!rdev->ops->add_virtual_intf ||
> - !(rdev->wiphy.interface_modes & (1 << type)))
> + if (!rdev->ops->add_virtual_intf)
> return -EOPNOTSUPP;
>
> if ((type == NL80211_IFTYPE_P2P_DEVICE || type == NL80211_IFTYPE_NAN ||
> @@ -3403,6 +3402,13 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
> return err;
> }
>
> + if (!(rdev->wiphy.interface_modes & (1 << type))) {
> + if (!(type == NL80211_IFTYPE_AP_VLAN &&
> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
> + params.use_4addr))
> + return -EOPNOTSUPP;
> + }
I'm not sure you should insert this further down, rather tahn at the
place where the check was before? Why not just insert this part directly
after the piece you modified above?
johannes
next prev parent reply other threads:[~2018-11-24 22:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 11:03 [PATCH] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices Manikanta Pubbisetty
2018-11-24 18:48 ` Johannes Berg [this message]
2018-11-26 5:39 ` Manikanta Pubbisetty
2019-02-26 22:01 ` Hauke Mehrtens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ce0f8352354900cd89074bcafe6ac45c29abd78.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mpubbise@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox