| Message ID | 20211009221711.2315352-1-robimarko@gmail.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | ath10k: support bus and device specific API 1 BDF selection | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
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
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
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
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?
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.
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 >
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
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
> 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
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
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
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
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
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
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
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
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);
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(-)