DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0046E615BE
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Erik Stromdahl <erik.stromdahl@gmail.com>
Cc:     linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
        Alagu Sankar <alagusankar@silex-india.com>
Subject: Re: [PATCH 1/6] ath10k: use clean packet headers
References: <20190409190851.4557-1-erik.stromdahl@gmail.com>
        <20190409190851.4557-2-erik.stromdahl@gmail.com>
Date:   Fri, 12 Apr 2019 15:54:03 +0300
In-Reply-To: <20190409190851.4557-2-erik.stromdahl@gmail.com> (Erik
        Stromdahl's message of "Tue, 9 Apr 2019 21:08:46 +0200")
Message-ID: <878swfe650.fsf@kamboji.qca.qualcomm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> From: Alagu Sankar <alagusankar@silex-india.com>
>
> HTC header carries junk values that may be interpreted by the firmware
> differently. Enable credit update only if flow control is enabled for
> the corresponding endpoint.
>
> PLL clock setting sequence does not mask the PLL_CONTROL
> register value. Side effect of not masking the values is not known as
> the entire pll clock setting sequence is undocumented.

One logical change per patch, please. So this should be split to two.

> Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>

Erik's s-o-b missing. 

> --- a/drivers/net/wireless/ath/ath10k/hw.c
> +++ b/drivers/net/wireless/ath/ath10k/hw.c
> @@ -814,6 +814,8 @@ static int ath10k_hw_qca6174_enable_pll_clock(struct ath10k *ar)
>  	if (ret)
>  		return -EINVAL;
>  
> +	reg_val &= ~(WLAN_PLL_CONTROL_REFDIV_MASK | WLAN_PLL_CONTROL_DIV_MASK |
> +		     WLAN_PLL_CONTROL_NOPWD_MASK);
>  	reg_val |= (SM(hw_clk->refdiv, WLAN_PLL_CONTROL_REFDIV) |
>  		    SM(hw_clk->div, WLAN_PLL_CONTROL_DIV) |
>  		    SM(1, WLAN_PLL_CONTROL_NOPWD));

The commit log mentions that there are no visible changes after this
patch. So why add it? :)

And do note that this also changes functionality for QCA6174 and QCA9377
PCI devices, so we have to be careful here.

-- 
Kalle Valo