From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs Date: Mon, 12 Jun 2017 19:11:34 -0700 Message-ID: <20170613021134.GT20170@codeaurora.org> References: <1496147943-25822-1-git-send-email-kgunda@codeaurora.org> <1496147943-25822-6-git-send-email-kgunda@codeaurora.org> <20170531015753.GW20170@codeaurora.org> <67dbf9dd211f4a8703e1076ba0818044@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:41630 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753122AbdFMCLg (ORCPT ); Mon, 12 Jun 2017 22:11:36 -0400 Content-Disposition: inline In-Reply-To: <67dbf9dd211f4a8703e1076ba0818044@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: kgunda@codeaurora.org Cc: Abhijeet Dharmapurikar , Subbaraman Narayanamurthy , Christophe JAILLET , David Collins , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, adharmap@quicinc.com, aghayal@qti.qualcomm.com, linux-arm-msm-owner@vger.kernel.org On 06/06, kgunda@codeaurora.org wrote: > On 2017-05-31 07:27, Stephen Boyd wrote: > >On 05/30, Kiran Gunda wrote: > >>From: Abhijeet Dharmapurikar > >> > >>We see a unmapped irqs trigger right around bootup. This could > >>likely be because the bootloader exited leaving the interrupts > >>in an unknown or unhandled state. Ack and mask the interrupt > >>if one is found. A request_irq later will unmask it and also > >>setup proper mapping structures. > > > >Do we have systems where this is causing an interrupt storm due > >to a level high interrupt or something? Just plain acking and > >masking irqs at boot if we don't have an irq descriptor created > >yet doesn't sound like a good idea, because we'll lose all > >interrupts that happen before this driver probes? > > > Yes. There were instances of an interrupt storm without this patch. > There is an RT_STATUS register in the peripheral address space which > maintains the real time state and can be read by the client driver > before it registers for the irq. Few client drivers such as charger > already doing this. So you're saying that drivers need to read RT_STATUS to know if they have a pending interrupt before requesting it? That sounds bogus. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project