All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Christian Lamparter <chunkeey@gmail.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
	Ansuel Smith <ansuelsmth@gmail.com>
Subject: Re: [PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem
Date: Mon, 01 Nov 2021 16:25:10 +0200	[thread overview]
Message-ID: <87lf280x89.fsf@codeaurora.org> (raw)
In-Reply-To: <3aebb711-dc45-3cbf-43cb-12f59909baf0@gmail.com> (Christian Lamparter's message of "Thu, 28 Oct 2021 20:50:13 +0200")

Christian Lamparter <chunkeey@gmail.com> writes:

> On 28/10/2021 13:52, Kalle Valo wrote:
>
>>>>>
>>>>> v1 -> v2:
>>>>> 	- use %zu and %u in the format string for size_t
>>>>>             and u32 types (catched by the "kernel test robot").
>>>>> 	- reworded commit message + successfully tested on QCA9880v2
>>>>>
>>>>> I placed the nvmem code in front of the current "file" method
>>>>> (firmware_request). Reason is that this makes it easier for me
>>>>> to test it. If needed it can be moved to a different place.
>>>>
>>>> Looks good to me. Before I apply this, I want to mention to that I have
>>>> had a long in my deferred queue related two patchsets:
>>>
>>>
>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-1-ansuelsmth@gmail.com/
>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-2-ansuelsmth@gmail.com/
>>>
>>> Oh ok, serves me right for not looking thoroughly googling this first.
>>> Alban Bedel and Ansuel's work made this nvmem all possible. And indeed,
>>> the second patch here looks eerie similar.
>>>
>>> Do you want to go with his two patches instead?
>>
>> I would prefer to take your patch.
>
> Ok.
>
>>> I'll change mine, so it just consists of the cal_mode for the older
>>> QCA9880v2,QCA9887 and add the -EPROBE_DEFER handling. This
>>> -EPROBE_DEFER only ever comes up with the Meraki gear. This is because
>>> Meraki likes putting the MACs-Values into SoC-connected AT24
>>> eeproms-chips. Everyone else just have them in a proper FLASH
>>> partition. Though, this's usually nothing more than adding the
>>> following line:
>>>
>>> if (ret == -EPROBER_DEFER)
>>> 	return ret;
>>
>> So I'll drop this version and wait for v3?
>
> I guess that "waiting for v3" won't be necessary in this case.
> If @Ansuel doesn't voice any concerns, you might as well just
> apply v2.

Ok, I took the v2 now. Thanks for helping out, I appreciate it!

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

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

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Christian Lamparter <chunkeey@gmail.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
	Ansuel Smith <ansuelsmth@gmail.com>
Subject: Re: [PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem
Date: Mon, 01 Nov 2021 16:25:10 +0200	[thread overview]
Message-ID: <87lf280x89.fsf@codeaurora.org> (raw)
In-Reply-To: <3aebb711-dc45-3cbf-43cb-12f59909baf0@gmail.com> (Christian Lamparter's message of "Thu, 28 Oct 2021 20:50:13 +0200")

Christian Lamparter <chunkeey@gmail.com> writes:

> On 28/10/2021 13:52, Kalle Valo wrote:
>
>>>>>
>>>>> v1 -> v2:
>>>>> 	- use %zu and %u in the format string for size_t
>>>>>             and u32 types (catched by the "kernel test robot").
>>>>> 	- reworded commit message + successfully tested on QCA9880v2
>>>>>
>>>>> I placed the nvmem code in front of the current "file" method
>>>>> (firmware_request). Reason is that this makes it easier for me
>>>>> to test it. If needed it can be moved to a different place.
>>>>
>>>> Looks good to me. Before I apply this, I want to mention to that I have
>>>> had a long in my deferred queue related two patchsets:
>>>
>>>
>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-1-ansuelsmth@gmail.com/
>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-2-ansuelsmth@gmail.com/
>>>
>>> Oh ok, serves me right for not looking thoroughly googling this first.
>>> Alban Bedel and Ansuel's work made this nvmem all possible. And indeed,
>>> the second patch here looks eerie similar.
>>>
>>> Do you want to go with his two patches instead?
>>
>> I would prefer to take your patch.
>
> Ok.
>
>>> I'll change mine, so it just consists of the cal_mode for the older
>>> QCA9880v2,QCA9887 and add the -EPROBE_DEFER handling. This
>>> -EPROBE_DEFER only ever comes up with the Meraki gear. This is because
>>> Meraki likes putting the MACs-Values into SoC-connected AT24
>>> eeproms-chips. Everyone else just have them in a proper FLASH
>>> partition. Though, this's usually nothing more than adding the
>>> following line:
>>>
>>> if (ret == -EPROBER_DEFER)
>>> 	return ret;
>>
>> So I'll drop this version and wait for v3?
>
> I guess that "waiting for v3" won't be necessary in this case.
> If @Ansuel doesn't voice any concerns, you might as well just
> apply v2.

Ok, I took the v2 now. Thanks for helping out, I appreciate it!

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  parent reply	other threads:[~2021-11-01 14:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-16 23:46 [PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem Christian Lamparter
2021-10-16 23:46 ` Christian Lamparter
2021-10-28  8:58 ` Kalle Valo
2021-10-28  8:58   ` Kalle Valo
2021-10-28 11:31   ` Christian Lamparter
2021-10-28 11:31     ` Christian Lamparter
2021-10-28 11:39     ` Ansuel Smith
2021-10-28 11:39       ` Ansuel Smith
2021-10-28 11:52     ` Kalle Valo
2021-10-28 11:52       ` Kalle Valo
2021-10-28 18:50       ` Christian Lamparter
2021-10-28 18:50         ` Christian Lamparter
2021-10-28 18:57         ` Ansuel Smith
2021-10-28 18:57           ` Ansuel Smith
2021-10-28 20:29           ` new "[1/2] ath10k: Try to get mac-address from dts" Christian Lamparter
2021-10-28 20:29             ` Christian Lamparter
2021-10-28 20:35             ` Ben Greear
2021-10-28 20:35               ` Ben Greear
2021-10-28 20:38             ` Ansuel Smith
2021-10-28 20:38               ` Ansuel Smith
2021-11-01 14:25         ` Kalle Valo [this message]
2021-11-01 14:25           ` [PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem Kalle Valo
2021-11-01 14:17 ` Kalle Valo
2021-11-01 14:17   ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lf280x89.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=ansuelsmth@gmail.com \
    --cc=ath10k@lists.infradead.org \
    --cc=chunkeey@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.