[PATCH] ath10k: support bus and device specific API 1 BDF selection

[PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

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>
---
 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Christian Lamparter]

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 <robimarko@gmail.com>
> ---

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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

On Thu, 14 Oct 2021 at 13:54, Christian Lamparter <chunkeey@gmail.com> 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 <robimarko@gmail.com>
> > ---
>
> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Christian Lamparter]

On 14/10/2021 14:01, Robert Marko wrote:
> On Thu, 14 Oct 2021 at 13:54, Christian Lamparter <chunkeey@gmail.com> 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 <robimarko@gmail.com>
>>> ---
>>
>> 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.

For more context here (it's unrelated to the patch):
There is more custom code than just the mtd splitter.
I do fear that this could be turning into a dreaded "separation between
mechanism vs policy"-proxy discussion with that in-kernel LZOR
decompressor/extractor and the way that the board-data then has be
rerouted through user-space back to ath10k.

---

As for the proposed feature: Yeah, back in 2017/2018-ish, I would have
really loved to have this "load separate board-1 based on device-location".
Instead the QCA4019's board-2.bin is now bigger than the device's
firmware itself. From what I can see, there are also more outstanding
board-2.bin merge requests too, though some those are updates.

Cheers,
Christian

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Kalle Valo]

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?

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20211009221711.2315352-1-robimarko@gmail.com/

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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Kalle Valo]

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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

On Tue, 7 Dec 2021 at 19:06, Kalle Valo <kvalo@kernel.org> wrote:
>
> 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?
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/20211009221711.2315352-1-robimarko@gmail.com/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Christian Lamparter]

On 08/12/2021 13:21, Robert Marko wrote:
> On Tue, 7 Dec 2021 at 19:06, Kalle Valo <kvalo@kernel.org> wrote:
>>
>> 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?
> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

On Wed, 8 Dec 2021 at 15:07, Christian Lamparter <chunkeey@gmail.com> wrote:
>
> On 08/12/2021 13:21, Robert Marko wrote:
> > On Tue, 7 Dec 2021 at 19:06, Kalle Valo <kvalo@kernel.org> wrote:
> >>
> >> 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?
> > 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Thibaut]

> Le 17 déc. 2021 à 13:06, Robert Marko <robimarko@gmail.com> a écrit :
> 
> On Wed, 8 Dec 2021 at 15:07, Christian Lamparter <chunkeey@gmail.com> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

Kalle,

What is your opinion on this?
I would really love to see this get merged as we are having more and
more devices that are impacted without it.

Regards,
Robert

On Fri, 17 Dec 2021 at 13:25, Thibaut <hacks@slashdirt.org> wrote:
>
>
>
> > Le 17 déc. 2021 à 13:06, Robert Marko <robimarko@gmail.com> a écrit :
> >
> > On Wed, 8 Dec 2021 at 15:07, Christian Lamparter <chunkeey@gmail.com> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

Silent ping,

Does anybody have an opinion on this?

Regards,
Robert

On Wed, 2 Feb 2022 at 19:49, Robert Marko <robimarko@gmail.com> wrote:
>
> Kalle,
>
> What is your opinion on this?
> I would really love to see this get merged as we are having more and
> more devices that are impacted without it.
>
> Regards,
> Robert
>
> On Fri, 17 Dec 2021 at 13:25, Thibaut <hacks@slashdirt.org> wrote:
> >
> >
> >
> > > Le 17 déc. 2021 à 13:06, Robert Marko <robimarko@gmail.com> a écrit :
> > >
> > > On Wed, 8 Dec 2021 at 15:07, Christian Lamparter <chunkeey@gmail.com> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Christian Lamparter]

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.)

Regards,
Christian

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Thibaut]

Hi,

> Le 16 févr. 2022 à 22:19, Christian Lamparter <chunkeey@gmail.com> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Robert Marko]

On Wed, 16 Feb 2022 at 22:55, Thibaut <hacks@slashdirt.org> wrote:
>
> Hi,
>
> > Le 16 févr. 2022 à 22:19, Christian Lamparter <chunkeey@gmail.com> 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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Kalle Valo]

Robert Marko <robimarko@gmail.com> writes:

> On Wed, 16 Feb 2022 at 22:55, Thibaut <hacks@slashdirt.org> wrote:
>>
>> Hi,
>>
>> > Le 16 févr. 2022 à 22:19, Christian Lamparter <chunkeey@gmail.com> 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).
>
> Kalle, any chance of reviewing this? It just brings the board data in
> line with caldata as far as naming goes.

Sorry for the delay in review. So the original idea was that board.bin
would be only used by developers for testing purposes only and normal
users will use the board file automatically from board-2.bin. It's a
shame if Mikrotik broke this, it's not ideal if there are so many
different ways to use board files. I need to think a bit about this.

The patch is now in pending branch for build testing:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=eda838c3941863a486f7fced4b739de6fc80e857

I also fixed two checkpatch warnings:

drivers/net/wireless/ath/ath10k/core.c:1252: line length of 93 exceeds 90 columns
drivers/net/wireless/ath/ath10k/core.c:1253: line length of 96 exceeds 90 columns

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

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

Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

[Kalle Valo]

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>
> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>

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/20211009221711.2315352-1-robimarko@gmail.com/

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