On 9 September 2016 at 19:42, Marty Faltesek <mfalte...@google.com> wrote:
> It's blocked by the code below which I tried to ifdef out, but then it
> returns all 0's.
>
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 8b01e3e..bb8b7ec 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct
> inode *inode, struct file *file)
> int ret;
>
> mutex_lock(&ar->conf_mutex);
> -
> +#if 0
> if (ar->state != ATH10K_STATE_ON &&
> ar->state != ATH10K_STATE_UTF) {
> ret = -ENETDOWN;
> goto err;
> }
> +#endif
This won't work. The driver needs to go through ath10k_start(), i.e.
firmware must be loaded. Cal data is cooked as part of that.
You could get away with just `ifconfig wlan0 up`. You don't need to
connect or anything.
I guess the driver *could* cache the end resulting cal data when the
device is probed and re-use it in subsequent firmware boot-up attempts
(instead of re-computing it) making it available when the device is
stopped as well. Any volunteers to try *and* test if it doesn't break
anything? :)
> On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>> Hi,
>>
>> It's just in OTP? You should be able to read the OTP data without
>> needing a STA/AP up?
I would argue with the "just OTP" at least from the driver-device
protocol point of view.
Michał
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
