Daniel Drake <drake@xxxxxxxxxxxx> 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=1", 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=1/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. -- Kalle Valo
