lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Aug 2020 07:59:52 -0700 From: Doug Anderson <dianders@...omium.org> To: Kalle Valo <kvalo@...eaurora.org> Cc: ath10k <ath10k@...ts.infradead.org>, linux-arm-msm <linux-arm-msm@...r.kernel.org>, Brian Norris <briannorris@...omium.org>, Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>, linux-wireless <linux-wireless@...r.kernel.org>, Rakesh Pillai <pillair@...eaurora.org>, Abhishek Kumar <kuabhs@...gle.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, LKML <linux-kernel@...r.kernel.org>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH v2 1/2] ath10k: Keep track of which interrupts fired, don't poll them Hi, On Wed, Aug 26, 2020 at 7:51 AM Kalle Valo <kvalo@...eaurora.org> wrote: > > Douglas Anderson <dianders@...omium.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@...omium.org> > > Reviewed-by: Rakesh Pillai <pillair@...eaurora.org> > > Reviewed-by: Brian Norris <briannorris@...omium.org> > > Signed-off-by: Kalle Valo <kvalo@...eaurora.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? ...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? -Doug
Powered by blists - more mailing lists