[lkml]   [2017]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
Hi Daniel,

After applied the 2 commits you mentioned in the email, ath9k works.

Best regards,
AceLan Kao.

2017-10-05 14:39 GMT+08:00 AceLan Kao <>:
> 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 <>:
>> Hi AceLan,
>> On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao <> 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:
>> This is the ath9k MSI patch which makes use of that:
>> 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,
>> 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

 \ /
  Last update: 2017-10-13 03:13    [W:0.055 / U:6.684 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site