Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp506472ybx; Tue, 5 Nov 2019 00:53:53 -0800 (PST) X-Google-Smtp-Source: APXvYqy5Jr5egrTIkWRyhm/f+G2PUGZ8/EvKCA3zh8BsOrKGE0JOl7bd+/gLFSIkPC0elLyvqt1Z X-Received: by 2002:a05:6402:7cd:: with SMTP id u13mr2652451edy.246.1572944033214; Tue, 05 Nov 2019 00:53:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572944033; cv=none; d=google.com; s=arc-20160816; b=TcbWwadzm+7yCHRzXCMJMtWy2fKy2mztCFEDS4LA7Y8typ068jSNSmW/hbJq5jdpcu sP4z4Dl8KmAxdx9Lj8b83pp/W/DJHsqIDkEu/lqJqXEsuiqAEFjvyB6P7IlE8FRwx5gB e2RV5XRBdtICqgeOmuUWlxUhEQ9OojwIIQFaiepR5tnRHa/TJ8vvB7RIc/BKyBbksEiM 76MNXQ1u9noBJo4SCOXLA4wPX5HMCT0zfPMJUdLCfDa1JDD+VBT2Umfws+Mo6Rd1VTtT aKErua7eMpLWjet47ObB5aI2w7mSgkE8jn9xhzX4m+Mz0PM7ccWQkE/YwA8uH5aU03Lh cZiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:user-agent:in-reply-to:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YVPc0+mqquR3l7zUD0Sc0a1/wfluhM4tfIW9rRnKpZk=; b=S7MRju+/csoSM1yLuvVAHTyZHW4iVSN06m5ECPl8szYRQrS9sCz5r6wu9s5fD9hGmX yLGXyz3vXfc7htvNMH0c5jtqQlIJu0E0XgX8XYLktVduiNEYcS2CTiSEicVt1YYZ0Dpp 9AD6Zo7g2LLKU6BCx4KUC6POu2DvA+3UWYo/08YM9pk0lpDk268WaiELz8tm90VYN0lE wEf9JcDht0ZFLdTW73ew+TLiwxpCm1os7BvSmzIvzYoNeHQAo3e6kWXS+WGfCrKVGOtP odfgoSW1Ksz5gfzsw689opgBa0JROw5MQlEnVtHgXturi28a7ek5iARKdO5QXnSddQ+N WuCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XisHm7F+; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a12si12381681ejp.425.2019.11.05.00.53.19; Tue, 05 Nov 2019 00:53:53 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XisHm7F+; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729765AbfKEIxS (ORCPT + 99 others); Tue, 5 Nov 2019 03:53:18 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:29689 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729171AbfKEIxS (ORCPT ); Tue, 5 Nov 2019 03:53:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572943996; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YVPc0+mqquR3l7zUD0Sc0a1/wfluhM4tfIW9rRnKpZk=; b=XisHm7F+bV4vHt79PgEzGe2tDIqw+m1Ps92CqcL4SJb494SB+Q37e65udd3bUryfg1hU7W gamlZgnpSoYrgKkmFSB5aa/ZC35deto2p088+zOeVRvSQcj0pDCCbrs1JkrHZrr0CKtqol g2EDQFujaa0ThEfPFtpev5Du1muBt2Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-304-XUojAqkKNSezxNrM1BE4jQ-1; Tue, 05 Nov 2019 03:53:13 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0F64D107ACC2; Tue, 5 Nov 2019 08:53:12 +0000 (UTC) Received: from localhost (unknown [10.40.205.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0C57D600C4; Tue, 5 Nov 2019 08:53:06 +0000 (UTC) Date: Tue, 5 Nov 2019 09:53:05 +0100 From: Stanislaw Gruszka To: Markus Theil Cc: Lorenzo Bianconi , nbd@nbd.name, linux-wireless@vger.kernel.org Subject: Re: [PATCH] mt76: mt76x02: fix num slots in beacon config init Message-ID: <20191105085305.GA21352@redhat.com> References: <20191104150341.13896-1-markus.theil@tu-ilmenau.de> <20191104154537.GE3935@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: XUojAqkKNSezxNrM1BE4jQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, Nov 04, 2019 at 05:07:16PM +0100, Markus Theil wrote: > On 04.11.19 16:45, Lorenzo Bianconi wrote: > >> mt76x02 mmio and usb devices use a different number of beacon slots (8 > >> vs. 5). Consider this in mt76x02_init_beacon_config. > >> > >> Signed-off-by: Markus Theil > >> --- > >> drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c b/dri= vers/net/wireless/mediatek/mt76/mt76x02_beacon.c > >> index 4209209ac940..b7412953ff26 100644 > >> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c > >> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c > >> @@ -249,7 +249,7 @@ void mt76x02_init_beacon_config(struct mt76x02_dev= *dev) > >> =09mt76_set(dev, MT_BEACON_TIME_CFG, MT_BEACON_TIME_CFG_SYNC_MODE); > >> =09mt76_wr(dev, MT_BCN_BYPASS_MASK, 0xffff); > >> =20 > >> -=09for (i =3D 0; i < 8; i++) > >> +=09for (i =3D 0; i < dev->beacon_ops->nslots; i++) > >> =09=09mt76x02_mac_set_beacon(dev, i, NULL); > >> =20 > >> =09mt76x02_set_beacon_offsets(dev); > > Hi Markus, > > > > mt76x02_init_beacon_config is run just at bootstrap and it is used to c= lean all > > beacon RAM memory. It can't see any issue with the current code. > > > > Regards, > > Lorenzo > > > >> --=20 > >> 2.17.1 > >> > Hi Lorenzo, >=20 > I just thought this function should overwrite all 8192 byte beacon RAM > memory. If the loop count is set to 8 it would overwrite 8 x 1024 =3D 819= 2 > byte in the mmio case and 8 x 1638 =3D 13104 byte in the USB case. 1638 i= s > 8192 / N_BCN_SLOTS. N_BCN_SLOTS is currently 5 for USB. mt76x02_beacon.c > has no further checks for beacon_ops->nslots in the case of setting a > beacon. We do not override beacon SRAM memory in mt76x02_init_beacon_config() as bcn_idx increase only if !!dev->beacons[i], so we 8 times nullify beacon 0 . Patch is fine though, but things can be optimized more ... We possibly can skip beacon SRAM nullification at all (even if there is garbage in the memory, beacon will not be sent if blocked by MT_BCN_BYPASS_MASK =3D 0xffff). Or nullify SRAM at once. And just set proper MT_MAC_BSSID_DW1_MBEACON_N value. Stanislaw