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 <[email protected]>
---
drivers/net/wireless/ath/ath10k/core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 2f9be182fbfb..20a448e099d8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1182,6 +1182,7 @@ static int ath10k_fetch_cal_file(struct ath10k *ar)
static int ath10k_core_fetch_board_data_api_1(struct ath10k *ar, int bd_ie_type)
{
const struct firmware *fw;
+ char boardname[100];
if (bd_ie_type == ATH10K_BD_IE_BOARD) {
if (!ar->hw_params.fw.board) {
@@ -1189,9 +1190,16 @@ static int ath10k_core_fetch_board_data_api_1(struct ath10k *ar, int bd_ie_type)
return -EINVAL;
}
+ scnprintf(boardname, sizeof(boardname), "board-%s-%s.bin",
+ ath10k_bus_str(ar->hif.bus), dev_name(ar->dev));
+
ar->normal_mode_fw.board = ath10k_fetch_fw_file(ar,
ar->hw_params.fw.dir,
- ar->hw_params.fw.board);
+ boardname);
+ if (IS_ERR(ar->normal_mode_fw.board))
+ ar->normal_mode_fw.board = ath10k_fetch_fw_file(ar,
+ ar->hw_params.fw.dir,
+ ar->hw_params.fw.board);
if (IS_ERR(ar->normal_mode_fw.board))
return PTR_ERR(ar->normal_mode_fw.board);
--
2.33.0
On 10/10/2021 00:17, Robert Marko 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 <[email protected]>
> ---
As mentioned in Robert's OpenWrt Pull request:
https://github.com/openwrt/openwrt/pull/4679
It looks like the data comes from an mtd-partition parser.
So the board data takes an extra detour through userspace
for this.
Maybe it would be great, if that BDF (and likewise pre-cal)
files could be fetched via an nvmem-consumer there?
(Kalle: like the ath9k-nvmem patches)
This would help with many other devices as well, since currently
in OpenWrt all pre-cal data has to be extracted by userspace
helpers, while it could be easily accessible through nvmem.
What do you think?
Cheers,
Christian
On Thu, 14 Oct 2021 at 13:54, Christian Lamparter <[email protected]> wrote:
>
> On 10/10/2021 00:17, Robert Marko 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 <[email protected]>
> > ---
>
> As mentioned in Robert's OpenWrt Pull request:
> https://github.com/openwrt/openwrt/pull/4679
>
> It looks like the data comes from an mtd-partition parser.
> So the board data takes an extra detour through userspace
> for this.
>
> Maybe it would be great, if that BDF (and likewise pre-cal)
> files could be fetched via an nvmem-consumer there?
> (Kalle: like the ath9k-nvmem patches)
Christian, in this case, NVMEM wont work as this is not just read from
an MTD device, it first needs to be parsed from the MikroTik TLV, and
then decompressed as they use LZO with RLE to compress the caldata
and BDF-s.
>
> This would help with many other devices as well, since currently
> in OpenWrt all pre-cal data has to be extracted by userspace
> helpers, while it could be easily accessible through nvmem.
Yeah, for non-MikroTik stuff pre-cal data via NVMEM would be great.
Regards,
Robert
>
> What do you think?
>
> Cheers,
> Christian
Robert Marko <[email protected]> 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 <[email protected]>
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?
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Kalle Valo <[email protected]> writes:
> Robert Marko <[email protected]> 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 <[email protected]>
>
> 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
On Tue, 7 Dec 2021 at 19:06, Kalle Valo <[email protected]> wrote:
>
> Robert Marko <[email protected]> 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 <[email protected]>
>
> 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?
Hi Kalle,
everything else should just continue working as before unless the
board-bus-device.bin file
exists it will just use the current method to fetch the BDF.
Also, this only applies to API1 BDF-s.
We are really needing this as currently there are devices with the
wrong BDF being loaded as
we have no way of knowing where MikroTik changed it and dynamic
loading would resolve
all of that since they are one of the rare vendors that embed the
BDF-s next to calibration data.
Regards,
Robert
>
> --
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
On 08/12/2021 13:21, Robert Marko wrote:
> On Tue, 7 Dec 2021 at 19:06, Kalle Valo <[email protected]> wrote:
>>
>> Robert Marko <[email protected]> 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 <[email protected]>
>>
>> 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?
> Hi Kalle,
> everything else should just continue working as before unless the
> board-bus-device.bin file
> exists it will just use the current method to fetch the BDF.
>
> Also, this only applies to API1 BDF-s.
>
> We are really needing this as currently there are devices with the
> wrong BDF being loaded as
> we have no way of knowing where MikroTik changed it and dynamic
> loading would resolve
> all of that since they are one of the rare vendors that embed the
> BDF-s next to calibration data.
Isn't the only user of this the non-upstreamable rb_hardconfig
mikrotik platform driver? So, in your case the devices in question
needs to setup a detour through the userspace firmware (helper+scripts)
to pull on the sysfs of that mikrotik platform driver? Wouldn't it
be possible to do this more directly?
Cheers,
Christian
On Wed, 8 Dec 2021 at 15:07, Christian Lamparter <[email protected]> wrote:
>
> On 08/12/2021 13:21, Robert Marko wrote:
> > On Tue, 7 Dec 2021 at 19:06, Kalle Valo <[email protected]> wrote:
> >>
> >> Robert Marko <[email protected]> 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 <[email protected]>
> >>
> >> 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?
> > Hi Kalle,
> > everything else should just continue working as before unless the
> > board-bus-device.bin file
> > exists it will just use the current method to fetch the BDF.
> >
> > Also, this only applies to API1 BDF-s.
> >
> > We are really needing this as currently there are devices with the
> > wrong BDF being loaded as
> > we have no way of knowing where MikroTik changed it and dynamic
> > loading would resolve
> > all of that since they are one of the rare vendors that embed the
> > BDF-s next to calibration data.
>
> Isn't the only user of this the non-upstreamable rb_hardconfig
> mikrotik platform driver? So, in your case the devices in question
> needs to setup a detour through the userspace firmware (helper+scripts)
> to pull on the sysfs of that mikrotik platform driver? Wouldn't it
> be possible to do this more directly?
Yes, its the sole current user as its the only vendor shipping the BDF
as part of the
factory data and not like a userspace blob.
I don't see how can it be more direct, its the same setup as when
getting pre-cal
data for most devices currently.
I am adding Thibaut who is the author of the platform driver.
Regards,
Robert
>
> Cheers,
> Christian
> Le 17 déc. 2021 à 13:06, Robert Marko <[email protected]> a écrit :
>
> On Wed, 8 Dec 2021 at 15:07, Christian Lamparter <[email protected]> wrote:
>>
>> Isn't the only user of this the non-upstreamable rb_hardconfig
>> mikrotik platform driver?
The driver could be upstreamed if desirable.
Yet I think it’s quite orthogonal to having the possibility to dynamically load a different BDF via API 1 for each available radio, which before this patch couldn’t be done and is necessary for this particular hardware.
>> So, in your case the devices in question
>> needs to setup a detour through the userspace firmware (helper+scripts)
>> to pull on the sysfs of that mikrotik platform driver? Wouldn't it
>> be possible to do this more directly?
>
> Yes, its the sole current user as its the only vendor shipping the BDF
> as part of the
> factory data and not like a userspace blob.
>
> I don't see how can it be more direct, its the same setup as when
> getting pre-cal
> data for most devices currently.
Indeed, not sure how it could be more direct than it already is. I’m open to suggestions though.
> I am adding Thibaut who is the author of the platform driver.
Best,
Thibaut
On Wed, 16 Feb 2022 at 22:55, Thibaut <[email protected]> wrote:
>
> Hi,
>
> > Le 16 févr. 2022 à 22:19, Christian Lamparter <[email protected]> a écrit :
> >
> > Hi,
> >
> > On 16/02/2022 14:38, Robert Marko wrote:
> >> Silent ping,
> >> Does anybody have an opinion on this?
> >
> > As a fallback, I've cobbled together from the old scripts that
> > "concat board.bin into a board-2.bin. Do this on the device
> > in userspace on the fly" idea. This was successfully tested
> > on one of the affected devices (MikroTik SXTsq 5 ac (RBSXTsqG-5acD))
> > and should work for all MikroTik.
> >
> > "ipq40xx: dynamically build board-2.bin for Mikrotik"
> > <https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=52f3407d94da62b99ba6c09f3663464cccd29b4f>
> > (though I don't think this link will stay active for
> > too long.)
>
> IMHO Robert’s patch addresses an actual bug in ath10k whereby the driver sends the same devpath for two different devices when requesting board-1 BDF, which doesn’t seem right.
>
> Your proposal is less straightforward than using unmodified board-1 data (as could be done if the above bug did not occur) and negates the previous efforts not to store this data on flash (using instead the kernel’s documented firmware sysfs loading facility - again possible without the above issue).
>
> HTH
> T-Bone
Kalle, any chance of reviewing this?
It just brings the board data in line with caldata as far as naming goes.
Regards,
Robert
Robert Marko <[email protected]> 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 <[email protected]>
> Signed-off-by: Kalle Valo <[email protected]>
Patch applied to ath-next branch of ath.git, thanks.
f2a7064a78b2 ath10k: support bus and device specific API 1 BDF selection
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches