[1/3] dt-bindings: net: wireless: mt76: add power-limits node

This subnode can be used to set per-rate tx power limits either per
country code / regdomain or globally.
These limits are typically provided by the device manufacturers and are
used to limit sideband emissions and stay within regulatory limits

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 .../bindings/net/wireless/mediatek,mt76.txt   | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)

On Fri, May 29, 2020 at 06:19:27PM +0200, Felix Fietkau wrote:
> This subnode can be used to set per-rate tx power limits either per
> country code / regdomain or globally.
> These limits are typically provided by the device manufacturers and are
> used to limit sideband emissions and stay within regulatory limits

How do other WiFi chips handle this? If this is added to DT, then it 
should be common for all WiFi h/w.
 
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
>  .../bindings/net/wireless/mediatek,mt76.txt   | 47 +++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> index ab7e7a00e534..9d9ace0cfbf9 100644
> --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -36,6 +36,7 @@ Optional nodes:
>  - led: Properties for a connected LED
>    Optional properties:
>      - led-sources: See Documentation/devicetree/bindings/leds/common.txt
> +- power-limits: contains per-regdomain/channel rate power limit subnodes
>  
>  &pcie {
>  	pcie0 {
> @@ -76,3 +77,49 @@ wmac: wmac@18000000 {
>  
>  	power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
>  };
> +
> +
> +Subnodes of power-limits:
> +
> +Properties:
> +- country: One or more country codes, as used by the cfg80211 regdomain code
> +- regdomain: "FCC", "ETSI" or "JP"
> +
> +If neither country, nor regdomain is specified, the power limits node is used
> +as a fallback when no other subnode matches.
> +
> +Subnodes txpower-2g, txpower-5g:
> +
> +Properties:
> +- channels: pairs of first and last channel number
> +- cck: 4 half-dBm per-rate power limit values
> +- ofdm: 8 half-dBm per-rate power limit values
> +- mcs:
> +	sets of per-rate power limit values for 802.11n/802.11ac rates for
> +	multiple channel bandwidth settings.
> +	Each set starts with the number of channel bandwidth settings for
> +	which the rate set applies, followed by either 8 (MT7603/MT7628) or
> +	10 (all other chips) power limit values.
> +	The order of the channel bandwidth settings is: 20, 40, 80, 160 MHz.
> +
> +
> +power-limit example:
> +
> +power-limits {
> +	r0 {
> +		regdomain = "FCC";
> +		txpower-5g {
> +			r1 {
> +				channels = <36 48>;
> +				ofdm = <23 23 23 23 23 23 23 23>;
> +				mcs = <1 23 23 23 23 23 23 23 23 23 23>,
> +					  <3 22 22 22 22 22 22 22 22 22 22>;
> +			};
> +			r2 {
> +				channels = <100 181>;
> +				ofdm = <14 14 14 14 14 14 14 14>;
> +				mcs = <4 14 14 14 14 14 14 14 14 14 14>;
> +			};
> +		};
> +	};
> +};
> -- 
> 2.24.0
>

On 2020-05-29 23:26, Rob Herring wrote:
> On Fri, May 29, 2020 at 06:19:27PM +0200, Felix Fietkau wrote:
>> This subnode can be used to set per-rate tx power limits either per
>> country code / regdomain or globally.
>> These limits are typically provided by the device manufacturers and are
>> used to limit sideband emissions and stay within regulatory limits
> 
> How do other WiFi chips handle this? If this is added to DT, then it 
> should be common for all WiFi h/w.
Most devices store this data in EEPROM, and the way it's handled also
varies across different chips. QCA has EEPROM data that only provides
limits for edge channels (called "conformance test limits")
The only other example I could find of a driver that stores it in DT is
mwifiex, which uses an opaque short array of bytes that is passed to the
firmware directly.
So I don't think it makes sense to put this in the common bindings.
On the other hand, I did try to keep the format as generic and
extensible as possible, so we could always move it over from mt76 to the
common binding once we encounter another driver that needs something
like this.

- Felix