Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6108672yba; Tue, 14 May 2019 01:40:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwLqDmof/sgCBMf6MZVeK4G3NMSSOrDzCwY8e3XO9pol0KbULPwE8byxfFVsiIKeDM+DNLo X-Received: by 2002:aa7:93a7:: with SMTP id x7mr39539629pff.196.1557823233646; Tue, 14 May 2019 01:40:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557823233; cv=none; d=google.com; s=arc-20160816; b=bPaw+tz+h9xLQHaGfwXi2Xy3H8er3SIh1WWtjo8oRBaOc+rLuBhBDKb5nKedhKhP1S LPLJB39kzFl2TuY0Jn1r+uMiFJHvOertIpl5Bi2E3As3Fv15QKi1uN6Hfbh81lW+jyfE 3Fzhi3kKyNhWZk5CzMy1U8woPFHlws3xf8Cgr7cyE3c+lB/WOGMgBmjWrSKzme1yabIf Ndp2w6Ps0PWw1/zntWnV12RziuKiGsI4sSIbrZRaH3oHJ26vpHqCnxU+FmRBzihQHYkh mippVYqlbzUTfKM+crchl7srWu5amf89sX1YR9Ia0LWNL4mkdypaZdm1tljWF16Q95we Ullg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=v2OfPbNM7R35IKxP39eBfSFib0DrylYcE75g+5xFB7I=; b=M5+u8lZH+Iq9Z3NEI8pp1U3dn6c55/CjuIyeZ89wBgGhGRNTD7YNbdoC8gF/z7C3g2 U5YAtDfnYHNUPBT7N1xl7bAv4woV/6gvORzZ2+RvOtPg20Q4hnNsElw3OCKB83H6EVue uQkff4AjGFaGE66yde3AMtXnqfaOqtZ+w5Alzb8g/pQgDZOmJD1JTDq217aU6CUsKnwW OYdGkOK4950DBTfelsfeAXfKIA/I0VzJHia85qR9zFEc6/rAc61r+suvRS8sWkQPduey MulSlN/gA+HqphxSrCDH4lPd2Sw+4rSyQAwKshl+OsClQfjnHPtyLmo+67wglTlRcfPL SriQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q86si19969146pfi.197.2019.05.14.01.40.18; Tue, 14 May 2019 01:40:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726143AbfENIjC (ORCPT + 99 others); Tue, 14 May 2019 04:39:02 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:39852 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725985AbfENIjC (ORCPT ); Tue, 14 May 2019 04:39:02 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hQSxh-0006YZ-0N; Tue, 14 May 2019 10:39:01 +0200 Message-ID: Subject: Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices From: Johannes Berg To: Manikanta Pubbisetty Cc: linux-wireless@vger.kernel.org Date: Tue, 14 May 2019 10:38:59 +0200 In-Reply-To: <1557307533-5795-1-git-send-email-mpubbise@codeaurora.org> References: <1557307533-5795-1-git-send-email-mpubbise@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote: > > +++ b/net/mac80211/util.c > @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata, > } > > /* Always allow software iftypes */ > - if (local->hw.wiphy->software_iftypes & BIT(iftype)) { > + if (local->hw.wiphy->software_iftypes & BIT(iftype) || > + (iftype == NL80211_IFTYPE_AP_VLAN && > + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) { > if (radar_detect) > return -EINVAL; Shouldn't this check if 4addr is actually enabled too, like here: > case NETDEV_PRE_UP: > - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) > + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) && > + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN && > + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP && > + wdev->use_4addr)) > return notifier_from_errno(-EOPNOTSUPP); ? Or is there some reason it doesn't matter? > @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) > return err; > } > > + if (!(rdev->wiphy.interface_modes & (1 << type)) && > + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr && > + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP)) > + return -EOPNOTSUPP; > + I also wonder if we shouldn't go "all in" and actually make the check something like check_interface_allowed(iftype, 4addr): if (iftype == AP_VLAN && 4addr) return wiphy.flags & WIPHY_FLAG_4ADDR_AP; else return wiphy.interface_modes & BIT(iftype); i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN interfaces", rather than "also allow it in this case". That would seem like the clearer semantics to me? johannes