Re: [v2] ath9k: add MSI support

[Kalle Valo <kvalo@qca.qualcomm.com>]

Daniel Drake <drake@endlessm.com> writes:

>> On new Intel platforms like ApolloLake, legacy interrupt mechanism
>> (INTx) is not supported
>
> Could you please share the background on what you are claiming here.
> I have multiple ApolloLake laptops here with many legacy interrupts
> being used in /proc/interrupts.
>
> I do see this ath9k problem on multiple Acer ApolloLake laptops, however
> I also have an Asus E402NA ApolloLake laptop on hand where the exact same
> ath9k miniPCIe card is working fine with legacy interrupts.
>
>> With module paremeter "use_msi=3D1", ath9k driver would try to
>> use MSI instead of INTx.
>
> In the previous patch review it was suggested that MSI should become
> the default - not a quirk or parameter.
> https://lkml.org/lkml/2017/9/26/64

Enabling MSI by default is just too invasive, ath9k is used in so many
different enviroments that risk of regressions is high. MSI needs a lot
of testing before we can even consider enabling it by default.

> I have tested your patch on Acer Aspire ES1-432. It does not work -
> I still can't connect to wifi.
> /proc/interrupts shows that no MSI interrupts are delivered, the
> counters are 0.
>
> lspci -vv shows:
>         Capabilities: [50] MSI: Enable+ Count=3D1/4 Maskable+ 64bit+
>                 Address: 00000000fee0f00c  Data: 4142
>                 Masking: 0000000e  Pending: 00000000
>
> So MSI is enabled and the vector number is 0x42 (decimal 66).
> However my kernel log is now totally spammed with:
>   do_IRQ: 0.64 No irq handler for vector
>
> My assumption here is that the ath9k hardware implementation of
> MSI is buggy, and it is therefore corrupting the MSI vector number
> by zeroing out the lower 2 bits (e.g. 66 -> 64).
>
> It would be very useful if Qualcomm could confirm if this behaviour
> is really true and if it could potentially be fixed with a new ath9k
> firmware version.

ath9k does not have firmware.

--=20
Kalle Valo=