Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <735c1318-2a6d-4247-8220-868f63f08578@quicinc.com>
Date:   Wed, 4 Oct 2023 07:39:44 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] wifi: ath11k: fix Tx power value during active CAC
Content-Language: en-US
To:     Kalle Valo <kvalo@kernel.org>
CC:     <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
References: <20230912051857.2284-4-quic_adisi@quicinc.com>
 <169634351476.120947.13624704208026863471.kvalo@kernel.org>
From:   Aditya Kumar Singh <quic_adisi@quicinc.com>
In-Reply-To: <169634351476.120947.13624704208026863471.kvalo@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/3/23 20:01, Kalle Valo wrote:
> 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."
Oops. Looks like only in commit message its still zero. Its changed to 
return -EAGAIN in code.

+	if (test_bit(ATH11K_CAC_RUNNING, &ar->dev_flags)) {
+		mutex_unlock(&ar->conf_mutex);
+		return -EAGAIN;
+	}

So could you just rectify while applying or should I resend?