The shared reset procedure of MT7610 and MT7612 stop all queues before
starting the reset sequence.
They however never restart these like other supported mt76 chips
do in the reconfig_complete call. This leads to TX not continuing
after the reset.
Restart queues in the reconfig_complete callback to restore
functionality after the reset.
Signed-off-by: David Bauer <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Restart the MCU and release the patch semaphore before loading the MCU
patch firmware from the host.
This fixes failures upon error recovery in case the semaphore was
previously taken and never released by the host.
This happens from time to time upon triggering a full-chip error
recovery. Under this circumstance, the hardware restart fails and the
radio is rendered inoperational.
Signed-off-by: David Bauer <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
The default timeout set in mt76_connac2_mcu_fill_message of 20 seconds
leads to excessive stalling in case messages are lost.
Testing showed that a smaller timeout of 5 seconds is sufficient in
normal operation.
Signed-off-by: David Bauer <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Increase the timeout for MCU_EXT_CMD_EFUSE_BUFFER_MODE command.
Regular retries upon hardware-recovery have been observed. Increasing
the timeout slightly remedies this problem.
Signed-off-by: David Bauer <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
When operating two VAP on a MT7610 with encryption (PSK2, SAE, OWE),
only the first one to be created will transmit properly encrypteded
frames.
All subsequently created VAPs will sent out frames with the payload left
unencrypted, breaking multicast traffic (ICMP6 NDP) and potentially
disclosing information to a third party.
Disable GTK offloading and encrypt these frames in software to
circumvent this issue. THis only seems to be necessary on MT7610 chips,
as MT7612 is not affected from our testing.
Signed-off-by: David Bauer <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
