[PATCH v2] ath10k: Retry pci probe on failure.

[Kalle Valo]

greearb at candelatech.com writes:

> From: Ben Greear <greearb at candelatech.com>
>
> This works around a problem we see when sometimes the wifi NIC does
> not respond the first time.  This seems to happen especially often on
> some of the 9984 NICs in mid-range platforms.
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>

[...]

> -static int ath10k_pci_probe(struct pci_dev *pdev,
> -			    const struct pci_device_id *pci_dev)
> +static int __ath10k_pci_probe(struct pci_dev *pdev,
> +			      const struct pci_device_id *pci_dev)
>  {
>  	int ret = 0;
>  	struct ath10k *ar;
> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
>  	return ret;
>  }
>  
> +static int ath10k_pci_probe(struct pci_dev *pdev,
> +			    const struct pci_device_id *pci_dev)
> +{
> +	int cnt = 0;
> +	int rv;
> +	do {
> +		rv = __ath10k_pci_probe(pdev, pci_dev);
> +		if (rv == 0)
> +			return rv;
> +		pr_err("ath10k: failed to probe PCI : %d, retry-count: %d\n", rv, cnt);
> +		mdelay(10); /* let the ath10k firmware gerbil take a small break */
> +	} while (cnt++ < 10);
> +	return rv;
> +}

This is a sledgehammer approach and it causes reload for all error
cases, like when hardware is broken or memory allocation is failing.

When the problem happens does it always fail at the the same place? Is
it hw reset or something else? It's better to retry the invidiual action
than to do this hack. Or is it just some more delay needed somewhere?

-- 
Kalle Valo