* Mostly debugging infra changes;
* Some more work on the Bz family of devices;
* Bump the FW API twice;
* Some other small fixes, clean-ups and improvements.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAmIpqdMACgkQoUecoho8
xfoRWA//cbXFT32SVGjIqLINdYsU45zaNHWAaku/CbauNrRxHkTDdKv+uAQBE2q5
cevvMBUXdb/Zw+aA9BrBJ2vGhqK3oih+heFQGsTxClyoxTduVMcSyS7clZKIBPkK
n10VkGYHjpwene5es/Ub2WtIFhAJldpTNofcpvLkYubCG9fP/orjYioMpQoSOxUg
tcKQKt+mDlffGWlYDJClkU9qv+ls56GibI3hT5Jh99dYvGCzhUMV3Ec0KRURhiKg
kdPulP/eV7KqTJwEnj2kAGW1dygh9L8PWa8cgKEE6jC1hiy92Ero+u5+nyZJWnt0
KjpaZo8Uxc7x8mHQCJnOXVxX/kfeobixVdELI5pod4cuRaCH2h/pmEX4QX+QvsDs
JyJsEpC4VLGVOycsMiwx5fjhhiVXqaTOLY9GfxsCPXEvcATPbX1VjPJ2izq4/tfl
xvgcMFeUb1C7clOQIzPeOWhnjaRoVrpfGIOX+kwJVOrNu5PVZ0osv9w2+Vu0QITZ
t5VJljWHyQcKxE4kQD0BHQuQympGA33wW3TzAPbpqfac7Vu4VNNB0yu43BeXj1sG
7+HM1DeiY3S+NG3k+688RcBI0NHpTy1BhTOdUS5xlLWR8NzgK9tF3x2NeMXcYnBW
un0PKBZ63/UjyIYVGSAqUodj5JGUp298u0+QiPgtxoGgsgGro3k=
=0EkZ
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2022-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches for v5.18
* Mostly debugging infra changes;
* Some more work on the Bz family of devices;
* Bump the FW API twice;
* Some other small fixes, clean-ups and improvements.
DAV is an another efuse region that new chip, like 8852C, has this region.
Extend the code to read it, and convert the physical map to logical map
followed by original logical map.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307060457.56789-12-pkshih@realtek.com
This is a register-based H2C/C2H interface to exchange data with firmware.
Since the register addresses of 8852A and 8852C are different, add fields
to chip_info to support this.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307060457.56789-9-pkshih@realtek.com
The HCI_FUNC_EN address of 8852C is different from existing chipset, so
add a chip_info::hci_func_en_addr to fill the address individually.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307060457.56789-8-pkshih@realtek.com
New chipset uses individual power_{on/off} functions to replace old power
sequences, because it is hard to represent new complicated flow in a
sequence table.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307060457.56789-7-pkshih@realtek.com
Only 8852A may get wrong chip version if power isn't on, so it needs
additional actions to correct the version. Later chips don't need those.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307060457.56789-6-pkshih@realtek.com
We have had a struct rtw89_pci_ch_dma_addr to describe register address,
so use it as regular. Since the addresses should be changed dynamically
according to operating mode, I don't change it to be constant.
These changes don't affect the logic, so I put them in this separated
patch.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307060457.56789-5-pkshih@realtek.com
Don't populate the read-only array pktflags on the stack but
instead make it static const. Also makes the object code a little
smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307223227.165963-1-colin.i.king@gmail.com
This function exists in phy_common.c as '_rtl92c_phy_set_rf_sleep'.
Switch to the one in common file.
Signed-off-by: Lu Jicong <jiconglu58@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220306090846.28523-1-jiconglu58@gmail.com
There are two identical assignments of chip->owner to the same value,
the second assignment is redundant and can be removed.
Cleans up cppcheck warning:
drivers/bcma/driver_gpio.c:184:15: style: Variable 'chip->owner' is
reassigned a value before the old one has been used. [redundantAssignment]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220303085841.1124766-1-colin.i.king@gmail.com
Today in the code we have two options for collecting data sync/schedule,
the two options call the same function and can lead to racing in free
resources after done.
So we call only one of two sync/schedule, and in case of sync only
call sync function without also schedule to immediately run as a side
job.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220304131517.88574097ce1b.I1b42297619d638d677a2300ed9a95105c1262101@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The module param "enable_ini" is currently used to be enable/disable ini.
Add the option to configure the FW debug preset via this module param,
by change it type from boolean to an integer.
Signed-off-by: Ayala Barazani <ayala.barazani@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220304131517.4929e4b14956.I1bdffa4c37d4ee349aa0001978b716b96e38b090@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
To work properly in 6G band, declare HE 6G capabilities. Without this fix,
it can only TX/RX with OFDM rates.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220307012741.6371-1-pkshih@realtek.com
Bit 2 and 3 are reserved on 5/6 GHz and bit 1 is reserved on 2.4 GHz,
so the driver should only set the non-reserved bits according
to band.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220301004331.6621-1-pkshih@realtek.com
We found management frames get stuck when wifi chip
enters low ps mode. So we add one notify wake function
to trigger wifi chip into normal mode before forwarding
management frames.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220225030851.13327-3-pkshih@realtek.com
Declare this function allows us to use customized scanning policy, so
each scan takes less time. This is a similar implementation to hw_scan
in rtw88, except that we offload more items to firmware and extend the
maximum IE length. For backward compatibility, we fallback to sw_scan
when firmware does not support this feature.
Signed-off-by: Po Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220225030851.13327-2-pkshih@realtek.com
Calculate the offset of center and primary frequencies to get hardware
indices of center channel and primary channel, and then use them to
configure hardware to a specific channel.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220222032103.29392-1-pkshih@realtek.com
ath.git patches for v5.18. Major changes:
ath11k
* debugfs interface to configure firmware debug log level
* debugfs interface to test Target Wake Time (TWT)
* provide 802.11ax High Efficiency (HE) data via radiotap
ath9k
* use hw_random API instead of directly dumping into random.c
wcn36xx
* fix wcn3660 to work on 5 GHz band
- bugfixes
- mt7915 thermal management improvements
- SAR support for more mt76 drivers
- mt7986 wmac support on mt7915
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EABECAB0WIQR10Rp9kadxD0kAQu/XfRQdAqdu9QUCYheK5wAKCRDXfRQdAqdu
9TrDAKDNjIEsJUcuRCz51jkJOuDqhY5eBACfRkRHglOa5plg87kQpS4lCYQ1Pf4=
=Hhut
-----END PGP SIGNATURE-----
Merge tag 'mt76-for-kvalo-2022-02-24' of https://github.com/nbd168/wireless
mt76 patches for 5.18
- bugfixes
- mt7915 thermal management improvements
- SAR support for more mt76 drivers
- mt7986 wmac support on mt7915
When operating on a mix of DFS and non-DFS channels, the driver only checks
the CAC status of the control channel. This causes beacons/tx to fail if the
control channel is on a non-DFS channel.
Fix this by calling cfg80211_reg_can_beacon to determine the DFS status of
all affected channels
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Fix following coccicheck warning:
./drivers/net/wireless/mediatek/mt76/mt7915/mac.c:768:29-31:
WARNING !A || A && B is equivalent to !A || B
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Similar to mt7915 driver, do not aggregate injected frames in
HW A-MSDU block.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
By default, mt7915e does not enable thermal management until the default
thermal zone does not reach a trip point. If the rest of the system
have better cooling than the wireless hardware, then it is possible that
the wireless chip can overheat while the rest of the system is fine.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The firmware-controlled actual throttle state was previously available
by reading the cooling_device, but this confused the thermal subsystem.
Add a hwmon attribute to get it instead.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
mt7915e registers a cooling_device with wrong semantics:
1. cooling_device expect that higher states values should cool more, but
mt7915e did the opposite... with the exception of state == 0, which
should "disable thermal management", but does not seem to have any
effect since the previous state is kept.
The result is that when the thermal zone heats up a bit and bumps the
cooling_device state from 0 to 1 to cool a bit, the performance is
destroyed, and when going back from 1 to 0, the performance stays bad.
2. Reading the cooling_device state does not always return the last
written state, but can return the actual hardware throttle state,
which is different.
This is a problem because the mt7915 firmware actually implement the
equivalent of a thermal zone with trip points. Setting the cooling
device state actually changes the throttles at each trip point, so the
following could occur if the first issue is fixed:
- thermal subsystem set state to 100% power (state=0)
- mt7915e driver set trip throttles to [100%, 50%, 25%, 12%]
- hardware heats up and decides to switch to 50% power
- thermal subsystem see that power is 50% (state=50), decide to increase
it to 60% (state=40) because the rest of the system is cool.
- mt7915e driver set trip throttle to [60%, 30%, 15%, 7%]
- hardware thus switches to 30% power
[race to the bottom continues...]
This patch corrects the semantics of the cooling_device to the one that
the thermal subsystem expect it.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Instead of just taking the maximum per-chain signal strength values,
add an approximation for the sum of the combined signal.
This should more accurately reflect the real signal strength, especially
if the per-chain signal strength values are close to each other
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Use min_t() in order to make code cleaner.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The muru enable/disable are only set after the first station connection.
Without this patch, the firmware couldn't enable muru
if the first connected station is non-HE type.
Fixes: 16bff457dd ("mt76: mt7915: rework mt7915_mcu_sta_muru_tlv()")
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
