accessing ath10k calibration data

Marty Faltesek mfaltesek at google.com
Mon Sep 12 12:47:59 PDT 2016


On Mon, Sep 12, 2016 at 4:50 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek at 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.

This does not work:

hexdump: ./kernel/debug/ieee80211/phy1/ath10k/cal_data: Network is down

But it works after starting the AP. Are you sure about what you said?


>
> 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? :)

This might break what we are trying to accomplish, which is read the
calibration data
and search for mis-calibrated hardware, and if found, apply a fix.

>
>
>> On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd <adrian at 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ł



More information about the ath10k mailing list