From: Brian Norris <briannorris@chromium.org>
To: Francesco Dolcini <francesco.dolcini@toradex.com>
Cc: "Amitkumar Karwar" <amitkarwar@gmail.com>,
"Ganapathi Bhat" <ganapathi017@gmail.com>,
"Sharvari Harisangam" <sharvari.harisangam@nxp.com>,
"Xinming Hu" <huxinming820@gmail.com>,
linux-wireless@vger.kernel.org,
"Andrejs Cainikovs" <andrejs.cainikovs@toradex.com>,
"Kalle Valo" <kvalo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
netdev@vger.kernel.org, "Jonas Dreßler" <verdre@v0yd.nl>
Subject: Re: [RFC PATCH] mwifiex: Select firmware based on strapping
Date: Mon, 21 Mar 2022 13:31:07 -0700 [thread overview]
Message-ID: <Yjjgi4YJVYBnJTqK@google.com> (raw)
In-Reply-To: <20220321161003.39214-1-francesco.dolcini@toradex.com>
On Mon, Mar 21, 2022 at 05:10:03PM +0100, Francesco Dolcini wrote:
> From: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
>
> Some WiFi/Bluetooth modules might have different host connection
> options, allowing to either use SDIO for both WiFi and Bluetooth,
> or SDIO for WiFi and UART for Bluetooth. It is possible to detect
> whether a module has SDIO-SDIO or SDIO-UART connection by reading
> its host strap register.
>
> This change introduces a way to automatically select appropriate
> firmware depending of the connection method, and removes a need
> of symlinking or overwriting the original firmware file with a
> required one.
>
> Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> ---
> Hi all,
>
> Current mwifiex_sdio implementation does not have strapping detection, which
> means there's no way system will automatically detect which firmware needs to
> be picked depending of the strapping. SD8997, in particular, can be strapped
> for sdiosdio (Wi-Fi over SDIO, Bluetooth over SDIO) or sdiouart (Wi-Fi over
> SDIO, Bluetooth over UART). What we do now - simply replace the
> original sdiosdio firmware file with the one supplied by NXP [1] for sdiouart.
>
> Of course, this is not clean, and by submitting this patch I would like to
> receive your comments regarding how it would be better to implement the
> strapping detection.
>
> [1] https://github.com/NXP/imx-firmware/blob/lf-5.10.52_2.1.0/nxp/FwImage_8997_SD/sdiouart8997_combo_v4.bin
>
> Francesco & Andrejs
>
> ---
> drivers/net/wireless/marvell/mwifiex/sdio.c | 17 ++++++++++++++++-
> drivers/net/wireless/marvell/mwifiex/sdio.h | 6 ++++++
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index bde9e4bbfffe..8670ded74c27 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -182,6 +182,9 @@ static const struct mwifiex_sdio_card_reg mwifiex_reg_sd8997 = {
> .host_int_rsr_reg = 0x4,
> .host_int_status_reg = 0x0C,
> .host_int_mask_reg = 0x08,
> + .host_strap_reg = 0xF4,
> + .host_strap_mask = 0x01,
> + .host_strap_value = 0x00,
Do you have any documentation or sources (e.g., a vendor driver) that
describe this register? If we don't have documentation on what exactly
this register means, we might need to be a bit more conservative on
using it.
Previous thread:
https://lore.kernel.org/linux-wireless/87a6ejj2np.fsf@bang-olufsen.dk/
I guess this links to some driver sources with similar definitions?
Seems like we could still use a bit better naming/macros to explicitly
call these out as "UART" and "SDIO" options, instead of just
"alternate".
> .status_reg_0 = 0xE8,
> .status_reg_1 = 0xE9,
> .sdio_int_mask = 0xff,
> @@ -402,6 +405,7 @@ static const struct mwifiex_sdio_device mwifiex_sdio_sd8977 = {
>
> static const struct mwifiex_sdio_device mwifiex_sdio_sd8997 = {
> .firmware = SD8997_DEFAULT_FW_NAME,
> + .firmware_alt_strap = SD8997_SDIOUART_FW_NAME,
> .reg = &mwifiex_reg_sd8997,
> .max_ports = 32,
> .mp_agg_pkt_limit = 16,
> @@ -536,6 +540,7 @@ mwifiex_sdio_probe(struct sdio_func *func, const struct sdio_device_id *id)
> struct mwifiex_sdio_device *data = (void *)id->driver_data;
>
> card->firmware = data->firmware;
> + card->firmware_alt_strap = data->firmware_alt_strap;
> card->reg = data->reg;
> card->max_ports = data->max_ports;
> card->mp_agg_pkt_limit = data->mp_agg_pkt_limit;
> @@ -2439,6 +2444,7 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
> int ret;
> struct sdio_mmc_card *card = adapter->card;
> struct sdio_func *func = card->func;
> + const char *firmware = card->firmware;
>
> /* save adapter pointer in card */
> card->adapter = adapter;
> @@ -2455,7 +2461,15 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
> return ret;
> }
>
> - strcpy(adapter->fw_name, card->firmware);
> + /* Select alternative firmware based on the strapping options */
> + if (card->firmware_alt_strap) {
> + u8 val;
> + mwifiex_read_reg(adapter, card->reg->host_strap_reg, &val);
> + if ((val & card->reg->host_strap_mask) == card->reg->host_strap_value)
> + firmware = card->firmware_alt_strap;
> + }
> + strcpy(adapter->fw_name, firmware);
> +
> if (card->fw_dump_enh) {
> adapter->mem_type_mapping_tbl = generic_mem_type_map;
> adapter->num_mem_types = 1;
> @@ -3157,3 +3171,4 @@ MODULE_FIRMWARE(SD8887_DEFAULT_FW_NAME);
> MODULE_FIRMWARE(SD8977_DEFAULT_FW_NAME);
> MODULE_FIRMWARE(SD8987_DEFAULT_FW_NAME);
> MODULE_FIRMWARE(SD8997_DEFAULT_FW_NAME);
> +MODULE_FIRMWARE(SD8997_SDIOUART_FW_NAME);
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index 5648512c9300..bfea4d5998b7 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -39,6 +39,7 @@
> #define SD8977_DEFAULT_FW_NAME "mrvl/sdsd8977_combo_v2.bin"
> #define SD8987_DEFAULT_FW_NAME "mrvl/sd8987_uapsta.bin"
> #define SD8997_DEFAULT_FW_NAME "mrvl/sdsd8997_combo_v4.bin"
> +#define SD8997_SDIOUART_FW_NAME "nxp/sdiouart8997_combo_v4.bin"
This isn't your main issue, but just because companies buy and sell IP
doesn't mean we'll change the firmware paths. Qualcomm drivers still use
"ath" prefixes, for one ;)
Personally, I'd still keep the mrvl/ path. But that might be up to Kalle
and/or linux-firmware.git maintainers.
Brian
>
> #define BLOCK_MODE 1
> #define BYTE_MODE 0
next prev parent reply other threads:[~2022-03-21 20:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 16:10 [RFC PATCH] mwifiex: Select firmware based on strapping Francesco Dolcini
2022-03-21 20:31 ` Brian Norris [this message]
2022-03-23 7:31 ` 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=Yjjgi4YJVYBnJTqK@google.com \
--to=briannorris@chromium.org \
--cc=amitkarwar@gmail.com \
--cc=andrejs.cainikovs@toradex.com \
--cc=davem@davemloft.net \
--cc=francesco.dolcini@toradex.com \
--cc=ganapathi017@gmail.com \
--cc=huxinming820@gmail.com \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sharvari.harisangam@nxp.com \
--cc=verdre@v0yd.nl \
/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: link
Be 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.