linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ath10k: support bus and device specific API 1 BDF selection
@ 2021-10-09 22:17 Robert Marko
  2021-10-14 11:54 ` Christian Lamparter
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Robert Marko @ 2021-10-09 22:17 UTC (permalink / raw)
  To: kvalo, davem, kuba, ath10k, linux-wireless, netdev, linux-kernel
  Cc: 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


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko
@ 2021-10-14 11:54 ` Christian Lamparter
  2021-10-14 12:01   ` Robert Marko
  2021-12-07 18:06 ` Kalle Valo
  2022-05-06  6:19 ` Kalle Valo
  2 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2021-10-14 11:54 UTC (permalink / raw)
  To: Robert Marko, kvalo, davem, kuba, ath10k, linux-wireless, netdev,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-10-14 11:54 ` Christian Lamparter
@ 2021-10-14 12:01   ` Robert Marko
  2021-10-14 13:23     ` Christian Lamparter
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Marko @ 2021-10-14 12:01 UTC (permalink / raw)
  To: Christian Lamparter
  Cc: kvalo, davem, kuba, ath10k, linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-10-14 12:01   ` Robert Marko
@ 2021-10-14 13:23     ` Christian Lamparter
  0 siblings, 0 replies; 17+ messages in thread
From: Christian Lamparter @ 2021-10-14 13:23 UTC (permalink / raw)
  To: Robert Marko
  Cc: kvalo, davem, kuba, ath10k, linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko
  2021-10-14 11:54 ` Christian Lamparter
@ 2021-12-07 18:06 ` Kalle Valo
  2021-12-07 18:09   ` Kalle Valo
  2021-12-08 12:21   ` Robert Marko
  2022-05-06  6:19 ` Kalle Valo
  2 siblings, 2 replies; 17+ messages in thread
From: Kalle Valo @ 2021-12-07 18:06 UTC (permalink / raw)
  To: Robert Marko
  Cc: kvalo, davem, kuba, ath10k, linux-wireless, netdev, linux-kernel,
	Robert Marko

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-12-07 18:06 ` Kalle Valo
@ 2021-12-07 18:09   ` Kalle Valo
  2021-12-08 12:21   ` Robert Marko
  1 sibling, 0 replies; 17+ messages in thread
From: Kalle Valo @ 2021-12-07 18:09 UTC (permalink / raw)
  To: Robert Marko; +Cc: davem, kuba, ath10k, linux-wireless, netdev, linux-kernel

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-12-07 18:06 ` Kalle Valo
  2021-12-07 18:09   ` Kalle Valo
@ 2021-12-08 12:21   ` Robert Marko
  2021-12-08 14:07     ` Christian Lamparter
  1 sibling, 1 reply; 17+ messages in thread
From: Robert Marko @ 2021-12-08 12:21 UTC (permalink / raw)
  To: Kalle Valo; +Cc: kvalo, davem, kuba, ath10k, linux-wireless, netdev, open list

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
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-12-08 12:21   ` Robert Marko
@ 2021-12-08 14:07     ` Christian Lamparter
  2021-12-17 12:06       ` Robert Marko
  0 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2021-12-08 14:07 UTC (permalink / raw)
  To: Robert Marko, Kalle Valo
  Cc: kvalo, davem, kuba, ath10k, linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-12-08 14:07     ` Christian Lamparter
@ 2021-12-17 12:06       ` Robert Marko
  2021-12-17 12:25         ` Thibaut
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Marko @ 2021-12-17 12:06 UTC (permalink / raw)
  To: Christian Lamparter
  Cc: Kalle Valo, kvalo, davem, kuba, ath10k, linux-wireless, netdev,
	open list, Thibaut

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-12-17 12:06       ` Robert Marko
@ 2021-12-17 12:25         ` Thibaut
  2022-02-02 18:49           ` Robert Marko
  0 siblings, 1 reply; 17+ messages in thread
From: Thibaut @ 2021-12-17 12:25 UTC (permalink / raw)
  To: Robert Marko
  Cc: Christian Lamparter, Kalle Valo, kvalo, davem, kuba, ath10k,
	linux-wireless, netdev, open list



> 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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-12-17 12:25         ` Thibaut
@ 2022-02-02 18:49           ` Robert Marko
  2022-02-16 13:38             ` Robert Marko
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Marko @ 2022-02-02 18:49 UTC (permalink / raw)
  To: Thibaut
  Cc: Christian Lamparter, Kalle Valo, kvalo, davem, kuba, ath10k,
	linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2022-02-02 18:49           ` Robert Marko
@ 2022-02-16 13:38             ` Robert Marko
  2022-02-16 21:19               ` Christian Lamparter
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Marko @ 2022-02-16 13:38 UTC (permalink / raw)
  To: Thibaut
  Cc: Christian Lamparter, Kalle Valo, kvalo, davem, kuba, ath10k,
	linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2022-02-16 13:38             ` Robert Marko
@ 2022-02-16 21:19               ` Christian Lamparter
  2022-02-16 21:55                 ` Thibaut
  0 siblings, 1 reply; 17+ messages in thread
From: Christian Lamparter @ 2022-02-16 21:19 UTC (permalink / raw)
  To: Robert Marko, Thibaut
  Cc: Kalle Valo, kvalo, davem, kuba, ath10k, linux-wireless, netdev,
	open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2022-02-16 21:19               ` Christian Lamparter
@ 2022-02-16 21:55                 ` Thibaut
  2022-05-03 15:58                   ` Robert Marko
  0 siblings, 1 reply; 17+ messages in thread
From: Thibaut @ 2022-02-16 21:55 UTC (permalink / raw)
  To: Christian Lamparter
  Cc: Robert Marko, Kalle Valo, kvalo, davem, kuba, ath10k,
	linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2022-02-16 21:55                 ` Thibaut
@ 2022-05-03 15:58                   ` Robert Marko
  2022-05-04  7:48                     ` Kalle Valo
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Marko @ 2022-05-03 15:58 UTC (permalink / raw)
  To: Thibaut
  Cc: Christian Lamparter, Kalle Valo, kvalo, davem, kuba, ath10k,
	linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2022-05-03 15:58                   ` Robert Marko
@ 2022-05-04  7:48                     ` Kalle Valo
  0 siblings, 0 replies; 17+ messages in thread
From: Kalle Valo @ 2022-05-04  7:48 UTC (permalink / raw)
  To: Robert Marko
  Cc: Thibaut, Christian Lamparter, davem, kuba, ath10k,
	linux-wireless, netdev, open list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
  2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko
  2021-10-14 11:54 ` Christian Lamparter
  2021-12-07 18:06 ` Kalle Valo
@ 2022-05-06  6:19 ` Kalle Valo
  2 siblings, 0 replies; 17+ messages in thread
From: Kalle Valo @ 2022-05-06  6:19 UTC (permalink / raw)
  To: Robert Marko
  Cc: kvalo, davem, kuba, ath10k, linux-wireless, netdev, linux-kernel,
	Robert Marko

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2022-05-06  6:20 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko
2021-10-14 11:54 ` Christian Lamparter
2021-10-14 12:01   ` Robert Marko
2021-10-14 13:23     ` Christian Lamparter
2021-12-07 18:06 ` Kalle Valo
2021-12-07 18:09   ` Kalle Valo
2021-12-08 12:21   ` Robert Marko
2021-12-08 14:07     ` Christian Lamparter
2021-12-17 12:06       ` Robert Marko
2021-12-17 12:25         ` Thibaut
2022-02-02 18:49           ` Robert Marko
2022-02-16 13:38             ` Robert Marko
2022-02-16 21:19               ` Christian Lamparter
2022-02-16 21:55                 ` Thibaut
2022-05-03 15:58                   ` Robert Marko
2022-05-04  7:48                     ` Kalle Valo
2022-05-06  6:19 ` Kalle Valo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).