[DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte

[DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte

[Karel Balej]

Hello,

this series adds support for WiFi to the samsung,coreprimevelte
smartphone (and can be straightforwardly reused for the other known
Marvell PXA1908-based smartphones).

The series is currently not intended for application as indicated in the
subject prefix as the firmware necessary for the operation of the chip is not
available in linux-firmware.

Instead, my intentions are to publish the recent developments regarding
the chip support (see the third patch of the series) and offer them for
others to use and if possible get some feedback on them and also
hopefully to spark some conversation with NXP regarding getting the FW
into linux-firmware which would allow this series to be mainlined.

Regarding the firmware I have been in contact with Jeff Chen of NXP some
time ago who promised to ask about it internally – I am thus now gently
reminding Jeff of the matter. I will also appreciate input from anyone
else who may help with upstreaming whichever version of the firmware.

The trouble of upstreaming the FW is mostly a legal one (although an up
to date version of it would also be very welcome) as it is available as
part of the stock Android of the devices with this chip and can thus be
used on individual basis, it cannot however be submitted to
linux-firmware by myself for instance as the license is not known
(although probably is the same as for the other blobs in the mrvl
directory) and as the submission would require a sign-off from someone
involved with NXP.

The third patch in this series fixes a serious issue with the WiFi
observed on the phone (see the relevant commit message). The form is
however not directly usptreamable and it is not clear to me how to best
make it be since it involves changing a data type which probably cannot
be easily be special-cased for the new chip and would likely break the
other chips the mwifiex driver supports if applied as is. I will thus
welcome suggestions on this, although I'm also hopeful that a possible
reasonably up to date FW would not require this workaround at all.

The series is based on the pxa1908-dt-for-6.19 tag of Duje's tree [1] as
it contains the necessary SDIO description in the phone's device tree.

I have not applied the trailers sent in response to v1 as it has been
some time and as this is not expected to be applied anyway.

[1] https://gitlab.com/pxa1908-mainline/linux/-/commits/pxa1908-dt-for-6.19

Cc: Jeff Chen <jeff.chen_1@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>

v2:
- Rebase to Duje's tag.
- Add a new patch fixing observed firmware crashes.
- Link to v1: https://lore.kernel.org/r/20231029111807.19261-1-balejk@matfyz.cz/

Karel Balej (4):
  dt-bindings: mwifiex: document use with the SD8777 chipset
  net: mwifiex: add support for the SD8777 chipset
  DONOTMERGE: net: mwifiex: fix timeouts with the SD8777 chip
  arm64: dts: samsung,coreprimevelte: add wifi node

 .../bindings/net/wireless/marvell,sd8787.yaml |  1 +
 .../mmp/pxa1908-samsung-coreprimevelte.dts    | 15 +++++++++++++
 drivers/net/wireless/marvell/mwifiex/fw.h     |  4 +---
 drivers/net/wireless/marvell/mwifiex/sdio.c   | 21 +++++++++++++++++++
 drivers/net/wireless/marvell/mwifiex/sdio.h   |  1 +
 drivers/net/wireless/marvell/mwifiex/sta_tx.c | 10 ++-------
 include/linux/mmc/sdio_ids.h                  |  1 +
 7 files changed, 42 insertions(+), 11 deletions(-)

-- 
2.51.1

[DONOTAPPLY RFC PATCH v2 1/4] dt-bindings: mwifiex: document use with the SD8777 chipset

[Karel Balej]

Document the corresponding compatible string for the use of this driver
with the Marvell SD8777 wireless chipset.

Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
 .../devicetree/bindings/net/wireless/marvell,sd8787.yaml         | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
index 930b700b73d0..d31ff38f57d1 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
@@ -18,6 +18,7 @@ description:
 properties:
   compatible:
     enum:
+      - marvell,sd8777
       - marvell,sd8787
       - marvell,sd8897
       - marvell,sd8978
-- 
2.51.1

Re: [DONOTAPPLY RFC PATCH v2 1/4] dt-bindings: mwifiex: document use with the SD8777 chipset

[Brian Norris]

On Sun, Oct 26, 2025 at 07:20:38PM +0100, Karel Balej wrote:
> Document the corresponding compatible string for the use of this driver
> with the Marvell SD8777 wireless chipset.

Device tree bindings aren't supposed to be about "drivers". This can
just be:

  Document the compatible string for the Marvell SD8777 wireless chipset.

On the bright side, it's totally legit to describe HW bindings even if
there isn't driver support yet. So:

Acked-by: Brian Norris <briannorris@chromium.org>

> Signed-off-by: Karel Balej <balejk@matfyz.cz>
> ---
>  .../devicetree/bindings/net/wireless/marvell,sd8787.yaml         | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
> index 930b700b73d0..d31ff38f57d1 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
> @@ -18,6 +18,7 @@ description:
>  properties:
>    compatible:
>      enum:
> +      - marvell,sd8777
>        - marvell,sd8787
>        - marvell,sd8897
>        - marvell,sd8978
> -- 
> 2.51.1
> 

[DONOTAPPLY RFC PATCH v2 2/4] net: mwifiex: add support for the SD8777 chipset

[Karel Balej]

Marvell SD8777 is a wireless chipset used for instance in the PXA1908
SoC found for example in the samsung,coreprimevelte smartphone, with
which this was tested. The driver seems to be compatible with this
chipset so enable this support by adding the necessary information based
on the downstream code.

Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 21 +++++++++++++++++++++
 drivers/net/wireless/marvell/mwifiex/sdio.h |  1 +
 include/linux/mmc/sdio_ids.h                |  1 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index f039d6f19183..a1adb78fabaf 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -318,6 +318,23 @@ static const struct mwifiex_sdio_card_reg mwifiex_reg_sd89xx = {
 				 0x68, 0x69, 0x6a},
 };
 
+static const struct mwifiex_sdio_device mwifiex_sdio_sd8777 = {
+	.firmware = SD8777_DEFAULT_FW_NAME,
+	.reg = &mwifiex_reg_sd87xx,
+	.max_ports = 16,
+	.mp_agg_pkt_limit = 8,
+	.tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K,
+	.mp_tx_agg_buf_size = MWIFIEX_MP_AGGR_BUF_SIZE_16K,
+	.mp_rx_agg_buf_size = MWIFIEX_MP_AGGR_BUF_SIZE_16K,
+	.supports_sdio_new_mode = false,
+	.has_control_mask = true,
+	.can_dump_fw = false,
+	.can_auto_tdls = true,
+	.can_ext_scan = true,
+	.fw_ready_extra_delay = false,
+	.host_mlme = false,
+};
+
 static const struct mwifiex_sdio_device mwifiex_sdio_sd8786 = {
 	.firmware = SD8786_DEFAULT_FW_NAME,
 	.reg = &mwifiex_reg_sd87xx,
@@ -516,6 +533,7 @@ static struct memory_type_mapping mem_type_mapping_tbl[] = {
 };
 
 static const struct of_device_id mwifiex_sdio_of_match_table[] __maybe_unused = {
+	{ .compatible = "marvell,sd8777" },
 	{ .compatible = "marvell,sd8787" },
 	{ .compatible = "marvell,sd8897" },
 	{ .compatible = "marvell,sd8978" },
@@ -954,6 +972,8 @@ static void mwifiex_sdio_coredump(struct device *dev)
 
 /* WLAN IDs */
 static const struct sdio_device_id mwifiex_ids[] = {
+	{SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8777_WLAN),
+		.driver_data = (unsigned long)&mwifiex_sdio_sd8777},
 	{SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8786_WLAN),
 		.driver_data = (unsigned long) &mwifiex_sdio_sd8786},
 	{SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8787_WLAN),
@@ -3201,6 +3221,7 @@ MODULE_AUTHOR("Marvell International Ltd.");
 MODULE_DESCRIPTION("Marvell WiFi-Ex SDIO Driver version " SDIO_VERSION);
 MODULE_VERSION(SDIO_VERSION);
 MODULE_LICENSE("GPL v2");
+MODULE_FIRMWARE(SD8777_DEFAULT_FW_NAME);
 MODULE_FIRMWARE(SD8786_DEFAULT_FW_NAME);
 MODULE_FIRMWARE(SD8787_DEFAULT_FW_NAME);
 MODULE_FIRMWARE(SD8797_DEFAULT_FW_NAME);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index 65d142286c46..c6425191ad84 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -18,6 +18,7 @@
 
 #include "main.h"
 
+#define SD8777_DEFAULT_FW_NAME "mrvl/sd8777_uapsta.bin"
 #define SD8786_DEFAULT_FW_NAME "mrvl/sd8786_uapsta.bin"
 #define SD8787_DEFAULT_FW_NAME "mrvl/sd8787_uapsta.bin"
 #define SD8797_DEFAULT_FW_NAME "mrvl/sd8797_uapsta.bin"
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 673cbdf43453..61e95b5a528c 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -95,6 +95,7 @@
 #define SDIO_DEVICE_ID_MARVELL_8797_BT		0x912a
 #define SDIO_DEVICE_ID_MARVELL_8897_WLAN	0x912d
 #define SDIO_DEVICE_ID_MARVELL_8897_BT		0x912e
+#define SDIO_DEVICE_ID_MARVELL_8777_WLAN	0x9131
 #define SDIO_DEVICE_ID_MARVELL_8887_F0		0x9134
 #define SDIO_DEVICE_ID_MARVELL_8887_WLAN	0x9135
 #define SDIO_DEVICE_ID_MARVELL_8887_BT		0x9136
-- 
2.51.1

[DONOTAPPLY RFC PATCH v2 3/4] DONOTMERGE: net: mwifiex: fix timeouts with the SD8777 chip

[Karel Balej]

It has been observed with the samsung,coreprimevelte smartphone which
uses this wireless chip that the driver would irrecoverably fail upon
certain operations, usually after timing out on a FW command such as
with these logs:

	[ 2101.209913] mwifiex_sdio mmc2:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0xa4, act = 0x0
	[ 2101.209941] mwifiex_sdio mmc2:0001:1: num_data_h2c_failure = 0
	[ 2101.209949] mwifiex_sdio mmc2:0001:1: num_cmd_h2c_failure = 0
	[ 2101.209957] mwifiex_sdio mmc2:0001:1: is_cmd_timedout = 1
	[ 2101.209964] mwifiex_sdio mmc2:0001:1: num_tx_timeout = 0
	[ 2101.209971] mwifiex_sdio mmc2:0001:1: last_cmd_index = 1
	[ 2101.209978] mwifiex_sdio mmc2:0001:1: last_cmd_id: 16 00 a4 00 75 00 a4 00 7f 00
	[ 2101.209988] mwifiex_sdio mmc2:0001:1: last_cmd_act: 00 00 00 00 02 00 00 00 00 00
	[ 2101.209995] mwifiex_sdio mmc2:0001:1: last_cmd_resp_index = 0
	[ 2101.210003] mwifiex_sdio mmc2:0001:1: last_cmd_resp_id: 16 80 a4 80 75 80 a4 80 7f 80
	[ 2101.210010] mwifiex_sdio mmc2:0001:1: last_event_index = 4
	[ 2101.210018] mwifiex_sdio mmc2:0001:1: last_event: 0b 00 0a 00 0b 00 0a 00 1c 00
	[ 2101.210025] mwifiex_sdio mmc2:0001:1: data_sent=1 cmd_sent=1
	[ 2101.210033] mwifiex_sdio mmc2:0001:1: ps_mode=1 ps_state=0
	[ 2101.210089] mwifiex_sdio mmc2:0001:1: failed to get signal information
	[ 2101.210761] mwifiex_sdio mmc2:0001:1: PREP_CMD: FW is in bad state
	[ 2101.210786] mwifiex_sdio mmc2:0001:1: failed to get signal information
	[ 2101.211162] mwifiex_sdio mmc2:0001:1: ===mwifiex driverinfo dump start===
	[ 2101.211178] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14.75.33.p119)
	[ 2101.211202] mwifiex_sdio mmc2:0001:1: SDIO register dump start
	[ 2101.211482] mwifiex_sdio mmc2:0001:1: SDIO Func0 (0x0-0x9): 32 02 02 02 03 00 00 02 03 00
	[ 2101.211649] mwifiex_sdio mmc2:0001:1: SDIO Func1 (0x0-0x9): 02 3f 03 00 00 00 00 00 92 00
	[ 2101.211740] mwifiex_sdio mmc2:0001:1: SDIO Func1: (0x28) 00 (0x30) 08 (0x34) 07 (0x38) 11 (0x3c) 00
	[ 2101.211921] mwifiex_sdio mmc2:0001:1: SDIO Func1 (0x60-0x6a): dc fe 5f 81 ca 04 00 79 79 00 30
	[ 2101.314135] mwifiex_sdio mmc2:0001:1: SDIO Func1 (0x60-0x6a): dc fe 5f 81 ca 04 00 79 79 00 30
	[ 2101.314168] mwifiex_sdio mmc2:0001:1: SDIO register dump end
	[ 2101.314300] mwifiex_sdio mmc2:0001:1: ===mwifiex driverinfo dump end===
	[ 2101.314313] mwifiex_sdio mmc2:0001:1: == mwifiex dump information to /sys/class/devcoredump start
	[ 2101.314586] mwifiex_sdio mmc2:0001:1: == mwifiex dump information to /sys/class/devcoredump end
	[ 2101.314610] mwifiex_sdio mmc2:0001:1: PREP_CMD: FW is in bad state
	[ 2101.314638] mwifiex_sdio mmc2:0001:1: PREP_CMD: FW is in bad state
	[ 2101.317997] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.318029] mwifiex_sdio mmc2:0001:1: deleting the crypto keys
	[ 2101.318037] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.318044] mwifiex_sdio mmc2:0001:1: deleting the crypto keys
	[ 2101.318051] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.318057] mwifiex_sdio mmc2:0001:1: deleting the crypto keys
	[ 2101.318064] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.318071] mwifiex_sdio mmc2:0001:1: deleting the crypto keys
	[ 2101.318078] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.318084] mwifiex_sdio mmc2:0001:1: deleting the crypto keys
	[ 2101.318091] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.318098] mwifiex_sdio mmc2:0001:1: deleting the crypto keys
	[ 2101.321278] mwifiex_sdio mmc2:0001:1: info: shutdown mwifiex...
	[ 2101.323214] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.323250] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.324427] mwifiex_sdio mmc2:0001:1: PREP_CMD: card is removed
	[ 2101.419786] mmc2: queuing unknown CIS tuple 0x50 [40 1e fd d1 c0 46 70 47 00 b5 23 48 24 49 01 60 24 48 24 49 01 60 24 49 08 47 1f 48 24 49 01 60] (32 bytes)
	[ 2101.460850] mmc2: queuing unknown CIS tuple 0x70 [53 f0 21 e3 1e ff 2f e1 10 1f 11 ee 00 00 50 e3 02 2a a0 e3 02 10 c1 01 02 10 81 11 10 1f 01 ee 1e ff 2f e1 01 00 a0 e3 f6 ff ff eb ea ff ff fa 48 00 9f e5 54 10 9f e5 54 20 9f e5 ef ff ff eb] (71 bytes)
	[ 2101.532495] mmc2: queuing unknown CIS tuple 0xe8 [2f 07 ee 1e ff 2f e1 0e 30 a0 e1 00 00 a0 e3 ea ff ff eb e5 ff ff fa 03 e0 a0 e1 2c 30 9f e5 13 ff 2f e1 00 10 80 e5 1a 9f 00 ee 12 ff 2f e1 04 21 00 80 c0 00 10 80 04 22 00 80 06 0a 46 02 48] (144 bytes)
	[ 2101.598922] mmc2: queuing unknown CIS tuple 0x9d [29 15 1d 01 00 4d 61 72 76 65 6c 6c 20 42 6c 75 65 74 6f 6f 74 68 20 44 65 76 69 63 65 00 00 ff 20 04 df 02 32 91 21 02 0c 00 22 2a 01 01 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00] (162 bytes)
	[ 2101.599647] mmc2: tried to HW reset card, got error -2
	[ 2101.599699] mwifiex_sdio mmc2:0001:1: SDIO HW reset failed: -2

(besides cmd id 0xa4 also 0xce is often seen in these dumps).

One of these operations which would cause the timeout reliably was
initiating a SSH connection into the phone over the WiFi and this was
used for tracking down the issue. The other known ones are heavier usage
of the XMPP client Dino on the phone and any more than basic browsing in
Firefox.

It was however verified that the mwifiex driver works without issues on
the vendor Samsung kernel with the proper support for the chip added,
although the stock Android on the phone doesn't use mwifiex but instead
a specialized driver for the chip which however is very similar to
mwifiex.

A support for the phone and it's components essential for the WiFi
function were thus backported to the v3.14 kernel on whose stable branch
the stock kernel was based and it was verified that the WiFi (namely SSH
over WiFi) also works there without timeouts. Afterwards, a bisect was
performed which first indicated the commit 808bbebcc8fc ("mwifiex: add
Tx status support for EAPOL packets") introduced in the v3.18-v3.19
cycle.

Reverting this commit (and the following one, commit 18ca43823f3c
("mwifiex: add Tx status support for ACTION frames"), to facilitate a
clean revert) fixed the timeouts for v3.19, but during the next cycle,
v3.19-v4.0, another breakage was introduced via commit 84b313b35f81
("mwifiex: make tx packet 64 byte DMA aligned").

Reverting all three commits fixed the timeouts on the current mainline
kernel also. This patch contains the minimal changes needed to achieve
that derived from the full revert commits.

Note that a few timeouts were still observed on mainline Linux even with
these changes, however they were all on a particular network and don't
have a known reproducer. On other networks, the chip performs flawlessly
as far as it was tested so far.

These changes also don't mitigate the observed firmware loading issues:

	[   68.698674] mwifiex_sdio mmc2:0001:1: FW download, write iomem (0) failed @ 208016
	[   68.698711] mwifiex_sdio mmc2:0001:1: prog_fw failed ret=0xffffffff

These were however also seen with the old kernels and as such are likely
caused either by some inherent incompatibility of the driver with the
chip in this regard or, more likely given their occasional nature, by an
issue at some other level, such as the stability of the SDIO (the
occurrence of the problem does seem to loosely correlate with the load
exerted on the phone while the FW loading is performed (i. e. mainly on
startup)).

Note that Bluetooth on the phone (provided by the same chip) has also
been seen crashing in a similar way as the WiFi without this patch,
although seemingly less frequently/deterministically, and a similar
change might thus be needed in the btmrvl driver if it is to be used for
the phone's BT without issues.

Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
 drivers/net/wireless/marvell/mwifiex/fw.h     |  4 +---
 drivers/net/wireless/marvell/mwifiex/sta_tx.c | 10 ++--------
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index e9e896606912..5c4c3363c7de 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -690,9 +690,7 @@ struct txpd {
 	u8 priority;
 	u8 flags;
 	u8 pkt_delay_2ms;
-	u8 reserved1[2];
-	u8 tx_token_id;
-	u8 reserved[2];
+	u8 reserved1;
 } __packed;
 
 struct rxpd {
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_tx.c b/drivers/net/wireless/marvell/mwifiex/sta_tx.c
index 9d0ef04ebe02..857eb22f4c24 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_tx.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_tx.c
@@ -41,8 +41,8 @@ void mwifiex_process_sta_txpd(struct mwifiex_private *priv,
 
 	pkt_type = mwifiex_is_skb_mgmt_frame(skb) ? PKT_TYPE_MGMT : 0;
 
-	pad = ((uintptr_t)skb->data - (sizeof(*local_tx_pd) + hroom)) &
-	       (MWIFIEX_DMA_ALIGN_SZ - 1);
+	pad = (4 - (((void *)skb->data - NULL) & 0x3)) % 4;
+
 	skb_push(skb, sizeof(*local_tx_pd) + pad);
 
 	local_tx_pd = (struct txpd *) skb->data;
@@ -58,12 +58,6 @@ void mwifiex_process_sta_txpd(struct mwifiex_private *priv,
 	local_tx_pd->pkt_delay_2ms =
 				mwifiex_wmm_compute_drv_pkt_delay(priv, skb);
 
-	if (tx_info->flags & MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS ||
-	    tx_info->flags & MWIFIEX_BUF_FLAG_ACTION_TX_STATUS) {
-		local_tx_pd->tx_token_id = tx_info->ack_frame_id;
-		local_tx_pd->flags |= MWIFIEX_TXPD_FLAGS_REQ_TX_STATUS;
-	}
-
 	if (local_tx_pd->priority <
 	    ARRAY_SIZE(priv->wmm.user_pri_pkt_tx_ctrl))
 		/*
-- 
2.51.1

Re: [DONOTAPPLY RFC PATCH v2 3/4] DONOTMERGE: net: mwifiex: fix timeouts with the SD8777 chip

[Brian Norris]

Hi,

On Sun, Oct 26, 2025 at 07:20:40PM +0100, Karel Balej wrote:
> 	[ 2101.211178] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14.75.33.p119)
... 
> Afterwards, a bisect was
> performed which first indicated the commit 808bbebcc8fc ("mwifiex: add
> Tx status support for EAPOL packets") introduced in the v3.18-v3.19
> cycle.
> 
> Reverting this commit (and the following one, commit 18ca43823f3c
> ("mwifiex: add Tx status support for ACTION frames"), to facilitate a
> clean revert) fixed the timeouts for v3.19, but during the next cycle,
> v3.19-v4.0, another breakage was introduced via commit 84b313b35f81
> ("mwifiex: make tx packet 64 byte DMA aligned").
> 
> Reverting all three commits fixed the timeouts on the current mainline
> kernel also. This patch contains the minimal changes needed to achieve
> that derived from the full revert commits.
...

(Trimmed the commit message down to the breaking commits, and the
version info)

From the looks of it, you're dealing with incompatible changes made in
the Marvell firmware API. It seems that you have a "version 14"
firmware, and the timeline of these mwifiex changes (~2014) is approx
when linux-firmware started seeing v15 and v16 firmware. It *might* be
OK to try add some versioning to these structs and padding changes, and
make a choice based on adapter->fw_release_number or
adapter->fw_cap_info. It might be ugly and error-prone, but possible...

Or if the FW versioning doesn't work out, it's possible we could
specifically flag these quirks for SD8777 somehow.

> Signed-off-by: Karel Balej <balejk@matfyz.cz>
> ---
>  drivers/net/wireless/marvell/mwifiex/fw.h     |  4 +---
>  drivers/net/wireless/marvell/mwifiex/sta_tx.c | 10 ++--------
>  2 files changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
> index e9e896606912..5c4c3363c7de 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -690,9 +690,7 @@ struct txpd {
>  	u8 priority;
>  	u8 flags;
>  	u8 pkt_delay_2ms;
> -	u8 reserved1[2];
> -	u8 tx_token_id;
> -	u8 reserved[2];
> +	u8 reserved1;

I'm inferring that 'sizeof(struct txpd)' (also spelled
'sizeof(*local_tx_pd)' below) is relevant, and that this struct probably
should retain the smaller size for FW version 14.

Maybe you need a new 'struct txpd_v14' layout, and embed that inside
'struct txpd'.

>  } __packed;
>  
>  struct rxpd {
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_tx.c b/drivers/net/wireless/marvell/mwifiex/sta_tx.c
> index 9d0ef04ebe02..857eb22f4c24 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_tx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_tx.c
> @@ -41,8 +41,8 @@ void mwifiex_process_sta_txpd(struct mwifiex_private *priv,
>  
>  	pkt_type = mwifiex_is_skb_mgmt_frame(skb) ? PKT_TYPE_MGMT : 0;
>  
> -	pad = ((uintptr_t)skb->data - (sizeof(*local_tx_pd) + hroom)) &
> -	       (MWIFIEX_DMA_ALIGN_SZ - 1);
> +	pad = (4 - (((void *)skb->data - NULL) & 0x3)) % 4;

It's not clear to me whether your v14 FW doesn't like the 64-byte
alignment, or if it didn't like the new txpd header size/layout, or
both. But obviously this line won't fly, with magic numbers and all. It
will need to be expressed in terms of macros (MWIFIEX_DMA_ALIGN_SZ, or a
"V14" version of that; and sizeof(...)).

> +
>  	skb_push(skb, sizeof(*local_tx_pd) + pad);
>  
>  	local_tx_pd = (struct txpd *) skb->data;
> @@ -58,12 +58,6 @@ void mwifiex_process_sta_txpd(struct mwifiex_private *priv,
>  	local_tx_pd->pkt_delay_2ms =
>  				mwifiex_wmm_compute_drv_pkt_delay(priv, skb);
>  
> -	if (tx_info->flags & MWIFIEX_BUF_FLAG_EAPOL_TX_STATUS ||
> -	    tx_info->flags & MWIFIEX_BUF_FLAG_ACTION_TX_STATUS) {
> -		local_tx_pd->tx_token_id = tx_info->ack_frame_id;
> -		local_tx_pd->flags |= MWIFIEX_TXPD_FLAGS_REQ_TX_STATUS;
> -	}

Rather than dropping this block, would it work to also check:

	adapter->fw_api_ver >= MWIFIEX_FW_V15

?

Brian

> -
>  	if (local_tx_pd->priority <
>  	    ARRAY_SIZE(priv->wmm.user_pri_pkt_tx_ctrl))
>  		/*
> -- 
> 2.51.1
> 

[DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node

[Karel Balej]

Add a node for the phone's WiFi serviced by the Marvell SD8777 chip a
communication with which happens over the SDIO. Also enable a regulator
without which it is not possible to connect to networks although they
are discovered properly.

Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
 .../mmp/pxa1908-samsung-coreprimevelte.dts        | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
index b2ce5edd9c6a..36d6ae4e902e 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
@@ -475,6 +475,14 @@ ldo14: ldo14 {
 				regulator-min-microvolt = <1200000>;
 				regulator-max-microvolt = <3300000>;
 			};
+
+			/*
+			 * Needs to be enabled in order for the WiFi to be able
+			 * to connect to networks.
+			 */
+			ldo15 {
+				regulator-always-on;
+			};
 		};
 	};
 };
@@ -523,6 +531,13 @@ &sdh1 {
 	pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
 	bus-width = <4>;
 	non-removable;
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	wifi@1 {
+		compatible = "marvell,sd8777";
+		reg = <1>;
+	};
 };
 
 &pwm3 {
-- 
2.51.1

Re: [DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node

[Brian Norris]

On Sun, Oct 26, 2025 at 07:20:41PM +0100, Karel Balej wrote:
> Add a node for the phone's WiFi serviced by the Marvell SD8777 chip a
> communication with which happens over the SDIO. Also enable a regulator
> without which it is not possible to connect to networks although they
> are discovered properly.
> 
> Signed-off-by: Karel Balej <balejk@matfyz.cz>
> ---
>  .../mmp/pxa1908-samsung-coreprimevelte.dts        | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
> index b2ce5edd9c6a..36d6ae4e902e 100644
> --- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
> +++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
> @@ -475,6 +475,14 @@ ldo14: ldo14 {
>  				regulator-min-microvolt = <1200000>;
>  				regulator-max-microvolt = <3300000>;
>  			};
> +
> +			/*
> +			 * Needs to be enabled in order for the WiFi to be able
> +			 * to connect to networks.
> +			 */
> +			ldo15 {
> +				regulator-always-on;

Do we have a min/max voltage for this regulator?

> +			};
>  		};
>  	};
>  };
> @@ -523,6 +531,13 @@ &sdh1 {
>  	pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
>  	bus-width = <4>;
>  	non-removable;
> +	#address-cells = <1>;
> +	#size-cells = <0>;

I wonder if this should have:

	vmmc-supply = <&ldo16>;

rather than regulator-always-on above.

Brian

> +
> +	wifi@1 {
> +		compatible = "marvell,sd8777";
> +		reg = <1>;
> +	};
>  };
>  
>  &pwm3 {
> -- 
> 2.51.1
> 

Re: [DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node

[Karel Balej]

Brian Norris, 2025-12-03T13:47:27-08:00:
> On Sun, Oct 26, 2025 at 07:20:41PM +0100, Karel Balej wrote:
>> Add a node for the phone's WiFi serviced by the Marvell SD8777 chip a
>> communication with which happens over the SDIO. Also enable a regulator
>> without which it is not possible to connect to networks although they
>> are discovered properly.
>> 
>> Signed-off-by: Karel Balej <balejk@matfyz.cz>
>> ---
>>  .../mmp/pxa1908-samsung-coreprimevelte.dts        | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> index b2ce5edd9c6a..36d6ae4e902e 100644
>> --- a/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> +++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts
>> @@ -475,6 +475,14 @@ ldo14: ldo14 {
>>  				regulator-min-microvolt = <1200000>;
>>  				regulator-max-microvolt = <3300000>;
>>  			};
>> +
>> +			/*
>> +			 * Needs to be enabled in order for the WiFi to be able
>> +			 * to connect to networks.
>> +			 */
>> +			ldo15 {
>> +				regulator-always-on;
>
> Do we have a min/max voltage for this regulator?

The downstream node is defined with the same values as the above ldo14,
they however are however only defined in the PMIC dtsi and correspond to
the actual physical limits of the regulator specified also in the
driver, so this doesn't really give any specific constraints for the
board itself.

The downstream code enabling WiFi seems to force it to 3300000 (which
also seems to be the startup value) unconditionally, so I suppose I will
just set the both limits to this value?

>
>> +			};
>>  		};
>>  	};
>>  };
>> @@ -523,6 +531,13 @@ &sdh1 {
>>  	pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
>>  	bus-width = <4>;
>>  	non-removable;
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>
> I wonder if this should have:
>
> 	vmmc-supply = <&ldo16>;
>
> rather than regulator-always-on above.

You mean ldo15 right?

Not having any board schematics, I don't really know what exactly the
regulator's purpose is. As I mentioned in the commit message, the
communication with the chipset seems to work even if this is disabled
(e. g. FW loads, networks can be scanned for,...) which doesn't seem
like it should be the case if this was a main power supply for the bus,
only actual connecting to networks doesn't work (gives
CONNECT_ERR_ASSOC_ERR_TIMEOUT errors).

So this didn't seem too fitting for either vmmc nor vqmmc as far as I
understand their semantics, so I went with the regulator-always-on
approach to be safe.

Thank you for the comments,
K. B.

Re: [DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node

[Duje Mihanović]

On 12/12/25 09:36, Karel Balej wrote:
> Brian Norris, 2025-12-03T13:47:27-08:00:
>>
>> Do we have a min/max voltage for this regulator?
> 
> The downstream node is defined with the same values as the above ldo14,
> they however are however only defined in the PMIC dtsi and correspond to
> the actual physical limits of the regulator specified also in the
> driver, so this doesn't really give any specific constraints for the
> board itself.
> 
> The downstream code enabling WiFi seems to force it to 3300000 (which
> also seems to be the startup value) unconditionally, so I suppose I will
> just set the both limits to this value?

This sounds reasonable to me.

>>
>>> +			};
>>>   		};
>>>   	};
>>>   };
>>> @@ -523,6 +531,13 @@ &sdh1 {
>>>   	pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
>>>   	bus-width = <4>;
>>>   	non-removable;
>>> +	#address-cells = <1>;
>>> +	#size-cells = <0>;
>>
>> I wonder if this should have:
>>
>> 	vmmc-supply = <&ldo16>;
>>
>> rather than regulator-always-on above.
> 
> You mean ldo15 right?
> 
> Not having any board schematics, I don't really know what exactly the
> regulator's purpose is. As I mentioned in the commit message, the
> communication with the chipset seems to work even if this is disabled
> (e. g. FW loads, networks can be scanned for,...) which doesn't seem
> like it should be the case if this was a main power supply for the bus,
> only actual connecting to networks doesn't work (gives
> CONNECT_ERR_ASSOC_ERR_TIMEOUT errors).

To me, this strongly suggests that the regulator powers the WiFi 
transmitter or at least a part of it (such as the RF amp).

> So this didn't seem too fitting for either vmmc nor vqmmc as far as I
> understand their semantics, so I went with the regulator-always-on
> approach to be safe.

Considering the above, I'd reckon it'd be good to have the option to 
toggle it for rfkill if anything. I'm however not sure what would be the 
right way to do so, nor how rfkill even works, if at all, with mwifiex 
(from what I see, the driver does not use the API).

Regards,
--
Duje

Re: [DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node

[Karel Balej]

Duje Mihanović, 2025-12-12T15:55:48+01:00:
> On 12/12/25 09:36, Karel Balej wrote:
>>>> +			};
>>>>   		};
>>>>   	};
>>>>   };
>>>> @@ -523,6 +531,13 @@ &sdh1 {
>>>>   	pinctrl-1 = <&sdh1_fast_pins_0 &sdh1_fast_pins_1 &sdh1_pins_2>;
>>>>   	bus-width = <4>;
>>>>   	non-removable;
>>>> +	#address-cells = <1>;
>>>> +	#size-cells = <0>;
>>>
>>> I wonder if this should have:
>>>
>>> 	vmmc-supply = <&ldo16>;
>>>
>>> rather than regulator-always-on above.
>> 
>> You mean ldo15 right?
>> 
>> Not having any board schematics, I don't really know what exactly the
>> regulator's purpose is. As I mentioned in the commit message, the
>> communication with the chipset seems to work even if this is disabled
>> (e. g. FW loads, networks can be scanned for,...) which doesn't seem
>> like it should be the case if this was a main power supply for the bus,
>> only actual connecting to networks doesn't work (gives
>> CONNECT_ERR_ASSOC_ERR_TIMEOUT errors).
>
> To me, this strongly suggests that the regulator powers the WiFi 
> transmitter or at least a part of it (such as the RF amp).

Something like this occurred to me too but would the chip even see the
networks if this was the case? Although you are right that it could only
power some specific part of the radio.

>> So this didn't seem too fitting for either vmmc nor vqmmc as far as I
>> understand their semantics, so I went with the regulator-always-on
>> approach to be safe.
>
> Considering the above, I'd reckon it'd be good to have the option to 
> toggle it for rfkill if anything. I'm however not sure what would be the 
> right way to do so, nor how rfkill even works, if at all, with mwifiex 
> (from what I see, the driver does not use the API).

I have experimented with rfkill here before. The chip has a specific pin
for this so I don't think handling the regulator alone would suffice.
But yes, it should certainly be associated with the rfkill if possible
so that it could be turned off to save power when the radio is disabled.

Brian, is it possible to attach the rfkill pin (and ideally this
regulator) to the wireless device solely through the device tree in some
generic way or must this be implemented in the driver? I have
experimented with the rfkill-gpio driver in the past but it appeared as
a separate rfkill device with its own controls independent of the
mwifiex device and I could only soft block both (soft blocking the
rfkill-gpio device of course had effect on the wifi though).

Regards,
K. B.

Re: [DONOTAPPLY RFC PATCH v2 4/4] arm64: dts: samsung,coreprimevelte: add wifi node

[Duje Mihanović]

On Friday, 12 December 2025 22:17:12 Central European Standard Time Karel 
Balej wrote:
> Duje Mihanović, 2025-12-12T15:55:48+01:00:
> > On 12/12/25 09:36, Karel Balej wrote:
> >> Not having any board schematics, I don't really know what exactly the
> >> regulator's purpose is. As I mentioned in the commit message, the
> >> communication with the chipset seems to work even if this is disabled
> >> (e. g. FW loads, networks can be scanned for,...) which doesn't seem
> >> like it should be the case if this was a main power supply for the bus,
> >> only actual connecting to networks doesn't work (gives
> >> CONNECT_ERR_ASSOC_ERR_TIMEOUT errors).
> > 
> > To me, this strongly suggests that the regulator powers the WiFi
> > transmitter or at least a part of it (such as the RF amp).
> 
> Something like this occurred to me too but would the chip even see the
> networks if this was the case? Although you are right that it could only
> power some specific part of the radio.

AFAIK you don't need the transmitter to capture and parse beacon frames. Of 
course, connecting to networks is a completely different story.

Regards,
--
Duje

Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte

[Karel Balej]

Hello,

Karel Balej, 2025-10-26T19:20:37+01:00:
> this series adds support for WiFi to the samsung,coreprimevelte
> smartphone (and can be straightforwardly reused for the other known
> Marvell PXA1908-based smartphones).
>
> The series is currently not intended for application as indicated in the
> subject prefix as the firmware necessary for the operation of the chip is not
> available in linux-firmware.
>
> Instead, my intentions are to publish the recent developments regarding
> the chip support (see the third patch of the series) and offer them for
> others to use and if possible get some feedback on them and also
> hopefully to spark some conversation with NXP regarding getting the FW
> into linux-firmware which would allow this series to be mainlined.
>
> Regarding the firmware I have been in contact with Jeff Chen of NXP some
> time ago who promised to ask about it internally – I am thus now gently
> reminding Jeff of the matter. I will also appreciate input from anyone
> else who may help with upstreaming whichever version of the firmware.
>
> The trouble of upstreaming the FW is mostly a legal one (although an up
> to date version of it would also be very welcome) as it is available as
> part of the stock Android of the devices with this chip and can thus be
> used on individual basis, it cannot however be submitted to
> linux-firmware by myself for instance as the license is not known
> (although probably is the same as for the other blobs in the mrvl
> directory) and as the submission would require a sign-off from someone
> involved with NXP.
>
> The third patch in this series fixes a serious issue with the WiFi
> observed on the phone (see the relevant commit message). The form is
> however not directly usptreamable and it is not clear to me how to best
> make it be since it involves changing a data type which probably cannot
> be easily be special-cased for the new chip and would likely break the
> other chips the mwifiex driver supports if applied as is. I will thus
> welcome suggestions on this, although I'm also hopeful that a possible
> reasonably up to date FW would not require this workaround at all.
>
> The series is based on the pxa1908-dt-for-6.19 tag of Duje's tree [1] as
> it contains the necessary SDIO description in the phone's device tree.
>
> I have not applied the trailers sent in response to v1 as it has been
> some time and as this is not expected to be applied anyway.
>
> [1] https://gitlab.com/pxa1908-mainline/linux/-/commits/pxa1908-dt-for-6.19

could I please get some feedback on this?

Mainly I'm wondering whether there is some way I could get this in (the
basic support, without the hack in the third patch) without the firmware
as I have unfortunately not been successful in my communication with NXP
yet. 

To reiterate, the firmware is generally available but is not part of
linux-firmware and the entire process of upstreaming the chipset support
is stuck on that.

Thank you, best regards,
K. B.

Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte

[Francesco Dolcini]

Hello Karel,

On Thu, Nov 27, 2025 at 04:29:12PM +0100, Karel Balej wrote:
> To reiterate, the firmware is generally available but is not part of
> linux-firmware and the entire process of upstreaming the chipset support is
> stuck on that.

I'll try to see if any of my contact in NXP Wi-Fi group is able to help. Give
me a few days.

Francesco

Re: [DONOTAPPLY RFC PATCH v2 0/4] WiFi support for samsung,coreprimevelte

[Karel Balej]

Hello, Francesco,

Francesco Dolcini, 2025-11-28T18:05:37+01:00:
> On Thu, Nov 27, 2025 at 04:29:12PM +0100, Karel Balej wrote:
>> To reiterate, the firmware is generally available but is not part of
>> linux-firmware and the entire process of upstreaming the chipset support is
>> stuck on that.
>
> I'll try to see if any of my contact in NXP Wi-Fi group is able to help. Give
> me a few days.

that's great, thank you very much!

I have received a reply from Jeff in the meantime who has discussed the
matter with his managers and unfortunately, they are not interested in
supporting this chip as it's considered outdated and would pose
maintainance burden.

Jeff however thinks that you as their customer may perhaps have more
luck when talking to them.

I am also still trying to find out whether upstreaming the old firmware
version (available as part of the stock Android) would be an acceptable
compromise for them - I never really intended for this to be supported
officially and I wasn't too hopeful about getting an up to date version
of the firmware either (although it would be very useful as it would
likely solve the issue I'm hacking around in the third patch of this
series), I mainly just want to upstream the support for the chipset as
far as possible.

Please let me know when you have some news.

Thanks again and best regards,
K. B.