Messages in this thread |  | | From | Kalle Valo <> | Subject | Re: [PATCH v2 1/2] ath10k: Keep track of which interrupts fired, don't poll them | Date | Tue, 01 Sep 2020 15:14:31 +0300 |
| |
Doug Anderson <dianders@chromium.org> writes:
> On Wed, Aug 26, 2020 at 7:51 AM Kalle Valo <kvalo@codeaurora.org> wrote: >> >> Douglas Anderson <dianders@chromium.org> wrote: >> >> > If we have a per CE (Copy Engine) IRQ then we have no summary >> > register. Right now the code generates a summary register by >> > iterating over all copy engines and seeing if they have an interrupt >> > pending. >> > >> > This has a problem. Specifically if _none_ if the Copy Engines have >> > an interrupt pending then they might go into low power mode and >> > reading from their address space will cause a full system crash. This >> > was seen to happen when two interrupts went off at nearly the same >> > time. Both were handled by a single call of ath10k_snoc_napi_poll() >> > but, because there were two interrupts handled and thus two calls to >> > napi_schedule() there was still a second call to >> > ath10k_snoc_napi_poll() which ran with no interrupts pending. >> > >> > Instead of iterating over all the copy engines, let's just keep track >> > of the IRQs that fire. Then we can effectively generate our own >> > summary without ever needing to read the Copy Engines. >> > >> > Tested-on: WCN3990 SNOC WLAN.HL.3.2.2-00490-QCAHLSWMTPL-1 >> > >> > Signed-off-by: Douglas Anderson <dianders@chromium.org> >> > Reviewed-by: Rakesh Pillai <pillair@codeaurora.org> >> > Reviewed-by: Brian Norris <briannorris@chromium.org> >> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> >> >> My main concern of this patch is that there's no info how it works on other >> hardware families. For example, QCA9984 is very different from WCN3990. The >> best would be if someone can provide a Tested-on tags for other hardware (even >> some of them). > > I simply don't have access to any other Atheros hardware. Hopefully > others on this thread do, though?
I have the hardware but in practise no time to do the testing :/
> ...but, if nothing else, I believe code inspection shows that the only > places that are affected by the changes here are: > > * Wifi devices that use "snoc.c". The only compatible string listed > in "snoc.c" is wcn3990. > > * Wifi devices that set "per_ce_irq" to true. The only place in the > table where this is set to true is wcn3990. > > While it is certainly possible that I messed up and somehow affected > other WiFi devices, the common bits of code in "ce.c" and "ce.h" are > fairly easy to validate so hopefully they look OK?
Basically I would like to see some evidence in the commit log that _all_ hardware families are taken into account to avoid any regressions, be it testing or at least thorough review. I see way too many patches where people are working just on one hardware/firmware combo and not giving a single thought how it would work on other hardware.
But I applied the three patches now, let's hope they are ok. At least I was not able to find any problems during review, but of course real testing would be better than just review.
-- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
|  |