Hi Kalle, I'm happy to see Russel's patch can be merged, and I'm willing to rebase and merge those quirks into one commit and submit it again. Although the solution is not perfect, but it's nice to have. Thanks. Best regards, AceLan Kao. 2018-01-09 7:07 GMT+08:00 Daniel Drake <drake@xxxxxxxxxxxx>: > On Mon, Jan 8, 2018 at 6:24 AM, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: >> (Adding AceLan) >> >> Daniel Drake <drake@xxxxxxxxxxxx> writes: >> >>> On Wed, Nov 15, 2017 at 7:38 AM, Daniel Drake <drake@xxxxxxxxxxxx> wrote: >>>> On Tue, Nov 14, 2017 at 8:15 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: >>>>>> Can't be fixed in firmware, but it would be good to have confirmation >>>>>> of the hardware behavivour, and maybe some other solution is possible? >>>>>> Are you following this up within Qualcomm? >>>>> >>>>> No time to do that right now, sorry. >>>> >>>> I got several autoresponders from people on this thread from Qualcomm >>>> Taiwan. Would it be useful for us to drop off a sample of the affected >>>> product at your Taipei or Hsinchu office so that you can investigate >>>> further? >>> >>> Ping - how can we collaborate on this? >> >> Are you asking me? While looking at my todo list for this year I doubt I >> can find time to help with the MSI implementation or bugfixing. > > So far you are the only Qualcomm person to reply to the many mails I > have written on this topic, so I appreciate the response. I have sunk > many hours into this unfortunate situation so I'd really appreciate if > you could point me to someone at Qualcomm who can provide a response. > I am willing to continue doing the hard work, but I do need some > Qualcomm help in getting past brick walls. > >> But my plan is that first I would apply Russel's patch which makes it >> possible to enable MSI with a module parameter: >> >> https://patchwork.kernel.org/patch/9999249/ > > This isn't enough to fix many of the systems that are affected by this > issue. You add the parameter, enable it, and MSI support totally fails > to deliver any interrupts. Pasting again from earlier: > > 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. > > For more info please see: > https://marc.info/?l=linux-pci&m=150238260826803&w=2 > https://marc.info/?t=150631283200001&r=1&w=2 > https://marc.info/?l=linux-pci&m=150831581725596&w=2 > > Thanks, > Daniel
