From owner-freebsd-wireless@FreeBSD.ORG Tue Aug 23 13:10:57 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 4D7FA106566C; Tue, 23 Aug 2011 13:10:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E83D58FC14; Tue, 23 Aug 2011 13:10:56 +0000 (UTC) Received: by vxh11 with SMTP id 11so100259vxh.13 for ; Tue, 23 Aug 2011 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X7GzAzHQWB099v29+ws6hN0Q0fLeiI05K55wYFgtSgY=; b=HzyeX2Zv2rZIlfEnnPmryje+/FbE65ar2udf/FCrKhtyvfwzRogPiMHsPH06miRZlR yp9WxezQAy6Ud/PqxC+39X2D/h2bk07FuUkR16qrZbtgaBuoE1Dyn/gqmd8MGJiCqFY+ CZ/M6cb1/djyezw6UNvDv6wRbYNDMwPCetQwo= MIME-Version: 1.0 Received: by 10.52.72.16 with SMTP id z16mr3737266vdu.395.1314105056270; Tue, 23 Aug 2011 06:10:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.33.49 with HTTP; Tue, 23 Aug 2011 06:10:56 -0700 (PDT) In-Reply-To: <201108231415.11981.bschmidt@freebsd.org> References: <201108231415.11981.bschmidt@freebsd.org> Date: Tue, 23 Aug 2011 21:10:56 +0800 X-Google-Sender-Auth: Y3Q5bbvxzu38hXrF46QoTK5m73w Message-ID: From: Adrian Chadd To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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 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 13:10:57 -0000 On 23 August 2011 20:15, Bernhard Schmidt wrote: >> Bernhard? > > Please stop top posting, thanks. Ok. > 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. ath generates sequence numbers ok - except for handling 11n aggregation. At that point, you need to do sequence number allocation in software. So how's the beacon code (in this example) supposed to handle it? > 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. Right. But I'm still unclear about how we could possibly handle it. (But I've been deep in this aggregation stuff, so my "big picture" handle is not quite working at the moment.) For example, with ath sequence number generation - we need to do it in software if the NIC is going to be doing 11n, otherwise we can leave it as-is. So do we somehow teach the net80211 code about the hardware capabilities? Do we add a capability _and_ a callback to enable/disable it? If we're doing 11n then we have to disable it - so net80211 has to fill in its own sequence numbers. If we're not doing 11n then the ath HAL still disables hardware sequence numbers on AR5416 and later - how do you propose we tell the driver to flip it on/off? Adrian