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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1571DC67861 for ; Mon, 8 Apr 2024 12:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K9M/+L9lJ/TYHFMPCrR1n/kNrRdFlI9BqEXv5v6Fkmw=; b=BnDX5RBnJIjAW4 NttjTfgoACrPqUK0D/hGpLRwhX2zpdc/RGmyatQjfqY+NhBkKt28/+hy3bhcfhgxTYMqlCpeGHaIY Yk1ns78J/OOIXBOEsmCjYrkdIAgt5gABZyZVRRmilfwBvdvgHDLz5AFsIeqMPYqVI5M58pYPIU+S8 wYGLgOA1VkkoG5fegGQmGp9V26P26CjwzFAGK9C+AZ9g5HXatfn0eK3RUvCTVsXtIQ+7n0xDAeEo4 nxPoTHN8GGlmLQlEdmopHaFln8vXimGMeHcDxhnQYFm2KMDHW1931sWSvXrUsqsPsSkaL5TuBwXBg /9GKdxajbwxYnlgnNkzw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rtnkQ-0000000FSs6-3HIt; Mon, 08 Apr 2024 12:05:14 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rtnkM-0000000FSrI-0Ht9 for linux-arm-kernel@lists.infradead.org; Mon, 08 Apr 2024 12:05:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BF31EDA7; Mon, 8 Apr 2024 05:05:36 -0700 (PDT) Received: from [10.57.54.16] (unknown [10.57.54.16]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E6CDB3F7B4; Mon, 8 Apr 2024 05:05:04 -0700 (PDT) Message-ID: Date: Mon, 8 Apr 2024 13:05:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf: arm_cspmu: Don't touch interrupt registers if no interrupt was assigned Content-Language: en-GB To: Ilkka Koskinen Cc: Besar Wicaksono , Suzuki K Poulose , Will Deacon , Mark Rutland , Raag Jadav , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20240307193104.58302-1-ilkka@os.amperecomputing.com> <042bbb32-481e-40d8-a46a-472b724ec33f@arm.com> <89d7ff41-ce2a-fd95-ebfc-4df914efd4c8@os.amperecomputing.com> From: Robin Murphy In-Reply-To: <89d7ff41-ce2a-fd95-ebfc-4df914efd4c8@os.amperecomputing.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240408_050510_319684_9581E27F X-CRM114-Status: GOOD ( 14.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024-04-05 11:33 pm, Ilkka Koskinen wrote: > > On Fri, 5 Apr 2024, Robin Murphy wrote: >> On 2024-03-07 7:31 pm, Ilkka Koskinen wrote: >>> The driver enabled and disabled interrupts even if no interrupt was >>> assigned to the device. >> >> Why's that a concern - if the interrupt isn't routed anywhere, surely >> it makes no difference what happens at the source end? > > The issue is that we have two PMUs attached to the same interrupt line. > Unfortunately, I just don't seem to find time to add support for shared > interrupts to the cspmu driver. Meanwhile, I assigned the interrupt to > one of the PMUs while the other one has zero in the APMT table. I suspected something like that ;) > Without > the patch, I can trigger "ghost interrupt" in the latter PMU. An occasional spurious interrupt should be no big deal. If it ends up as a screaming spurious interrupt because we never handle the overflow condition on the "other" PMU, then what matters most is that we never handle the overflow, thus the "other" PMU is still useless since you can't assume the user is going to read it frequently enough to avoid losing information and getting nonsense counts back. So this hack really isn't a viable solution for anything. Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel