Hi Daniel, After applied the 2 commits you mentioned in the email, ath9k works. https://marc.info/?l=linux-wireless&m=150631274108016&w=2 https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 Best regards, AceLan Kao. 2017-10-05 14:39 GMT+08:00 AceLan Kao <acelan.kao@xxxxxxxxxxxxx>: > Hi all, > > Please drop my patches, Qualcomm is working internally and will submit > the MSI patch by themselves. > Thanks. > > Hi Daniel, > > I'll try your patches tomorrow. > > Best regards, > AceLan Kao. > > 2017-10-02 12:21 GMT+08:00 Daniel Drake <drake@xxxxxxxxxxxx>: >> Hi AceLan, >> >> On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao <acelan.kao@xxxxxxxxxxxxx> wrote: >>> Hi Daniel, >>> >>> I've tried your patch, but it doesn't work for me. >>> Wifi can scan AP, but can't get connected. >> >> Can you please clarify which patch(es) you have tried? >> >> This is the base patch which adds the infrastructure to request >> specific MSI IRQ vectors: >> https://marc.info/?l=linux-wireless&m=150631274108016&w=2 >> >> This is the ath9k MSI patch which makes use of that: >> https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 >> >> If you were already able to use ath9k MSI interrupts without specific >> consideration for which MSI vector numbers were used, these are the >> possible explanations that spring to mind: >> >> 1. You got lucky and it picked a vector number that is 4-aligned. You >> can check this in the "lspci -vvv" output. You'll see something like: >> Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+ >> Address: 00000000fee0300c Data: 4142 >> The lower number is the vector number. In my example here 0x42 (66) is >> not 4-aligned so the failure condition will be hit. >> >> 2. You are using interrupt remapping, which I suspect may provide a >> high likelihood of MSI interrupt vectors being 4-aligned. See if >> /proc/interrupts shows the IRQ type as IR-PCI-MSI >> Unfortunately interrupt remapping is not available here, >> https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023717.html >> >> 3. My assumption that all ath9k hardware corrupts the MSI vector >> number could wrong. However we've seen this on different wifi modules >> in laptops produced by different OEMs and ODMs, so it seems to be a >> somewhat widespread problem at least. >> >> 4. My assumption that ath9k hardware is corrupting the MSI vector >> number could be wrong; maybe another component is to blame, could it >> be a BIOS issue? Admittedly I don't really know how I can debug the >> layers inbetween seeing the MSI Message Data value disagree with the >> vector number being handled inside do_IRQ(). >> >> Daniel
