Re: [PATCH] ath: use PRI value given by spec for fixed PRI

From: Peter Oh <poh@codeaurora.org>
To: Zefir Kurtisi <zefir.kurtisi@neratec.com>,
	Peter Oh <poh@qca.qualcomm.com>,
	ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath: use PRI value given by spec for fixed PRI
Date: Thu, 03 Sep 2015 11:04:20 -0700	[thread overview]
Message-ID: <55E88BA4.7010009@codeaurora.org> (raw)
In-Reply-To: <551BC2B1.3030002@neratec.com>

Hi Zefir,

I believe the patch below is good to be checked in since you've already 
made change in DFS.
Can you confirm it?

Thanks,
Peter

On 04/01/2015 03:04 AM, Zefir Kurtisi wrote:
> On 03/30/2015 07:57 PM, Peter Oh wrote:
>> On 03/30/2015 02:55 AM, Zefir Kurtisi wrote:
>>> [...]
>>> That's why I believe we need to
>>> be very cautious when changing it to fix / improve minor issues.
>> This patch is not for minor fix.
>> Current DFS detector fails on Japan W53 band which requires at least 50%
> of data
>> traffic during DFS certificate.
>> So this patch should apply to both of 9k and 10k.
> That is the core of my concern: you add changes to fix FCC/JP, which at
> the same
> time also affects ETSI.
>
> Our company (and maybe others) got ath9k certified for ETSI, and any
> potential
> change to the detector relevant for that domain would essentially require
> to
> re-certify.
>
> There were several patches lately added to the detector that were isolated
> to
> specific domains (like the recent updates for FCC pattern 1) which I knew
> won't
> affect the ETSI detector performance, since they touched only the FCC
> configuration but not the algorithm itself. This patch does, and that's
> why I need
> to point out that doing so might void certification efforts out there.
>
> Unfortunately, I have no good idea how to cope with it. Freezing the
> driver at the
> certified state is no option, since we all want to evolve. Having multiple
> copies
> of the detector for each regulatory domain would be an option (and
> essentially
> will happen since FCC/JP can't be covered by PRI detectors only), but
> gives
> unacceptable code duplication. Ideally we would fully separate algorithm
> from
> configuration and leave the algorithm untouched ever after, not sure how
> doable,
> though.
>
>
> As for your patch at hand, I tested it for ETSI and it does not change
> detector
> performance, therefore (please replace 16 with PRI_TOLERANCE in the macro)
>
> Acked-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

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