Search Linux Wireless

Re: [PATCH] ath10k: Fix ASPM L1 state on QCA988X

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/10/2019, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
> (please always CC ath10k list so that ath10k patches are easy to find)
>
> Tomislav Požega <pozega.tomislav@xxxxxxxxx> writes:
>
>> On some systems there are heavy crashes if the kernel config
>> option CONFIG_PCIEASPM_PERFORMANCE is not set. Patch provided by
>> Sujith for ath9k fixes this issue and the card operates without
>> crashes with kernel default CONFIG_PCIEASPM_DEFAULT option that uses
>> BIOS provided ASPM settings. Tested with QCA9862 mPCIe card.
>>
>> Signed-off-by: Sujith Manoharan <c_manoha@xxxxxxxxxxxxxxxx>
>> Signed-off-by: Tomislav Požega <pozega.tomislav@xxxxxxxxx>
>
> So I'll summarise the discussion from patchwork:
>
> https://patchwork.kernel.org/patch/10860301/
>
> Sujith wrote this workaround first for ath9k and you ported it to
> ath10k:
>
> https://lore.kernel.org/linux-wireless/1377421989-21240-1-git-send-email-sujith@xxxxxxxxxxx/
>
> https://git.kernel.org/linus/b380a43b52be
>
> And you have PCI problems after QCA988X firmware has crashed on HP
> Compaq 6735b laptop, apparently the device just does not respond on PCI
> bus at that point. And this workaround solves the issue and you don't
> have any problems anymore.
>
> Please correct if I have misunderstood.
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -2787,14 +2787,25 @@ static int ath10k_pci_hif_power_up(struct ath10k
>> *ar,
>>  				   enum ath10k_firmware_mode fw_mode)
>>  {
>>  	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
>> +	struct pci_dev *pdev = ar_pci->pdev;
>>  	int ret;
>> +	u32 val;
>>
>>  	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif power up\n");
>>
>> -	pcie_capability_read_word(ar_pci->pdev, PCI_EXP_LNKCTL,
>> +	if (ar->dev_id == QCA988X_2_0_DEVICE_ID) {
>> +		pci_read_config_dword(pdev, 0x70c, &val);
>> +		if ((val & 0xff000000) == 0x17000000) {
>> +			val &= 0x00ffffff;
>> +			val |= 0x27000000;
>> +			pci_write_config_dword(pdev, 0x570c, val);
>> +		}
>> +	} else {
>> +		pcie_capability_read_word(ar_pci->pdev, PCI_EXP_LNKCTL,
>>  				  &ar_pci->link_ctl);
>> -	pcie_capability_write_word(ar_pci->pdev, PCI_EXP_LNKCTL,
>> +		pcie_capability_write_word(ar_pci->pdev, PCI_EXP_LNKCTL,
>>  				   ar_pci->link_ctl & ~PCI_EXP_LNKCTL_ASPMC);
>> +	}
>
> Magic values are not nice, it's better to have proper defines. Sujith
> already provided meaning for 0x70c, but I don't know what 0x570c means
> (or I guess 0x500 offset)?
>
> Also please use GENMASK() and FIELD_PREP(). Otherwise looks good to me.
>
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

I don't think the old patch from ath9k is that much relevant in this
bug case at all, since by applying it the way it is the patch actually
prevented ASPM code from execution (moved after } else { ) on
QCA988X_2_0 devices. The ASPM enable code that was commited years ago
causes regression as I've already wrote, and reverting that commit is
sufficient to have card operating properly.
When that is handled properly, this patch can then be added before or
after the ASPM enable code. Also, since the read value will obviously
differ from system to system, something like this could be used:

if ((val & 0xff000000) != 0x27000000)

0x570c should refer to programming address for this register, at least
according to reference driver.




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux