Re: [PATCHv3 2/2] ath10k: Allow setting coverage class

[Benjamin Berg <benjamin@sipsolutions.net>]

[-- Attachment #1.1: Type: text/plain, Size: 2158 bytes --]

On Do, 2016-08-25 at 07:28 -0700, Ben Greear wrote:
> 
> On 08/25/2016 06:25 AM, Benjamin Berg wrote:
> > 
> > Unfortunately ath10k does not generally allow modifying the
> > coverage class
> > with the stock firmware and Qualcomm has so far refused to
> > implement this
> > feature so that it can be properly supported in ath10k. If we
> > however know
> > the registers that need to be modified for proper operation with a
> > higher
> > coverage class, then we can do these modifications from the driver.
> > 
> > This patch implements this hack for first generation cards which
> > are based
> > on a core that is similar to ath9k. The registers are modified in
> > place and
> > need to be re-written every time the firmware sets them. To achieve
> > this
> > the register status is verified after certain WMI events from the
> > firmware.
> > 
> > The coverage class may not be modified temporarily right after the
> > card
> > re-initializes the registers. This is for example the case during
> > scanning.
> > 
> > Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for
> > initially
> > working on a userspace support for this. This patch wouldn't have
> > been
> > possible without this documentation.
> 
> 
> 
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
> > b/drivers/net/wireless/ath/ath10k/wmi.c
> > index d246288..8ccc8cf 100644
> > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > @@ -4879,6 +4879,12 @@ exit:
> >   	return 0;
> >   }
> > 
> > +static inline void ath10k_wmi_queue_set_coverage_class_work(struct
> > ath10k *ar)
> > +{
> > +	if (ar->hw_params.hw_ops->set_coverage_class)
> > +		queue_work(ar->workqueue, &ar-
> > >set_coverage_class_work);
> > +}
> 
> Maybe this should first check to see if the user has specified a
> coverage class
> before it attempts to do any work at all?
> 
> That way, if user does not set anything, then the behaviour does not
> change
> in any significant way?

Hm, yes, adding a check there looks simple and I don't see any reason
why it wouldn't work.

Benjamin

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k