From owner-freebsd-wireless@FreeBSD.ORG Tue Aug 23 12:15:21 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65F81106564A; Tue, 23 Aug 2011 12:15:21 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C04F38FC12; Tue, 23 Aug 2011 12:15:20 +0000 (UTC) Received: by bkat8 with SMTP id t8so46775bka.13 for ; Tue, 23 Aug 2011 05:15:19 -0700 (PDT) Received: by 10.204.157.8 with SMTP id z8mr1502732bkw.145.1314101718969; Tue, 23 Aug 2011 05:15:18 -0700 (PDT) Received: from jessie.localnet (p5B2EEC4B.dip0.t-ipconnect.de [91.46.236.75]) by mx.google.com with ESMTPS id o20sm45683bku.10.2011.08.23.05.15.16 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 05:15:16 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Tue, 23 Aug 2011 14:15:11 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; i686; ; ) References: In-Reply-To: X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201108231415.11981.bschmidt@freebsd.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kang Yin Su , freebsd-wireless@freebsd.org Subject: Re: AR5416 beacon issue. X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:15:21 -0000 On Tuesday, August 23, 2011 13:49:16 Adrian Chadd wrote: > I think we'll need some review/testing of that patch before we commit > it to -HEAD. > That, and I'd like to actually document what the drivers are supposed > to do with respect to hardware generated sequence numbers. > > Bernhard? Please stop top posting, thanks. You can't over-simplify here. Some HW supports generating seqnos, some other don't and yet again other overwrites it anyways. What you really need is a per-case decision. If the hardware is able to generate seqnos correctly (which afaik ath is) then use it. If the generated numbers are wrong for whatever reason, then try to use those generated in software. What you can generalize is, if the HW does something wrong (or not 100% correct) try to use SW as a fallback. See the beacon miss implementation in SW as an example, it is only used for the multiple VAP case, otherwise the HW function itself is used. -- Bernhard