Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753386AbdFMCLh (ORCPT ); Mon, 12 Jun 2017 22:11:37 -0400 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 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 305DE60796 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Mon, 12 Jun 2017 19:11:34 -0700 From: Stephen Boyd 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 Subject: Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs 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 Content-Disposition: inline In-Reply-To: <67dbf9dd211f4a8703e1076ba0818044@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1354 Lines: 30 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