Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp612401ybc; Fri, 22 Nov 2019 10:11:50 -0800 (PST) X-Google-Smtp-Source: APXvYqxO3oF0ENpHl9DeF5BI7WGWf/xLItk82RuGvUdqSLHDBgn3s+MOdP5bE0sEajmQS1Elhz6E X-Received: by 2002:a50:a691:: with SMTP id e17mr2709846edc.151.1574446310277; Fri, 22 Nov 2019 10:11:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574446310; cv=none; d=google.com; s=arc-20160816; b=oTrwK6J4JHlB+VrVHEW7X0G6kwvpF4fdCa9eDFKGJ7iOi9RncNyqrarImWyqm2bORO tSOSgj4CMtPP97qFPF5h0xh13ymv2bvsOwGTKtr+7ZuNLaa1ZFqALpSMnooNeZbKah+k XXTAwfrulPRXQOyXOdE1HLHRfu1B0OId3Qw7bmKjnl/0rG0u6JHHZvSh+UA6HcfEton4 vCTF5oNnYPjxiperP613CSiOj/jb3Rjs1C0G5DMi5/o3se3b6I0hYqsPN1tFgktFg7jV Av8NLmVTMC5agwB1CtV8dFTWBGa4yNkUclr+LNidzhgJmrXiN5os1j6IklZoSoHBwe2b PBNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=Qns3rzCuVujgS8tdmTDem/gB5VnErlxGgvXzZbcjfAQ=; b=rjQx5DJbSifVbeABGEl+GC3+CW1cLxppNp0s+gk/H7z1q6FvrleG6EHnt1JuzprmaT 7adn7drmh7+Bj7+hBw/ioatl94j2KEMJQAuLNw/Vx+Yb1XF2wQS6W1aYiJRKJRdsCg1P 9iZCJmFuHi3bLMZ5URFxl/a137DjFAu+fKpSU2mVO2POYSLfewEWh7MntuP3k0JSlz7x aaBaUmIfHv99TVMiomj3TU/XY6DAfZF4ZMMhe34sAMTwt8y5bH6LTOE4X96blPyCNbWj fB40vqMUpXrOHL10N0/vQIkHgGuQPuquE3Zwz/3O6CqjP20wGBMNDGv0G1MoM3U0XX8W v4EQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m2si4560813ejj.70.2019.11.22.10.11.25; Fri, 22 Nov 2019 10:11:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726994AbfKVSI4 (ORCPT + 99 others); Fri, 22 Nov 2019 13:08:56 -0500 Received: from s3.sipsolutions.net ([144.76.43.62]:49088 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726975AbfKVSI4 (ORCPT ); Fri, 22 Nov 2019 13:08:56 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.3) (envelope-from ) id 1iYD6N-0002B1-Et; Fri, 22 Nov 2019 18:52:15 +0100 Message-ID: <175edd72f0cd3bc4d2c0dbd42a4570c7fb47b8fd.camel@sipsolutions.net> Subject: Re: [PATCH] mac80211_hwsim: set the maximum EIRP output power for 5GHz From: Johannes Berg To: Ramon Fontes Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-wireless , kvalo@codeaurora.org, davem@davemloft.net Date: Fri, 22 Nov 2019 18:52:12 +0100 In-Reply-To: (sfid-20191122_151928_905345_8C817F08) References: <20191108152013.13418-1-ramonreisfontes@gmail.com> <7d43bbc0dfeb040d3e0468155858c4cbe50c0de2.camel@sipsolutions.net> (sfid-20191122_151928_905345_8C817F08) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 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