mediatek: port patch: add tx_power check during eeprom loading for BE14

[danpawlik]

Some Banana Pi BPI-R4 BE14 WiFi modules are shipped with zeroed tx_power fields in EEPROM (2G/5G/6G). This leads to low transmit power on affected bands.

Fallback to default values if invalid EEPROM content is detected.

Original patch was done in mt76 project [1].
Related to: #17489

[1] openwrt/mt76#954

[danpawlik]

kindly ping @dangowrt what you think about that approach.

[leow149]

Any updates on this? @danpawlik @dangowrt

[danpawlik]

Kindly ping @nbd168
It's bad that we ping you directly - we know it. It is just a situation that many BE14 owners are just affected and we don't want to use custom builds to set properly tx power. Please understand us. Any feedback how it can be done better would be appreciated.

[KFOq]

@nbd168 @dangowrt @hauke
we appreciate your support to approve this patch

=====

thanks @danpawlik for following on this matter

[dangowrt]

Instead of creating a patch file in package/kernel/mt76/patches this patch should be sent upstream to the linux-wireless mailing list, merged into the wireless-next tree and then it can be picked into https://github.com/openwrt/mt76
Make sure to add Lorenzo and Felix in Cc, they are the maintainers of that driver and with their review this should go upstream.

[mhalano]

@dangowrt I think that's why @danpawlik created a new patch for openwrt instead of the original one that was for mt76.
Since it's a problem caused by the manufacturer, I don't think the Linux kernel will accept since at kernel level there is not wrong, the same reason that mt76 mentioned.
But I think openwrt could accept since it's a problem that happens in the field.

[dangowrt]

I don't think @nbd168 is willing to accept downstream patches on mt76. And as it is a "problem that happens in the field" that's a good argument for upstream Linux as well.

[mhalano]

@dangowrt So maybe we could find a middle ground and keep it as a patch for OpenWrt directly as this PR is, without trying to get upstream on mt76 or the kernel?

[danpawlik]

@dangowrt there is also similar patch done in mt76 project -openwrt/mt76#968 - where in the commit message it seems it was sent to upstream already (or they mail in cc: Cc: stable@vger.kernel.org makes confusion), but can not find it. Also I don't see any commit in kernel, that I can assume it was merged.
What I mean here is, if the patch was sent to upstream already and it is not merged, don't believe any other would be approved.

[danpawlik]

Kindly ping @yukariin as you are owner of that patch.
Also ping @im-0 as you have another patch proposed in mt76 project. May I ask if your patch was proposed to linux kernel?

[KFOq]

@yukariin @im-0. Please Your support

@danpawlik I believe we need to move from our side to get confirmation to add this patch

.....................
@dangowrt @nbd168 @hauke
Please your kindness support for this subject, based on my experience with Linux team is difficult to get their support on such things that has manufacturer fault

Im one of OpenWrt users who doesn't like to use customized build by other people ..I prefer the official one

Im sure the people are suffering from poor wifi performance on BPI-R4 because of this issue from long time , where the manufacturer left his hand and can't support or replace this defected wifi boards ...

In my humble opinion @openwrt team to add this patch under purposed file location for this device

This issue from 2024 until to now not solved and this patch will solve a huge issue..

Your support is highly appreciated by all members

[nbd168]

Sorry for not responding earlier. I believe this patch is incomplete, since the driver in those cases needs to merge data from flash or default bin with data from OTP. Also, I believe some support for external EEPROM may also be missing.
Once I have time to properly look into this, I will dig up the related patches from MTK's feed and upstream them.
Thank you for your patience.

[leow149]

Sorry for not responding earlier. I believe this patch is incomplete, since the driver in those cases needs to merge data from flash or default bin with data from OTP. Also, I believe some support for external EEPROM may also be missing.
Once I have time to properly look into this, I will dig up the related patches from MTK's feed and upstream them.
Thank you for your patience.

Great, thanks for looking into it :)

[pmarques]

Hi @nbd168 first of all thank you for all the amazing Openwrt work.

When you talk about External EEPROM, is that similar to this PR #20005 ?

I will dig up the related patches from MTK's feed and upstream them.

A few of us have been compiling the MTK Feed but we still need to hack / apply this patch to mt76 to make it work. The old mtk feed for Kernel 5.4 / Openwrt 21.04 seems to be using and mtd partition which is deprecated. Their doc also mentions a bin_file_name in the device tree but I don't think that's a available upstream #17489 (comment)

We may also be able to test a few things If you can share any pointers or guidance :)

[s09289728096]

Ah, I shoulda make a upstream RP for it but I'm too busy to solve it.
Will be great if someone can give a hand.

[PancakeTAS]

I applied this patch to my kernel fork and while it did fix the limitation issue, it also slashed my speeds. Prior to patching I was able to get ~2100 Mbps on 6 GHz, and at the same time between 800 and 1600 Mbps on another device through 5 GHz. After the patch, the moment I start transfering from the second device, the 6 GHz device halves it's speed down to only 1000 Mbps and then both stay at that speed. That's a downgrade from ~3 Gbps to ~2 Gbps. I don't know how to properly debug this any further.

From what I understand this patch loads the default EEPROM from the firmware blob if the on-device EEPROM is filled with zeroes. I don't know what's stored on the EEPROM and I don't feel like it would be capable of slowing down operation. I did try artificially setting the 6 and 7 dB power limit back onto the 5 GHz band and 2.4 GHz band, but that didn't change anything.

Any ideas on what else could possibly cause this? I mean it makes no sense, right? These are two separate radios with two separate circuits and even processors, they shouldn't influence each other?

(I'll provide debug information when I find the time to)

[PancakeTAS]

I can't believe this dumb workaround actually works

diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c
index da3231c9a..406974c31 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c
@@ -148,12 +148,23 @@ mt7996_eeprom_check_or_use_default(struct mt7996_dev *dev, bool use_default)
 		goto out;
 	}
 
-	if (!use_default && mt7996_eeprom_variant_valid(dev, fw->data))
-		goto out;
-
-	dev_warn(dev->mt76.dev, "eeprom load fail, use default bin\n");
-	memcpy(eeprom, fw->data, MT7996_EEPROM_SIZE);
-	dev->flash_mode = true;
+	// always use default tx power, regardless of use_default
+	eeprom[MT_EE_TX0_POWER_2G] = fw->data[MT_EE_TX0_POWER_2G];
+	eeprom[MT_EE_TX0_POWER_2G+1] = fw->data[MT_EE_TX0_POWER_2G+1];
+	eeprom[MT_EE_TX0_POWER_2G+2] = fw->data[MT_EE_TX0_POWER_2G+2];
+	eeprom[MT_EE_TX0_POWER_2G+3] = fw->data[MT_EE_TX0_POWER_2G+3];
+	eeprom[MT_EE_TX0_POWER_2G+4] = fw->data[MT_EE_TX0_POWER_2G+4];
+	eeprom[MT_EE_TX0_POWER_5G] = fw->data[MT_EE_TX0_POWER_5G];
+	eeprom[MT_EE_TX0_POWER_5G+1] = fw->data[MT_EE_TX0_POWER_5G+1];
+	eeprom[MT_EE_TX0_POWER_5G+2] = fw->data[MT_EE_TX0_POWER_5G+2];
+	eeprom[MT_EE_TX0_POWER_5G+3] = fw->data[MT_EE_TX0_POWER_5G+3];
+	eeprom[MT_EE_TX0_POWER_5G+4] = fw->data[MT_EE_TX0_POWER_5G+4];
+	eeprom[MT_EE_TX0_POWER_6G] = fw->data[MT_EE_TX0_POWER_6G];
+	eeprom[MT_EE_TX0_POWER_6G+1] = fw->data[MT_EE_TX0_POWER_6G+1];
+	eeprom[MT_EE_TX0_POWER_6G+2] = fw->data[MT_EE_TX0_POWER_6G+2];
+	eeprom[MT_EE_TX0_POWER_6G+3] = fw->data[MT_EE_TX0_POWER_6G+3];
+	eeprom[MT_EE_TX0_POWER_6G+4] = fw->data[MT_EE_TX0_POWER_6G+4];
 
 out:
 	release_firmware(fw);

Copies the transmit power, but nothing else. Seems to not slow down my network anymore. Someone who actually knows what the code does should probably take a look at this, not me.

[mhalano]

Nice. I will try this patch as soon as possible. It seems not the best code, but if works...

[andreabravetti]

Copies the transmit power, but nothing else. Seems to not slow down my network anymore. Someone who actually knows what the code does should probably take a look at this, not me.

Isn't it like openwrt/mt76#968? are ranges correct? +4 for 5G and +8 for 6G? and 2G?

[danpawlik]

@dangowrt hey, so you mean something like that: https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/dts/mt7986a-bananapi-bpi-r3-mini.dts#L589 ? Is it require to add new patch that removes disabled from https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.12/189-arm64-dts-mediatek-mt7988a-complete-bpi-r4.patch#L361 ?

EDIT:
ah, using overlay. so it should be something like a new file mt7988a-bananapi-bpi-r4-wifi-be14.dtso:

/dts-v1/;
/plugin/;

/ {
    compatible = "bananapi,bpi-r4", "mediatek,mt7988a";
};

&i2c_wifi {
    status = "okay";

    eeprom@50 {
        compatible = "atmel,24c02";
        reg = <0x50>;
        address-bits = <8>;
        page-size = <8>;
        size = <256>;
    };
};

/* PCIe WiFi device with EEPROM calibration data */
&pcie0 {
    wifi@0,0 {
        /* Full EEPROM data from a known-good BE14 module */
        mediatek,eeprom-data = <
            0x96790500 0x... /* ~7KB of hex calibration data */
            /* ... many lines of 32-bit hex values ... */
        >;
    };
};

then in https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/image/filogic.mk#L672 add: mt7988a-bananapi-bpi-r4-wifi-be14.dtso, for example:

DEVICE_DTS_OVERLAY:= mt7988a-bananapi-bpi-r4-emmc mt7988a-bananapi-bpi-r4-rtc mt7988a-bananapi-bpi-r4-sd mt7988a-bananapi-bpi-r4-wifi-be14

is it right?

Unfortunately, I'm not an expert on mbeded devices, so I had to take an advice from AI

[dangowrt]

is it right?

Yes exactly.

[danpawlik]

@dangowrt Proposed draft - #22447 . Will take a test today.

[danpawlik]

Going with overlay as Daniel suggested - #22447