lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 22 Nov 2019 18:52:12 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Ramon Fontes <ramonreisfontes@...il.com>
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        linux-wireless <linux-wireless@...r.kernel.org>,
        kvalo@...eaurora.org, davem@...emloft.net
Subject: Re: [PATCH] mac80211_hwsim: set the maximum EIRP output power for
 5GHz

On Fri, 2019-11-22 at 11:19 -0300, Ramon Fontes wrote:
> > Right, so the commit log should say that it should be incremented to
> > allow regdb to work, rather than worry about ETSI specifics?
> > 
> > Or maybe this limit should just be removed entirely?
> 
> Hmm.. not sure. Perhaps we should add only one more information:
> 
> ETSI has been set the maximum EIRP output power to 36 dBm (4000 mW)
> Source: https://www.etsi.org/deliver/etsi_en/302500_302599/302502/01.02.01_60/en_302502v010201p.pdf
> 
> + The new maximum EIRP output power also allows regdb to work
> correctly when txpower is greater than 20 dBm.
> 
> Since there is no standard defining greater txpower, in my opinion we
> should keep the maximum value. What do you think?

It just feels to me like if the only restriction in the driver is
regulatory, we shouldn't have it in the driver. That's what we have the
regulatory database for.

If there's some other (physical?) restriction in the driver, sure, maybe
it should have one there, but for pure regulatory I'm not sure I see it.

That's why the pointer here to ETSI feels so strange to me.

> Do I need to submit a new patch?

I'll need to see if we can remove it, but if we can I'll do that, and
otherwise I can just commit your patch but with a changed commit
message.

Note that I just sent my final pull request for the current kernel, so
this'll probably have to wait some time.

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ