Re: [PATCH] ath10k: Allow setting coverage class

From: Michal Kazior <michal.kazior@tieto.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Benjamin Berg <benjamin@sipsolutions.net>,
	Kalle Valo <kvalo@qca.qualcomm.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>,
	Sebastian Gottschall <s.gottschall@dd-wrt.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
	Simon Wunderlich <sw@simonwunderlich.de>
Subject: Re: [PATCH] ath10k: Allow setting coverage class
Date: Wed, 3 Aug 2016 09:09:31 +0200	[thread overview]
Message-ID: <CA+BoTQkbM8uQoOWhXnKp+qJXxnnvHXeW4rV_fSuy3ftzLgMsww@mail.gmail.com> (raw)
In-Reply-To: <579B71B4.7080206@candelatech.com>

On 29 July 2016 at 17:09, Ben Greear <greearb@candelatech.com> wrote:
> On 07/29/2016 07:52 AM, Benjamin Berg wrote:
[...]
>> Yeah, I am aware of the fact that the firmware may do internal resets
>> from time to time. The interesting question (and one for which I do not
>> know the answer) is whether we get a wmi or other event under all
>> conditions where the register may be rewritten due to a reset.
>>
>> The current code will re-set the register value after any wmi event
>> including debug messages. If this is not enough, then the only solution
>> might be to periodically poll the register values instead of relying on
>> a received event.
>
> You will get a dbglog event at least most of the time, so maybe that
> will be good enough.

But you need to remember you need to enable dbglog first to get these
events. I guess when coverage class is set the driver could,
internally, override dbglog mask so that these events are guaranteed
to be reported for the purpose of properly refreshing registers on
channel programming.

At that point I guess the update hook could be just placed in dbglog
handler alone instead of all over wmi_rx variants.

Michał