+ Michał
On 3/22/2019 8:25 PM, Christian Lamparter wrote:
On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
When chip reset is done before the chip is checked if supported
there will be crash. Previous behaviour caused bootloops on
Archer C7 v1 units, this patch allows clean device boot without
excluding ath10k driver.
You need
Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe")
too
Looking at the commit subject makes me suspicious whether this is a
proper fix.
Signed-off-by: Tomislav Požega <pozega.tomislav@xxxxxxxxx>
---
drivers/net/wireless/ath/ath10k/pci.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e24403c..ec681da 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3619,12 +3619,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
- ret = ath10k_pci_chip_reset(ar);
- if (ret) {
- ath10k_err(ar, "failed to reset chip: %d\n", ret);
- goto err_free_irq;
- }
-
bus_params.dev_type = ATH10K_DEV_TYPE_LL;
bus_params.link_can_suspend = true;
bus_params.chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
It seems to me the chip reset was done explicitly *before* reading the
chipid for a reason.
"""
ath10k: reset chip before reading chip_id in probe
There are some very rare cases with some hardware
configuration that the device doesn't init quickly
enough in which case reading chip_id yielded 0.
This caused driver to subsequently fail to setup
the device.
Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx>
Signed-off-by: Kalle Valo <kvalo@xxxxxxxxxxxxxxxx>
"""
Might be the ath10k_pci_chip_reset() function needs to be modified to
work properly for Archer C7 v1 units.
Regards,
Arend
