Add tx_power check during eeprom loading

[Yukariin]

Hello.
As pointed out in openwrt/openwrt/issues/17489 - some BPI-R4-BE14 cards come with a stock firmware with no tx_power values for 2.4G and 5G bands. Which basically prevents using the 2/5G band as it defaults to 6dBm.
This PR adds a basic check in mt7996_eeprom_load that reads the power value from the first channel group for each band. If any of them is zero, it falls back to loading the default firmware from the disk.
It was confirmed working on both affected and unaffected devices in the main issue.

[rmandrad]

@nbd168 ?

[razvanphp]

Would this trick also work on MT7921?

[Headcrabed]

Such kind of patch should be sent to linux kernel mail list rather than here.

[Headcrabed]

Besides, when sending patches, please rebase your patch on this repo: https://github.com/nbd168/wireless

[Headcrabed]

Also I'm not sure if your patch is doing things right... I asked someone who is more knowledged about this, he said that the actual supported TX power caculation is not only depending on MT_EE_TX0_POWER_*G but also some other parameters...

[Headcrabed]

As far as I know, Sinovoip has delibrately limited TX power for 2.4/5ghz to 20dBm to follow Chinese legal constrictions in BE14 eeprom. And the constrictions are working correctly in BPI's mtwifi-based closed-source firmware.

[morrownr]

@razvanphp

see patchwork for wifi: mt76: fix returned txpower for mt7921 and mt7925

It is a series of patches that came in today.

[razvanphp]

haha, I know, I’m the Author of that patch series 🙂

[Headcrabed]

haha, I know, I’m the Author of that patch series 🙂

@razvanphp Bro your patch really needs line wrapping XD

[razvanphp]

@Headcrabed I've sent v2 which fixes the line wrapping and also added cleanup for MT7996 as you suggested. Thanks!

[morrownr]

@razvanphp

You will hate me for this but I just noticed:

You forgot to add the following below your Signed-off :

Cc: [email protected]

That keys those that do the backports to apply it to all currently maintained kernels and we could certainly use this being applied to 6.12 for mt7925 and 6.12 and 6.6 for mt7921.

[Headcrabed]

@razvanphp

You will hate me for this but I just noticed:

You forgot to add the following below your Signed-off :

Cc: [email protected]

That keys those that do the backports to apply it to all currently maintained kernels and we could certainly use this being applied to 6.12 for mt7925 and 6.12 and 6.6 for mt7921.

I think the CC could be added in reply?

[morrownr]

@Headcrabed

I've never had a problem doing it the way I am. I think there is some code that does something to make sure it gets to where it is going.

[SockToy]

Also I'm not sure if your patch is doing things right... I asked someone who is more knowledged about this, he said that the actual supported TX power caculation is not only depending on MT_EE_TX0_POWER_*G but also some other parameters...

That may be true, but as someone with one of the affected BE14's I'll tell you that without this patch it is unusable, and with this patch loading the default fw it works fine. I think the point is not that this is replacing the TX power calculation, but rather that it detecting a known-broken firmware state and reloading with a known-good file.

Which is nice when otherwise you have several hundred dollars of junk ;p

[Jiyuu]

As far as I know, Sinovoip has delibrately limited TX power for 2.4/5ghz to 20dBm to follow Chinese legal constrictions in BE14 eeprom. And the constrictions are working correctly in BPI's mtwifi-based closed-source firmware.

This patch isn't about going above 20dBm, its about being able to go above 6dBm.
Without this patch plenty of people(me included) couldn't use 2.4/5Ghz at any power above 6dBm regardless of any other tinkering.

After the investigation we realized that the location in the eeprom that the driver is looking at is empty for many of us, while the eeprom image has the proper values there, so we concluded the eeprom is somehow wrong.
it is possible that the version should know to look elsewhere in some cases, but in any case non of us can use a firmware that doesnt have this patch, without it the banana pi is basically useless.

[Headcrabed]

As far as I know, Sinovoip has delibrately limited TX power for 2.4/5ghz to 20dBm to follow Chinese legal constrictions in BE14 eeprom. And the constrictions are working correctly in BPI's mtwifi-based closed-source firmware.

This patch isn't about going above 20dBm, its about being able to go above 6dBm. Without this patch plenty of people(me included) couldn't use 2.4/5Ghz at any power above 6dBm regardless of any other tinkering.

After the investigation we realized that the location in the eeprom that the driver is looking at is empty for many of us, while the eeprom image has the proper values there, so we concluded the eeprom is somehow wrong. it is possible that the version should know to look elsewhere in some cases, but in any case non of us can use a firmware that doesnt have this patch, without it the banana pi is basically useless.

@Jiyuu But this patch seems currently would completely neglect all calibration data inside the eeprom now. It would be better if only power data is neglected but other things from the eeprom are preserved.

[Jiyuu]

As far as I know, Sinovoip has delibrately limited TX power for 2.4/5ghz to 20dBm to follow Chinese legal constrictions in BE14 eeprom. And the constrictions are working correctly in BPI's mtwifi-based closed-source firmware.

This patch isn't about going above 20dBm, its about being able to go above 6dBm. Without this patch plenty of people(me included) couldn't use 2.4/5Ghz at any power above 6dBm regardless of any other tinkering.
After the investigation we realized that the location in the eeprom that the driver is looking at is empty for many of us, while the eeprom image has the proper values there, so we concluded the eeprom is somehow wrong. it is possible that the version should know to look elsewhere in some cases, but in any case non of us can use a firmware that doesnt have this patch, without it the banana pi is basically useless.

@Jiyuu But this patch seems currently would completely neglect all calibration data inside the eeprom now. It would be better if only power data is neglected but other things from the eeprom are preserved.

Isnt this patch basically just changing the startup sequence?
I will admit my understanding of this code is far from perfect, but it seemed to me there is an initialization process where the driver checks for the state of the eeprom, if it find a "valid" eeprom it uses it, if it detects something is off it instead loads the eeprom from the drive.
so my understanding was that this would simply catch another way that the eeprom might not be valid and therefore should be loaded from file instead of relying on the existing one..

If this understanding is wrong then I would probably agree that this patch is less appropriate for upsteaming, but then where/who should we reach out to figure this issue out, because i think this solution was basically crowdsourced by a bunch of affected people that were trying to get their hardware to work..

[Headcrabed]

I agree with this: openwrt/openwrt#17489 (comment)

[haohetao]

nice

[Headcrabed]

@Headcrabed I've sent v2 which fixes the line wrapping and also added cleanup for MT7996 as you suggested. Thanks!

@razvanphp Did you send your patch email to all output addresses from ./scripts/get_maintainers.pl? Seems you are not doing it correctly?

[haohetao]

Why hasn't this PR been merged yet?

[morrownr]

@haohetao

It is waiting to be reviewed to go in kernel 6.15:

https://patchwork.kernel.org/project/linux-wireless/list/?series=932665

[Headcrabed]

@haohetao

It is waiting to be reviewed to go in kernel 6.15:

https://patchwork.kernel.org/project/linux-wireless/list/?series=932665

@morrownr The patch you mentioned above is not related to this MR. Also it seems not working correctly. #783 (comment)

[razvanphp]

@razvanphp Did you send your patch email to all output addresses from ./scripts/get_maintainers.pl? Seems you are not doing it correctly?

No, I just sent it to the list in this list: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n14821

I think I can forward it to everybody, including the backport one.

[Headcrabed]

@razvanphp Did you send your patch email to all output addresses from ./scripts/get_maintainers.pl? Seems you are not doing it correctly?

No, I just sent it to the list in this list: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n14821

I think I can forward it to everybody, including the backport one.

@razvanphp better send it to everyone with a resend tag, like this: https://lore.kernel.org/all/TYCPR01MB84373677E45A7BFA5A28232C98792@TYCPR01MB8437.jpnprd01.prod.outlook.com/

[gregoirefavre]

There was some commits a few hours ago, is this patch still needed ?

[im-0]

There was some commits a few hours ago, is this patch still needed ?

This (or alternative) patch is still needed for BPI-R4 / BPI-R4-NIC-BE14.

[pmarques]

anybody can guide me on how to apply the patch ?

You need to compile it manually and the easiest way is to add the patch to package/kernel/mt76/patches/, for instance pmarques/openwrt@47008ea

[MatthewCroughan]

This is the only patch that fixes the issue on three of my bpi-r4's, whereas #968 does not fix the issue completely. See openwrt/openwrt#17489 (comment) for more details.

[tagatac]

What are the next steps to merge or deny this patch? It would have saved me half a day learning how to build OpenWrt yesterday if this were merged 😅

[tagatac]

This fixes the 6dBm txpower limitation on my BPI-R4 when applied as tagatac/openwrt@19c6417 on top of the v24.10.1 tag, built on Debian with the default config for BPI-R4, and flashed to an SD card, or applied as a sysupgrade to an existing 24.10.1 installation on eMMC

[Critter74]

maybe the maintainers are still in hibernation ;)
I vote for merge with master