From: "John W. Linville" <linville@tuxdriver.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: linux-wireless@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>,
Janusz Dziedzic <janusz.dziedzic@tieto.com>,
Ming Lei <ming.lei@canonical.com>, Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH] wireless: fixup genregdb.awk for remove of antenna gain from wireless-regdb
Date: Wed, 2 Jul 2014 10:30:03 -0400 [thread overview]
Message-ID: <20140702143003.GA13564@tuxdriver.com> (raw)
In-Reply-To: <20140702001936.GQ27687@wotan.suse.de>
On Wed, Jul 02, 2014 at 02:19:36AM +0200, Luis R. Rodriguez wrote:
> On Tue, Jul 01, 2014 at 04:17:54PM -0400, John W. Linville wrote:
> > Since "wireless-regdb: remove antenna gain" was merged in the
> > wireless-regdb tree, this script has been incompatible with the
> > 'official' regulatory database. Let's fix it up.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > I think the dfs_cac stuff is still broken, since it does not account
> > for the starting offset of the flags.
>
> Indeed, but that also breaks other stuff too, because the DFS CAC stuff
> is optional it means the flags can now start at different locations, it
> also means that we need to distinguish a flag from a CAC.
>
> Here's a complex example we should test for as an example now:
>
> country US: DFS-FCC
> (2400 - 2450 @ 40), (100 mW)
> (2450 - 2500 @ 0), (100 mW), DFS, AUTO-BW
> (5170 - 5250 @ 80), (100 mW), DFS, AUTO-BW, NO-OUTDOOR
> (5250 - 5330 @ 0), (20), (60000), DFS, AUTO-BW
> (5735 - 5835 @ 80), (30)
> (57240 - 63720 @ 2160), (40)
>
> The changes below seem to address it. I think awk is too fragile to
Your patch looks almost exactly like what I was thinkg to do.
> scale well and keep us sane. A C parser exists but right now it
> ignores the DFS CAC. Having a parser is nice as it allows us to
> modify the db.txt on the fly, however parser still requires a bit
> of an update in code. If we wanted to avoid the parser all together
> we could just merge a CRDA reader at build time and require a
> a regulatory.bin file for reading instead of the db.txt. If we
> had support for that then its really only one step further from
> having full CRDA functionality upstream on the kernel, ie letting
> us read the file at run time rather than just build time. If we
> are to follow the steps from udev with its firmware loader helper
> we might as well merge CRDA upstream, in fact we could just use
> request_firmware_direct() for the reader, what remains questionable
> to me is the signing stuff, but if we already have support module
> signing checks it doesn't seem far fetched to be able to have
> request firmware verify a signature on a file, which probably
> ain't such a bad idea anyway. If we did this we'd have two options:
>
> 1) regulatory.bin reader at build time to build the static regulatory domains
> 2) the same reader code can use request the file at run time via
> request_firmware_direct() and if we added signature verification
> it can replace CRDA
>
> We'd eliminate the ASCII representation completely from the build picture
> and peg a regulatory.bin firmware to each kernel then. Thoughts?
I'll have to digest this -- needs some more discussion, for sure.
> diff --git a/net/wireless/genregdb.awk b/net/wireless/genregdb.awk
> index 40c37fc..baf2426 100644
> --- a/net/wireless/genregdb.awk
> +++ b/net/wireless/genregdb.awk
> @@ -51,32 +51,41 @@ function parse_country_head() {
>
> function parse_reg_rule()
> {
> + flag_starts_at = 7
> +
> start = $1
> sub(/\(/, "", start)
> end = $3
> bw = $5
> sub(/\),/, "", bw)
> - gain = $6
> - sub(/\(/, "", gain)
> - sub(/,/, "", gain)
> - power = $7
> - sub(/\)/, "", power)
> - sub(/,/, "", power)
> + gain = 0
> + power = $6
> # power might be in mW...
> - units = $8
> + units = $7
> + dfs_cac = 0
> +
> + sub(/\(/, "", power)
> + sub(/\),/, "", power)
> + sub(/\),/, "", units)
> sub(/\)/, "", units)
> - sub(/,/, "", units)
> - dfs_cac = $9
> +
> if (units == "mW") {
> + flag_starts_at = 8
> power = 10 * log(power)/log(10)
> + if ($8 ~ /[[:digit:]]/) {
> + flag_starts_at = 9
> + dfs_cac = $8
> + }
> } else {
> - dfs_cac = $8
> + if ($7 ~ /[[:digit:]]/) {
> + flag_starts_at = 8
> + dfs_cac = $7
> + }
> }
> - sub(/,/, "", dfs_cac)
> sub(/\(/, "", dfs_cac)
> - sub(/\)/, "", dfs_cac)
> + sub(/\),/, "", dfs_cac)
> flagstr = ""
> - for (i=8; i<=NF; i++)
> + for (i=flag_starts_at; i<=NF; i++)
> flagstr = flagstr $i
> split(flagstr, flagarray, ",")
> flags = ""
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
next prev parent reply other threads:[~2014-07-02 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 20:17 [PATCH] wireless: fixup genregdb.awk for remove of antenna gain from wireless-regdb John W. Linville
2014-07-02 0:19 ` Luis R. Rodriguez
2014-07-02 14:30 ` John W. Linville [this message]
2014-07-14 21:08 ` Luis R. Rodriguez
2014-07-14 21:13 ` Kees Cook
2014-07-14 21:33 ` Luis R. Rodriguez
2014-07-14 21:37 ` Kees Cook
2014-07-14 22:36 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140702143003.GA13564@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=janusz.dziedzic@tieto.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=ming.lei@canonical.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).