From: Robert Marko <robimarko@gmail.com> To: Kalle Valo <kvalo@kernel.org> Cc: kvalo@codeaurora.org, davem@davemloft.net, kuba@kernel.org, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, open list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection Date: Wed, 8 Dec 2021 13:21:47 +0100 [thread overview] Message-ID: <CAOX2RU5mqUfPRDsQNSpVPdiz6sE_68KN5Ae+2bC_t1cQzdzgTA@mail.gmail.com> (raw) In-Reply-To: <163890036783.24891.8718291787865192280.kvalo@kernel.org> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Robert Marko <robimarko@gmail.com> To: Kalle Valo <kvalo@kernel.org> Cc: kvalo@codeaurora.org, davem@davemloft.net, kuba@kernel.org, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, open list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection Date: Wed, 8 Dec 2021 13:21:47 +0100 [thread overview] Message-ID: <CAOX2RU5mqUfPRDsQNSpVPdiz6sE_68KN5Ae+2bC_t1cQzdzgTA@mail.gmail.com> (raw) In-Reply-To: <163890036783.24891.8718291787865192280.kvalo@kernel.org> 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 > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2021-12-08 12:22 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko 2021-10-09 22:17 ` Robert Marko 2021-10-14 11:54 ` Christian Lamparter 2021-10-14 11:54 ` Christian Lamparter 2021-10-14 12:01 ` Robert Marko 2021-10-14 12:01 ` Robert Marko 2021-10-14 13:23 ` Christian Lamparter 2021-10-14 13:23 ` Christian Lamparter 2021-12-07 18:06 ` Kalle Valo 2021-12-07 18:06 ` Kalle Valo 2021-12-07 18:09 ` Kalle Valo 2021-12-07 18:09 ` Kalle Valo 2021-12-08 12:21 ` Robert Marko [this message] 2021-12-08 12:21 ` Robert Marko 2021-12-08 14:07 ` Christian Lamparter 2021-12-08 14:07 ` Christian Lamparter 2021-12-17 12:06 ` Robert Marko 2021-12-17 12:06 ` Robert Marko 2021-12-17 12:25 ` Thibaut 2021-12-17 12:25 ` Thibaut 2022-02-02 18:49 ` Robert Marko 2022-02-02 18:49 ` Robert Marko 2022-02-16 13:38 ` Robert Marko 2022-02-16 13:38 ` Robert Marko 2022-02-16 21:19 ` Christian Lamparter 2022-02-16 21:19 ` Christian Lamparter 2022-02-16 21:55 ` Thibaut 2022-02-16 21:55 ` Thibaut 2022-05-03 15:58 ` Robert Marko 2022-05-03 15:58 ` Robert Marko 2022-05-04 7:48 ` Kalle Valo 2022-05-04 7:48 ` Kalle Valo 2022-05-06 6:19 ` Kalle Valo 2022-05-06 6:19 ` Kalle Valo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOX2RU5mqUfPRDsQNSpVPdiz6sE_68KN5Ae+2bC_t1cQzdzgTA@mail.gmail.com \ --to=robimarko@gmail.com \ --cc=ath10k@lists.infradead.org \ --cc=davem@davemloft.net \ --cc=kuba@kernel.org \ --cc=kvalo@codeaurora.org \ --cc=kvalo@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=netdev@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.