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: stable@vger.kernel.org

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: stable@vger.kernel.org

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 ?

[mhalano]

Could you elaborate or point to the correct bug? I got the same value on all radios, 2.4, 5 and 6 GHz, and I need to restart the 6GHz, since it doesn't work if I reset the 2.4or the 5GHz ones, to get the correct values in all radios, not just the 6GHz.
I thought it was related since it's also a problem with getting the correct TX power values.

This is probably related to your issue: openwrt/openwrt#16548

Maybe, the funny part is I get 255 in all radios. Just after restarting the 6GHz radio I got the readings correct.

[mhalano]

@leow149 Yeah, I think I have the issue you mentioned. I got just 255 dBm for 6GHz interface using iwinfo.
You can see the TX power values are correct, just the menu for maximum TX power that shows the wrong value.
Thanks.

[Critter74]

I think its time to merge this patch with master @nbd168
Or have any1 a better idea?

[mhalano]

My two cents: it would be better to merge the other patch in openwrt/openwrt. I say that because the code for mt76 is fine, the real problem is with the manufacturer that didn't add the values in the eeprom, so since it's a problem we see in the wild, openwrt could add a patch there.

[Critter74]

It doesn't help anyone if this issue is pushed back and forth between the two repos, openwrt/openwrt and openwrt/mt76.
It's time to act.

[mhalano]

Sorry, I didn't see openwrt/openwrt pushing this change back to openwrt/mt76.

I also think we should approve, just not here.

[Critter74]

Could someone please create a patch in OpenWrt? Repo? I would do it, but I'm not familiar with it.

Thank you

[danpawlik]

@Critter74 it is already there for a while: openwrt/openwrt#19503.

[Critter74]

Thank you!
Sorry, I overlooked that

[mhalano]

I'm using this patch and it seems after commit b4d6b6c98697e0153ae17ca30e95f1219742270c, which updates mt76, it doesn't work anymore.
I'm removing the patch to check if a solution is available upstream.