From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gqloD-0002Np-WC for ath10k@lists.infradead.org; Mon, 04 Feb 2019 21:29:43 +0000 Received: by mail-pf1-x436.google.com with SMTP id b7so518055pfi.8 for ; Mon, 04 Feb 2019 13:29:41 -0800 (PST) Date: Mon, 4 Feb 2019 13:29:36 -0800 From: Brian Norris Subject: Re: [PATCH v2] ath10k: implement set_base_macaddr to fix rx-bssid mask in multiple APs conf Message-ID: <20190204212935.GA158434@google.com> References: <20190204205714.23858-1-chunkeey@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190204205714.23858-1-chunkeey@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Christian Lamparter Cc: Ben Greear , linux-wireless@vger.kernel.org, Mathias Kresin , ath10k@lists.infradead.org, Felix Fietkau Hi, On Mon, Feb 04, 2019 at 09:57:14PM +0100, Christian Lamparter wrote: > Many integrated QCA9984 WiFis in various IPQ806x platform routers > from various vendors (Netgear R7800, ZyXEL NBG6817, TP-LINK C2600, > etc.) have either blank, bogus or non-unique MAC-addresses in > their calibration data. > > As a result, OpenWrt utilizes a discouraged binary calibration data > patching method that allows to modify the device's MAC-addresses right > at the source. This is because the ath10k' firmware extracts the MAC > address from the supplied radio/calibration data and issues a response > to the ath10k linux driver. Which was designed to take the main MAC in > ath10k_wmi_event_ready(). > > Part of the "setting an alternate MAC" issue was already tackled by a > patch from Brian Norris: > commit 9d5804662ce1 > ("ath10k: retrieve MAC address from system firmware if provided") > by allowing the option to specify an alternate MAC-address with the > established device_get_mac_address() function which extracts the right > address from DeviceTree/fwnode mac-address or local-mac-address > properties and saves it for later. > > However, Ben Greear noted that the Qualcomm's ath10k firmware is liable > to not properly calculate its rx-bssid mask in this case. This can cause > issues in the popluar "multiple AP with a single ath10k instance" > configurations. > > To improve MAC address handling, Felix Fietkau suggested to call > pdev_set_base_macaddr_cmdid before bringing up the first vif and > use the first vif MAC address there. Which is in ath10k_core_start(). > > This patch implement Felix Fietkau's request to > "call pdev_set_base_macaddr_cmdid before bringing up the first vif". > The pdev_set_base_macaddr_cmdid is already declared for all devices > and version. The driver just needed the support code for this > function. > > Tested on: > QCA9880/CUS223, firmwares: 10.2.4.13-2, 10.2.4.70.44, 10.2.4-1.0-00041 > QCA9887/MR33 firmware:10.2.4-1.0-00033 > QCA4019/RT-AC58U firmware: 10.4-3.4-00104, 10.4-3.5.3-00057 > QCA9984/R7800 firmware: Candela Technologies (CT) Firmware > > BugLink: https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/014595.html > Fixes: 9d5804662ce1 ("ath10k: retrieve MAC address from system firmware if provided") > Cc: Brian Norris > Cc: Ben Greear > Cc: Felix Fietkau > Cc: Mathias Kresin > Signed-off-by: Christian Lamparter > > --- > > Changed from v1: > - removed support for obsolete, untested firmwares > - removed unsupported TLV ops > - don't error-out on unsupported platforms This doesn't break WCN3990 this time (which doesn't support this command), and I correctly hit the EOPNOTSUPP path: Tested-by: Brian Norris _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k