From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 30 16:20:00 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3B0326D for ; Tue, 30 Apr 2013 16:20:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 805D31D15 for ; Tue, 30 Apr 2013 16:20:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3UGK03D077367 for ; Tue, 30 Apr 2013 16:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3UGK0V0077366; Tue, 30 Apr 2013 16:20:00 GMT (envelope-from gnats) Resent-Date: Tue, 30 Apr 2013 16:20:00 GMT Resent-Message-Id: <201304301620.r3UGK0V0077366@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, adrian chadd Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4D29170 for ; Tue, 30 Apr 2013 16:19:04 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [69.147.83.34]) by mx1.freebsd.org (Postfix) with ESMTP id D70621D02 for ; Tue, 30 Apr 2013 16:19:04 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r3UGJ4xY012287 for ; Tue, 30 Apr 2013 16:19:04 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id r3UGJ4V6012286; Tue, 30 Apr 2013 16:19:04 GMT (envelope-from nobody) Message-Id: <201304301619.r3UGJ4V6012286@red.freebsd.org> Date: Tue, 30 Apr 2013 16:19:04 GMT From: adrian chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/178263: [ath] review the use of ic_freq / ic_ieee / ic_flags / ichan->channel X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 16:20:00 -0000 >Number: 178263 >Category: kern >Synopsis: [ath] review the use of ic_freq / ic_ieee / ic_flags / ichan->channel >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Apr 30 16:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: -HEAD >Organization: >Environment: n/a >Description: Review the use of the frequency / channel fields in ieee80211_channel and HAL_CHANNEL_INTERNAL. * check whether net80211's ieee80211_channel entry stores the real frequency (eg 900mhz, 420mhz mapping) or the underlying channel frequency; * .. and whether ic_flags shows a 900MHz channel using 2.4GHz hardware as being a 2.4GHz channel; * .. and whether ic_ieee reflects the 900MHz IEEE number, or the 2.4GHz hardware number. * Evaluate what HAL_CHANNEL_INTERNAL gets - I _think_ it gets the real channel frequency in 'channel', but we don't store the real channel IEEE number. The aim is to correctly support channel mapping for the 11n chips. I'm worried that ic_freq / ic_flags / ic_ieee is used in places where it shouldn't be. It's also a big requirement to get channel mapping 'right' on the AR9380 and later hardware, in case some vendors (eg Ubiquiti) decide to glue downconverters on the newer chips. It's possible that I'll have to extend the HAL to include this information in HAL_CHANNEL_INTERNAL and then modify a bunch of code to use HAL_CHANNEL_INTERNAL instead of ieee80211_channel when looking at what the _hardware_ programming should look like. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: