From owner-freebsd-arch@FreeBSD.ORG Mon Aug 8 13:33:52 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B22E106566C; Mon, 8 Aug 2011 13:33:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F37208FC08; Mon, 8 Aug 2011 13:33:51 +0000 (UTC) Received: by vws18 with SMTP id 18so2669974vws.13 for ; Mon, 08 Aug 2011 06:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U2bjp+SweJu98fJkfFXHlogIAw794d1M8WMqa8n2j0Q=; b=HtIR+05V+Ea7+YPabtQTbiqpKdXb07FLu2b/NWFKSWeJ77DN2waSUWRFUxnRdh714B ta+Sp48QUaUabNg8o5Ldj0Z6M2LIQZaGjMviWvCF7YYKIzGChdrNDniYL7CcTawC560x +0Ai/ru04VgW6Jxe9e62UMzWE+fO6ypLeGOHY= MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr5690701vdg.296.1312810431344; Mon, 08 Aug 2011 06:33:51 -0700 (PDT) Received: by 10.52.157.193 with HTTP; Mon, 8 Aug 2011 06:33:51 -0700 (PDT) In-Reply-To: References: <201108081525.21563.bschmidt@freebsd.org> Date: Mon, 8 Aug 2011 21:33:51 +0800 Message-ID: From: Adrian Chadd To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFQ] net80211 regulatory changes: what I'd like to see before 9.0-RELEASE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:33:52 -0000 But to be clear - the SKU will only be used for that. Regulatory decisions will be based on the ISOCC and regdomain entry chosen. How about instead, I: * maintain regdomain.xml entries by name (eg FCC, ETSI, etc); * index regulatory domain by a regdomain "key", which is just an integer value which only has meaning in regdomain.xml - ie, replace how sku values are used in regdomain.xml (as the key) with "regdomain value"; * isocc entries in regdomain.xml have a "default" regulatory domain entry, as they do now. That way you can have multiple regdomain entries and you can choose whichever you want? Adrian On 8 August 2011 21:31, Adrian Chadd wrote: > On 8 August 2011 21:25, Bernhard Schmidt wrote: > >> We've discussed this on IRC already, though to mention it again what I >> >> really like to get rid of is all the SKU stuff from the regdomain.xml. This >> is >> >> specific to ath(4) and ath(4) only. > > Yup, I agree. ath/ath_hal can export a default country code for the given SKU. > The only reason I'd maintain the SKU is so tools that currently expose > that value keep working (ie, to read the EEPROM value from the NIC.) > > But it won't be used anywhere else for configuration/ > >> Using the isocc as the index is correct and really the way to go, but it >> >> might not serve some corner cases that well. Imagine someone wants >> >> to set a regdomain and not a country (we DO support this currently), >> >> how do want to express that in regdomain.xml? Adding a dummy isocc >> >> for each regdomain (FCC, ETSI, ..)? Maybe we should use (isocc,regdomain) >> >> as the index, so it is possible to use issoc=0,regdomain={FCC,ETSI,..} >> >> for the mentioned case. > > You'd just create or use a NONE ISOCC, and set your regulatory domain > to whatever. > > The ISO CC is just a key to find a default regulatory domain. Some > countries may share the same regulatory domain because they (for > example) implement 100% of the USA FCC rules. But many won't, so I > think we'll likely see something more like CRDA where each country > gets enumerated. > > There'll also (for now) be custom SKUs/regulatory domains - > specifically to drive the net80211ath/ath_hal GSM configuration > (900mhz.) net80211 handles 900mhz frequencies. The SKU choice "tells" > the ath/hal code to use the relevant channel mapping. That's the main > reason I don't want to yet get rid of SKUs. I can worry about that > part later. > > > > Adrian >