On Fri, 29 Mar 2024 at 18:24, Krzysztof Kozlowski
wrote:
>
> Merging
> ===
> All further patches depend on the first patch. Everything could go via
> one tree, e.g. MMC, or the cleanup patches removing owner would wait a
> cycle.
Patch 1 applied for next, thanks!
I can certainly pick the re
On 30.03.2024 7:25 PM, Krzysztof Kozlowski wrote:
> On 28/03/2024 18:39, Marc Gonzalez wrote:
>> The ath10k driver waits for an "MSA_READY" indicator
>> to complete initialization. If the indicator is not
>> received, then the device remains unusable.
>>
>> cf. ath10k_qmi_driver_event_work()
>>
>>
On 02/04/2024 16:34, Konrad Dybcio wrote:
> On 30.03.2024 7:25 PM, Krzysztof Kozlowski wrote:
>
>> On 28/03/2024 18:39, Marc Gonzalez wrote:
>>
>>> The ath10k driver waits for an "MSA_READY" indicator
>>> to complete initialization. If the indicator is not
>>> received, then the device remains unu
On Tue, 2 Apr 2024 at 18:31, Marc Gonzalez wrote:
>
> On 02/04/2024 16:34, Konrad Dybcio wrote:
>
> > On 30.03.2024 7:25 PM, Krzysztof Kozlowski wrote:
> >
> >> On 28/03/2024 18:39, Marc Gonzalez wrote:
> >>
> >>> The ath10k driver waits for an "MSA_READY" indicator
> >>> to complete initializatio
repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
tags/ath-next-20240402
for you to fetch changes up to f09e3b774fe806ee0b1f2bb69771e8c29961e40a:
wifi: ath9k: eeprom: fix sparse endian warnings (2024-03-25 12:5
x/kernel/git/kvalo/ath (2024-03-05 20:57:28
> +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
> tags/ath-next-20240402
>
> for you to fetch changes up to f09e3b774fe806ee0b1f2bb69771e8c29961e40a:
>
&g
On 4/2/2024 8:55 AM, Dmitry Baryshkov wrote:
> I'd say, we should take a step back and actually verify how this was
> handled in the vendor kernel.
(error handling and other non-QMI code removed from the following for
readability)
In ath10k we unconditionally call the following in
ath10k_qmi_eve
On 02.04.2024 18:55, Dmitry Baryshkov wrote:
I'd say, we should take a step back and actually verify how this was
handled in the vendor kernel.
AFAIK there is no such thing in vendor kernel driver for this, as
this startup procedure is likely handled entirely in userspace in
cnss_daemon.
B
On Tue, 2 Apr 2024 at 21:22, Jeff Johnson wrote:
>
> On 4/2/2024 8:55 AM, Dmitry Baryshkov wrote:
> > I'd say, we should take a step back and actually verify how this was
> > handled in the vendor kernel.
>
> (error handling and other non-QMI code removed from the following for
> readability)
>
>
On Tue, 2 Apr 2024 at 21:25, Alexey Minnekhanov
wrote:
>
>
>
> On 02.04.2024 18:55, Dmitry Baryshkov wrote:
> > I'd say, we should take a step back and actually verify how this was
> > handled in the vendor kernel.
>
>
> AFAIK there is no such thing in vendor kernel driver for this, as
> this star
On 4/2/2024 11:25 AM, Alexey Minnekhanov wrote:
>
>
> On 02.04.2024 18:55, Dmitry Baryshkov wrote:
>> I'd say, we should take a step back and actually verify how this was
>> handled in the vendor kernel.
>
>
> AFAIK there is no such thing in vendor kernel driver for this, as
> this startup proc
On 3/29/2024 9:47 PM, Dmitry Baryshkov wrote:
> On Wed, 6 Mar 2024 at 10:16, Dmitry Baryshkov
> wrote:
>>
>> On WCN3990 platforms actual firmware, wlanmdsp.mbn, is sideloaded to the
>> modem DSP via the TQFTPserv. These MBN files are signed by the device
>> vendor, can only be used with the partic
On 3/29/2024 9:48 PM, Dmitry Baryshkov wrote:
> On Tue, 30 Jan 2024 at 08:47, Dmitry Baryshkov
> wrote:
>>
>> The ath10k driver fails to properly handle fallback from board-2.bin to
>> board.bin for WCN3990 cards. This happens because the
>> ath10k_hw_params_list doesn't include .fw.board* paramet
On 30/03/2024 23:04, Marc Gonzalez wrote:
> On 30/03/2024 19:23, Krzysztof Kozlowski wrote:
>
>> On 30/03/2024 19:20, Krzysztof Kozlowski wrote:
>>
>>> On 28/03/2024 18:36, Marc Gonzalez wrote:
>>>
The ath10k driver waits for an "MSA_READY" indicator
to complete initialization. If the in
14 matches
Mail list logo
