From: Kalle Valo <kvalo@kernel.org>
To: Robert Marko <robimarko@gmail.com>
Cc: davem@davemloft.net, kuba@kernel.org, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
Date: Tue, 07 Dec 2021 20:09:32 +0200 [thread overview]
Message-ID: <87lf0wjnhf.fsf@codeaurora.org> (raw)
In-Reply-To: <163890036783.24891.8718291787865192280.kvalo@kernel.org> (Kalle Valo's message of "Tue, 7 Dec 2021 18:06:09 +0000 (UTC)")
Kalle Valo <kvalo@kernel.org> writes:
> Robert Marko <robimarko@gmail.com> wrote:
>
>> Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
>> BDF-s to be extracted from the device storage instead of shipping packaged
>> API 2 BDF-s.
>>
>> This is required as MikroTik has started shipping boards that require BDF-s
>> to be updated, as otherwise their WLAN performance really suffers.
>> This is however impossible as the devices that require this are release
>> under the same revision and its not possible to differentiate them from
>> devices using the older BDF-s.
>>
>> In OpenWrt we are extracting the calibration data during runtime and we are
>> able to extract the BDF-s in the same manner, however we cannot package the
>> BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
>> the fly.
>> This is an issue as the ath10k driver explicitly looks only for the
>> board.bin file and not for something like board-bus-device.bin like it does
>> for pre-cal data.
>> Due to this we have no way of providing correct BDF-s on the fly, so lets
>> extend the ath10k driver to first look for BDF-s in the
>> board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin
>> If that fails, look for the default board file name as defined previously.
>>
>> Signed-off-by: Robert Marko <robimarko@gmail.com>
>
> Can someone review this, please? I understand the need for this, but the board
> handling is getting quite complex in ath10k so I'm hesitant.
>
> What about QCA6390 and other devices. Will they still work?
I meant QCA6174, of course. I have been working too much on ath11k.
--
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@kernel.org>
To: Robert Marko <robimarko@gmail.com>
Cc: davem@davemloft.net, kuba@kernel.org, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
Date: Tue, 07 Dec 2021 20:09:32 +0200 [thread overview]
Message-ID: <87lf0wjnhf.fsf@codeaurora.org> (raw)
In-Reply-To: <163890036783.24891.8718291787865192280.kvalo@kernel.org> (Kalle Valo's message of "Tue, 7 Dec 2021 18:06:09 +0000 (UTC)")
Kalle Valo <kvalo@kernel.org> writes:
> Robert Marko <robimarko@gmail.com> wrote:
>
>> Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
>> BDF-s to be extracted from the device storage instead of shipping packaged
>> API 2 BDF-s.
>>
>> This is required as MikroTik has started shipping boards that require BDF-s
>> to be updated, as otherwise their WLAN performance really suffers.
>> This is however impossible as the devices that require this are release
>> under the same revision and its not possible to differentiate them from
>> devices using the older BDF-s.
>>
>> In OpenWrt we are extracting the calibration data during runtime and we are
>> able to extract the BDF-s in the same manner, however we cannot package the
>> BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
>> the fly.
>> This is an issue as the ath10k driver explicitly looks only for the
>> board.bin file and not for something like board-bus-device.bin like it does
>> for pre-cal data.
>> Due to this we have no way of providing correct BDF-s on the fly, so lets
>> extend the ath10k driver to first look for BDF-s in the
>> board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin
>> If that fails, look for the default board file name as defined previously.
>>
>> Signed-off-by: Robert Marko <robimarko@gmail.com>
>
> Can someone review this, please? I understand the need for this, but the board
> handling is getting quite complex in ath10k so I'm hesitant.
>
> What about QCA6390 and other devices. Will they still work?
I meant QCA6174, of course. I have been working too much on ath11k.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2021-12-07 18:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko
2021-10-09 22:17 ` Robert Marko
2021-10-14 11:54 ` Christian Lamparter
2021-10-14 11:54 ` Christian Lamparter
2021-10-14 12:01 ` Robert Marko
2021-10-14 12:01 ` Robert Marko
2021-10-14 13:23 ` Christian Lamparter
2021-10-14 13:23 ` Christian Lamparter
2021-12-07 18:06 ` Kalle Valo
2021-12-07 18:06 ` Kalle Valo
2021-12-07 18:09 ` Kalle Valo [this message]
2021-12-07 18:09 ` Kalle Valo
2021-12-08 12:21 ` Robert Marko
2021-12-08 12:21 ` Robert Marko
2021-12-08 14:07 ` Christian Lamparter
2021-12-08 14:07 ` Christian Lamparter
2021-12-17 12:06 ` Robert Marko
2021-12-17 12:06 ` Robert Marko
2021-12-17 12:25 ` Thibaut
2021-12-17 12:25 ` Thibaut
2022-02-02 18:49 ` Robert Marko
2022-02-02 18:49 ` Robert Marko
2022-02-16 13:38 ` Robert Marko
2022-02-16 13:38 ` Robert Marko
2022-02-16 21:19 ` Christian Lamparter
2022-02-16 21:19 ` Christian Lamparter
2022-02-16 21:55 ` Thibaut
2022-02-16 21:55 ` Thibaut
2022-05-03 15:58 ` Robert Marko
2022-05-03 15:58 ` Robert Marko
2022-05-04 7:48 ` Kalle Valo
2022-05-04 7:48 ` Kalle Valo
2022-05-06 6:19 ` Kalle Valo
2022-05-06 6:19 ` 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=87lf0wjnhf.fsf@codeaurora.org \
--to=kvalo@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=robimarko@gmail.com \
/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.