From owner-freebsd-wireless@freebsd.org Sun Aug 9 16:55:36 2020 Return-Path: Delivered-To: freebsd-wireless@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4088D3B9F91 for ; Sun, 9 Aug 2020 16:55:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BPlbC2JYGz4DJ7 for ; Sun, 9 Aug 2020 16:55:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qk1-f174.google.com with SMTP id b79so6316084qkg.9 for ; Sun, 09 Aug 2020 09:55:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eDRjIfgyQ3IhWnI+cLkL8zxju9u4txtG3FWgAk3B/5A=; b=DrQHhbW4GTFdEO59V6+a8745L7ppWpmyLBoKpNIu4X+fcSKBlV+pa+PbLwVIof1jzD Pf7ccFxPcei9unoAkiy4TYUt++8aw7LKz/IiJ9Wg3I57NmQoC08HZMkcdp3J+Tu1sFjn iOBgs89UYfmlxtipu26l17BaF0utWLVdB00EjOLtLY2mNANrUMfyBiDKD1HlLhJbpZUG 17eRhz18k8tyZC/6iDnEnq2pschgY6EX+doD4IpGVbwe4r8MFQZFpwsAbPLi7sJ4HasD tMPIt37nyvw25TvYOqaiiX61M9ujOfAEi6N0+Z/AMKNgUeEABD47Fa01/ZYKVAnLCc63 gXlQ== X-Gm-Message-State: AOAM530xiO7NXP3u885qdNEd6uScqxRslHWfdf5GeIG+cUQLBIECVam1 L8KvOoXVQ3FqPfE/Az7y5fRM+tYXxg/bf5n0aMnpbw== X-Google-Smtp-Source: ABdhPJzvghkvXKgn8JwKPEFyWOxKeeapCb0emTDPv4cyPtMYemlGtIPqkftxcDOH181CZKI04e9Wc6vw8kbp5e1ltUE= X-Received: by 2002:a05:620a:1a:: with SMTP id j26mr23294330qki.183.1596992134358; Sun, 09 Aug 2020 09:55:34 -0700 (PDT) MIME-Version: 1.0 References: <083B7D36-2175-46DC-9C9A-FEA8673482E8@lists.zabbadoz.net> In-Reply-To: <083B7D36-2175-46DC-9C9A-FEA8673482E8@lists.zabbadoz.net> From: Adrian Chadd Date: Sun, 9 Aug 2020 09:55:22 -0700 Message-ID: Subject: Re: regdomain.xml [was also: - Linux wireless-regdb] To: "Bjoern A. Zeeb" Cc: freebsd-wireless X-Rspamd-Queue-Id: 4BPlbC2JYGz4DJ7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-2.15 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.99)[-0.993]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-wireless@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.21)[-0.208]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.174:from]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.174:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 09 Aug 2020 16:55:36 -0000 On Sun, 9 Aug 2020 at 08:38, Bjoern A. Zeeb wrote: > Hi, > > I=E2=80=99ll just join in on the last email in the thread not replying to > anything specific. > > Having gone through some of the stuff lately myself in order to put [1] > out (which is also includes a few things to discuss) I=E2=80=99ll try to > summarise a few things I=E2=80=99ve learnt and thought of, which confused= me > over the time: > The best way to start is by realising Sam started this by taking the ath regulatory code and breaking bits of it out into net80211. Look at sys/dev/ath/ath_hal/ath_regdomain/ or wherever I moved it. > > - SKU - what does it actually stand for? Does it really belong into > our regdomain? > It's the stock keeping unit code - it's based on the notion that NICs are sold into different markets for different purposes (country, sta/ap, laptop, etc) and so it's oriented around stockig. > > - why are the freqbands prefixes with =E2=80=9CH=E2=80=9D, =E2=80=9CF=E2= =80=9D, .. and what do > these magic letters stand for? > The amusingly line up well with what's in the ath_hal regdomain code. :-) > > - We have netbands, freqbands, and bands. None of these are actually > describing the actual frequency ranges (as the linux-db does). > Yup. Look at the ath_hal regdomain code. :-) > > - The freqbands seems to start and end on the center frequency of the > first/last chansep spaced channel. In the old days that was less > confusing I guess as to now with 4x20 for VHT80. > Yup - again, look at the ath_hal regdomain code :-) > > - I am still unclear as to where we should map channels to frequency > because we are half-hearted doing that partially for upper and lower > bounds of freqbands currently. As such I have different freqbands for > VHT20 vs. VHT40/80/160 as there are cases where there is an extra 20 > channel not part of 80s. > That's partly why I didn't wanna start VHT80+80 and VHT160 - this needs to be made less insane. > > - I=E2=80=99d love to have the freqbands actually describe the frequency > limits and have the mappings of channels within them elsewhere; I have > no idea how/where Linux is doing that. > The regdb code in linux is doing that in nl80211 somewhere. - I=E2=80=99d love to have general freqbands and groups of them independent= of > the netbands. > Same. > > - I do not actually understand what netbands are for given we have the > IEEE80211_CHAN_ set appropriately. It=E2=80=99s for simplicity later bu= t > there is a lot of duplication. That said, some of these > IEEE80211_CHAN_* flags do not actually belong to the regulatory limits > either but are an 802.11 channel description. > Again, see ath_regdomain :-) > > - This all leads to confusion currently as to how we setup > bands/channels/.. I made a mistake by accident and the list of > combinations we checked in ifconfig exploded to 350.000 for whether a > channel was valid. Clearly told me that the organisation does not seem > to be right. > Yup. ath_regdomain. :-) I argued for redoing how the atheros driver did channel representation at QCA when we were doing the 11ac work and .. well, the way I did it in net80211 to at least get something going? THat's very similar to how it's done in the QCA reference driver for earlier chips. > - I was wondering if for clarity we can break up regdomain.xml into > multiple files? > > - One thing I don=E2=80=99t like on the Linux version is that for, say ET= SI, > the information is basically copied per EU member state. I love our > reference model there. I don=E2=80=99t mind having etsi, etsi1, etsi2 if= I > can then say 20 countries it=E2=80=99s etsi2 and be done. I think that = is > something essential and good we have. > I like it, as long as the abstraction is that and we can add some per country overrides. I think there are some country differences in things. > > - I do like our more structured format a lot more than the Linux one. > > - We are lacking a few things, DFS and INDOORS and maxpower are not the > only things which matter these days. You may notice =E2=80=9Cwmmrule=3DE= TSI=E2=80=9D > in the Linux reg-db, for example. > Yeah, that, and the upcoming SAR (specific absorption rate) rules. > > - I wonder if what we actually want is a multi-layer thingy inheriting > one from another or if we want a pure-regdomain (not knowing about > channels) and more logic elsewhere which deals with putting WiFi things > into that)? > I think we should aim for a pure regdomain thing; I wouldn't mind it including things as well, and also assembling the channel list to push up to the hardware. > > > - I think it=E2=80=99ll need a bit more than simply restructuring > regdomain.xml; I think doing it will probably also need a bit more (a) > documentation on what each bit means and tries to accomplish) and (b) a > more clear separation between frequencies and restrictions and 802.11 > channels and with that a bit more downward code changes. > > - I would really love to see some of these things sorted and I=E2=80=99d = love > if the thread would stay alive. > > Just my 5cts, > Bjoern > > > [1] https://reviews.freebsd.org/D25999 > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.or= g > " >