Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v2 3/3] wifi: ath11k: fix Tx power value during active CAC
From:   Kalle Valo <kvalo@kernel.org>
In-Reply-To: <20230912051857.2284-4-quic_adisi@quicinc.com>
References: <20230912051857.2284-4-quic_adisi@quicinc.com>
To:     Aditya Kumar Singh <quic_adisi@quicinc.com>
Cc:     <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>,
        <johannes@sipsolutions.net>,
        "Aditya Kumar Singh" <quic_adisi@quicinc.com>
User-Agent: pwcli/0.1.1-git (https://github.com/kvalo/pwcli/) Python/3.11.2
Message-ID: <169634351476.120947.13624704208026863471.kvalo@kernel.org>
Date:   Tue,  3 Oct 2023 14:31:56 +0000 (UTC)
Precedence: bulk

Aditya Kumar Singh <quic_adisi@quicinc.com> wrote:

> Tx power is fetched from firmware's pdev stats. However, during active
> CAC, firmware does not fill the current Tx power and sends the max
> initialised value filled during firmware init. If host sends this power
> to user space, this is wrong since in certain situations, the Tx power
> could be greater than the max allowed by the regulatory. Hence, host
> should not be fetching the Tx power during an active CAC.
> 
> Fix this issue by returning Tx power as 0 during active CAC since it
> is known that during CAC, there will be no transmission happening.

The returning as 0 doesn't seem to match the code. Should I change the sentence to:

"Fix this issue by returning -EAGAIN error so that the user space knows there's
no value available right now."


-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20230912051857.2284-4-quic_adisi@quicinc.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches