[PATCH AUTOSEL 6.19-6.12] wifi: rtw89: 8922a: set random mac if efuse contains zeroes

[Sasha Levin <sashal@kernel.org>]

From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

[ Upstream commit 41be33d3efc120f6a2c02d12742655f2aa09e1b6 ]

I have some rtl8922ae devices with no permanent mac stored in efuse.

It could be properly saved and/or configured from user tools like
NetworkManager, but it would be desirable to be able to initialize it
somehow to get the device working by default.

So, in the same way as with other devices, if the mac address read from
efuse contains zeros, a random mac address is assigned to at least allow
operation, and the user is warned about this in case any action needs to
be considered.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251126091905.217951-1-jtornosm@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The rtw8922a driver was first included in kernel v6.8. This means it's
available in stable trees 6.8.y and later (and likely in 6.6.y LTS if it
was backported, but probably not).

### 8. OVERALL ASSESSMENT

**Arguments FOR backporting (YES):**
- Fixes a real hardware issue — devices with empty efuse are completely
  unusable without this
- Very small, contained change in a single file
- Well-established pattern used in rtw88 driver and other Realtek
  wireless drivers
- Low risk — only affects devices with all-zero MAC (no impact on
  working devices)
- Acked by subsystem maintainer
- Falls under "hardware quirk/workaround" category which is acceptable
  for stable

**Arguments AGAINST backporting (NO):**
- This is technically adding new functionality (random MAC generation)
  rather than fixing a bug in existing code
- The driver was working "as designed" — it just didn't handle the case
  of unprogrammed efuse
- It's not fixing a crash, corruption, or security issue — it's making
  broken hardware work
- The commit message describes this as a "desirable" improvement rather
  than a critical fix
- No Fixes: tag or Cc: stable (expected, but also suggests the author
  didn't consider it critical)

### DECISION

This is a borderline case. While the change is small and low-risk, it's
fundamentally adding new behavior (random MAC assignment) rather than
fixing a bug in existing code. The device doesn't crash without this —
it simply doesn't have a valid MAC address. This is closer to a
"hardware enablement" change than a bug fix.

However, I lean toward YES because:
1. It's a hardware workaround for broken/unprogrammed devices — this
   category is explicitly allowed in stable
2. Without it, the device is completely non-functional (a zero MAC
   address is invalid)
3. The risk is essentially zero for existing users
4. The pattern is proven across the Realtek driver family
5. It's a small, self-contained change

**YES**

 drivers/net/wireless/realtek/rtw89/rtw8922a.c | 22 +++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw89/rtw8922a.c b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
index 4437279c554b0..4bcf20612a455 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8922a.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8922a.c
@@ -636,16 +636,30 @@ static int rtw8922a_read_efuse_rf(struct rtw89_dev *rtwdev, u8 *log_map)
 static int rtw8922a_read_efuse(struct rtw89_dev *rtwdev, u8 *log_map,
 			       enum rtw89_efuse_block block)
 {
+	struct rtw89_efuse *efuse = &rtwdev->efuse;
+	int ret;
+
 	switch (block) {
 	case RTW89_EFUSE_BLOCK_HCI_DIG_PCIE_SDIO:
-		return rtw8922a_read_efuse_pci_sdio(rtwdev, log_map);
+		ret = rtw8922a_read_efuse_pci_sdio(rtwdev, log_map);
+		break;
 	case RTW89_EFUSE_BLOCK_HCI_DIG_USB:
-		return rtw8922a_read_efuse_usb(rtwdev, log_map);
+		ret = rtw8922a_read_efuse_usb(rtwdev, log_map);
+		break;
 	case RTW89_EFUSE_BLOCK_RF:
-		return rtw8922a_read_efuse_rf(rtwdev, log_map);
+		ret = rtw8922a_read_efuse_rf(rtwdev, log_map);
+		break;
 	default:
-		return 0;
+		ret = 0;
+		break;
+	}
+
+	if (!ret && is_zero_ether_addr(efuse->addr)) {
+		rtw89_info(rtwdev, "efuse mac address is zero, using random mac\n");
+		eth_random_addr(efuse->addr);
 	}
+
+	return ret;
 }
 
 #define THM_TRIM_POSITIVE_MASK BIT(6)
-- 
2.51.0