Introduce RT6352 instead of matching against RF7620.
Clean up channel setting rfvals.
Port bandwidth filter calibration.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
So here is another round of improvements for MT7620 WiFi.
This commit fixes a few significant issues related to TX_PWR_CFG_x and
TX_ALC and also makes the code more readable by adding register
descriptions for things added for MT7620 and use the usual bit-field
access macros and the now defined macros instead of plain bit-ops and
magic numbers.
Properly describe EEPROM_TARGET_POWER at word 0x68 (== byte 0xD0) and
thereby fix internal TXALC which would otherwise just read
out-of-bounds of the EEPROM map.
Split-out tx-power/ALC related stuff into an additional function.
Fix VCO calibration, it was carried out properly in the channel
switching but incomplete in the actual VCO calibration function.
Also there is no need to trigger VCO calibration in channel switching,
the VCO calibration function is already being called at this point.
Remove it from channel switching function to avoid redundant code.
The TX power calibration differs significantly from all other
Mediatek/Ralink chips: They finally allow 0.5dB steps stored as 8-bit
values for (almost) each bitrate -- and promptly ran out of space and
for some reason didn't want to change the EEPROM layout. The hence
opted for a scheme of sharing values for some adjecent bitrates and
a highly over-complicated (or obfuscated?) way to populate the
TX_PWR_CFG_x registers with the values stored in the EEPROM.
The code here now looks much less complicated than what you see in the
vendor's driver, however, it does the exact same thing:
bGpwrdeltaMinus is a constant and always TRUE, hence half of the
code was dead. Gpwrdelta is always 0 (rather than using the value read
from the EEPROM). What remains is some very grotesque effort to avoid
0x20, probably some hardware bug related to some misunderstanding of
what a singed 8-bit value is (imagine: if it was a signed 6-bit value
then someone could believe that 0x20 == 0x0). And then they didn't
clean it up once they later on anandonned that whole story of having a
constant offset for 40 MHz channels and just set the offset to be
constant 0 -- there is no effort for avoiding 0x20 for the 20 MHz
values stored in the EEPROM, hence that's probably just a forbidden
value in the EEPROM specs and won't appear anyway...
Anyway, the whole thing felt like solving some college math test
where in the end everything cancels out and the result equals 0 ;)
To make sure that channel bandwidth power compensation really doesn't
need to be taken care of, output a warning when the corresponding
value stored in the EEPROM is non-zero.
Also there is no apparent reason to refrain from initializing RFCSR
register 13, it doesn't fail what-so-ever.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Open-code usb_phy_generic_register instead of calling it, since it is
really trivial. Avoid pulling CONFIG_NOP_USB_XCEIV into the kernel
config and add a proper dependency instead
Signed-off-by: Felix Fietkau <nbd@nbd.name>
If ehci platform driver is loaded before the chipidea controller driver,
both are competing for the same IO resources and the generic driver gets
used for the hardware. This results in USB device mode being
unavailable.
Split generic EHCI support code out of kmod-usb2, so that the chipidea
driver can be included without also pulling in the generic one. Also
rework the load order, so that the chipidea driver gets loaded first, in
case both are installed
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The following will enable the TPM kernel module, as well as support for
the atmel i2c TPM driver. Tested and confirmed working on an Aerohive
AP-121
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
This is required for default wireless configuration of malta target to
work out of the box again. Fixes "77ece30e: hostapd: Add ability to
specify that that wireless driver supports 802.11ac"
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
This patch splits `kmod-mt76` into three separate packages:
`kmod-mt76-core`, `kmod-mt76x2` and `kmod-mt7603`. By making
`kmod-mt76` a metapackage containing these new packages,
the previous behaviour of including all drivers and firmware
is left unchanged, unless explicitly unselected in
`DEVICE_PACKAGES`.
This splitting is especially beneficial for devices with
small flash chips, since the `kmod-mt76` package currently
requires ~160K on squashfs (after compression).
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cleanup]
Effects of the bugs could include memory corruption, tx hangs, kernel
crahes, possibly other things as well
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Remove CONFIG_VLAN_8021Q overrides for two targets
These features are built into the kernel image for all targets
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This commit combines all the changes I've made on my staging tree
into a single commit fixing many issues with our patch for MT7620.
First of all, checkpatch.pl revealed numerous code style issues with
the patch, so fix all the white-space and commets. Also use
usleep_range instead of legacy timing and relax timing for VCO
calibration just like the vendor driver does.
Several line programming registers were commented out in the patch.
Originally this came from the features present but disabled by default
in the vendor's driver (RTMP_TEMPERATURE_CALIBRATION and
ADJUST_POWER_CONSUMPTION_SUPPORT). Remove the dead code for now, it can
easily be re-added if we actually intend to support those features.
Move values from mt7620_freqconfig type into the existing rf_channel
struct, this shouldn't be a new typedef and it is possible to use the
existing struct because rf_channel got 4 32-bit fields, so two of the
8-bit values from mt7620_freqconfig can easily be stored in the same
32-bit field.
Map values such that
Rdiv -> rf1
N -> rf2
K -> rf3[0:7]
D -> rf3[8:15]
Ksd -> rf4
This makes the channel switching logic already look a bit more like
what we are used to in rt2x00... Probably many of the read-modify-write
calls could still be replaced by macros intended for that.
iq calibration seems to be identical to RT5592, so just enable it.
Test shows that this improves things quite a lot, datarates went up
by a couple of megabits when running iperf, signal quality seems jumpy
in the first few seconds once a station connencts, the stabelizes on a
value significantly better than what it was before.
Add description to the patch and reference the original OpenWrt commit
by which it was added.
The patch now passes checkpatch.pl and can thus be discussed with the
upstream authors of the rt2x00 driver.
Funded-by: https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede/
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Lots of users try random stuff when they encounter any kind of
difficulty. I've had to debug a number of cases where people had enabled
this option for no reason. Hopefully this warning will reduce the number
of useless support cases.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
I needed a moment to figure out relation between this patchset and the
nl80211: fix validation of scheduled scan info for wowlan netdetect
It appears nl80211 commit will go on top of brcmfmac changes so it's
safe to backport these patches.
One patch that was excluded is commit 2a2a5d1835b6 ("brcmfmac: add
.update_connect_params() callback") as it depends on missing commit
088e8df82f91 ("cfg80211: Add support to update connection parameters").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
