From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D93CC43461 for ; Fri, 11 Sep 2020 07:50:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B90B520829 for ; Fri, 11 Sep 2020 07:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599810645; bh=nRYPJjnlVsKFjfs8QXkPB5GTb07r7c2hZuIqaiaHkPc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=OfdjimC3Xdjbj5bc+QKu9qzxAZsYORcmEj/zSutKkvTi5Vefs1B+AA4eNG68W1sLf CDCAEkF5c8oz11uVxEvlIJbzq1hcbTD04CLiGFkGn4h5TzV1ZQMWqVWntzzR3i8oa2 TjUqTD76E0gfVQuEavj8kT0bmqWojJ/Q4Z4E8qQ8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725648AbgIKHuo (ORCPT ); Fri, 11 Sep 2020 03:50:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:57760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725468AbgIKHun (ORCPT ); Fri, 11 Sep 2020 03:50:43 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CD7E42076C; Fri, 11 Sep 2020 07:50:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599810643; bh=nRYPJjnlVsKFjfs8QXkPB5GTb07r7c2hZuIqaiaHkPc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CEEWrpyc+3geow4CnTiWj5CSu+r97jczejt8iq7pkQ+/c/IWKqthlU+2ca/06wL22 AoXCwNNf/Truif1lXBlYk3z3KYxQ9bG1dyRtL9XKkLg1xJdWO1ZJ/q6w88doZvigVw 4D60FwbPyi+3zohY9NYVqHKej50QkYkojAZbsYuU= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kGdpQ-00Avhn-U1; Fri, 11 Sep 2020 08:50:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 11 Sep 2020 08:50:40 +0100 From: Marc Zyngier To: Huacai Chen Cc: Thomas Bogendoerfer , Thomas Gleixner , Jason Cooper , "open list:MIPS" , Fuxin Zhang , Jiaxun Yang , stable Subject: Re: [PATCH 3/3] irqchip/loongson-pch-pic: Reserve legacy LPC irqs In-Reply-To: References: <1599624552-17523-1-git-send-email-chenhc@lemote.com> <1599624552-17523-3-git-send-email-chenhc@lemote.com> <613dd7bc4d7eeec1a5fd30f679fc83eb@kernel.org> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <6af66ab3dbf81cc1d0cf4c204ebac2b8@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: chenhc@lemote.com, tsbogend@alpha.franken.de, tglx@linutronix.de, jason@lakedaemon.net, linux-mips@vger.kernel.org, zhangfx@lemote.com, jiaxun.yang@flygoat.com, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 2020-09-11 05:13, Huacai Chen wrote: > Hi, Marc, > > On Thu, Sep 10, 2020 at 6:08 PM Marc Zyngier wrote: >> >> On 2020-09-09 05:09, Huacai Chen wrote: >> > Reserve legacy LPC irqs (0~15) to avoid spurious interrupts. >> >> How can they be spurious? Why are they enabled the first place? >> >> This looks like you are papering over a much bigger issue. > The spurious interrupts are probably occurred after kdump and the irq > number is in legacy LPC ranges. I think this is because the old kernel > doesn't (and it can't) disable devices properly so there are stale > interrupts in the kdump case. I don't really understand why the old kernel can't turn the interrupts off. Most architectures are able t, why not yours? Finally, why don't you just shut these interrupts off the first place in the interrupt controller init? Adding a whole lot of kernel data structures as a band-aid doesn't strike me as the best possible idea. Not to mention that if they keep firing, all you are doing is adding extra overhead. M. -- Jazz is not dead. It just smells funny...