regdomain.xml [was also: - Linux wireless-regdb]

[Adrian Chadd]

On Sun, 9 Aug 2020 at 08:38, Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net>
wrote:

> Hi,
>
> I’ll 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’ll try to
> summarise a few things I’ve 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 “H”, “F”, .. 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’d 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’d 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’s for simplicity later but
> 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’t like on the Linux version is that for, say ETSI,
> the information is basically copied per EU member state.  I love our
> reference model there.  I don’t mind having etsi, etsi1, etsi2 if I
> can then say 20 countries it’s 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 “wmmrule=ETSI”
> 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’ll 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’d love
> if the thread would stay alive.
>
> Just my 5cts,
> Bjoern
>
>
> [1] https://reviews.freebsd.org/D25999
> _______________________________________________
> freebsd-wireless at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe at freebsd.org
> "
>