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
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 <[email protected]> wrote:
>
>
>
> > 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
Silent ping,
Does anybody have an opinion on this?
Regards,
Robert
On Wed, 2 Feb 2022 at 19:49, Robert Marko <[email protected]> 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 <[email protected]> wrote:
> >
> >
> >
> > > 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
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