From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AA5F02F60CC for ; Thu, 27 Aug 2026 12:34:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787834045; cv=none; b=i1WSztO/38vNcn60GI1I/DAfOrSOqOX0YA1YBVruQIi9G3bqy9dM3caNgCuwvbLXrAeDxMolKn3+9d9tcxuDjunltBQefBIKohabVoJ4YRlU8in84IRSTtDw7regciN11z+/v+wwBBNvTAO6wHsQuaGJAPHrVdkx/xkkmrPnh+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787834045; c=relaxed/simple; bh=mY3Eav+LjuHZMwXDTdn++FZAjJ/U1MT/NAZX93Cyy4U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o/WiAND2Co3lQcJrqza6sm03lFVk8/cyOQaz75jbW4MJA4TEtHAjs3dSzDKZa8zzGVg9HLt3d8dvqvpuARHmG3i3XxAe2/+f42lyM5b4Az/fyK0MVH9zJJuCUsxMKAL5bOQI+cCUqeniBaGjpqZuBWTxfcMl4xQizu2HibP2ML8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=OsFUMBHE; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="OsFUMBHE" 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 C4401169E; Thu, 27 Aug 2026 05:33:57 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DD2EF3F85F; Thu, 27 Aug 2026 05:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1787834041; bh=mY3Eav+LjuHZMwXDTdn++FZAjJ/U1MT/NAZX93Cyy4U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OsFUMBHEaz0MEEtpQe2t/mV0Bh0yAMbABVuevsnZfzq2jdkZC7jCmm1dBlOs17pWq WZ55pKQ6caopkWdxmTSrDDeBrXYHU+P0eoZQCtRXzYJLjqvkMAgpWZVClF0upnWdGN Y8BmeN/1xOQ58RPN8/J1H5NGvzOTt1q3snNZ/ufo= Date: Thu, 27 Aug 2026 14:33:50 +0200 From: Beata Michalska To: Xuewen Yan Cc: Sean Wang1 , Catalin Marinas , Will Deacon , Sudeep Holla , Greg Kroah-Hartman , "rafael@kernel.org" , Danilo Krummrich , Lifeng Zheng , Xuewen Yan , Geert Uytterhoeven , Sumit Gupta , Yunhui Cui , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "driver-core@lists.linux.dev" Subject: Re: [External] Re: [PATCH v3] arm64: topology: add source check in arch_cpu_idle_enter() Message-ID: References: <20260811072830.10028-1-seanwang1@lenovo.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Aug 27, 2026 at 05:11:28PM +0800, Xuewen Yan wrote: > On Thu, Aug 27, 2026 at 5:02 PM Beata Michalska wrote: > > > > On Mon, Aug 24, 2026 at 05:21:03PM +0800, Xuewen Yan wrote: > > > On Thu, Aug 20, 2026 at 3:11 AM Beata Michalska wrote: > > > > > > > Should we distinguish between events? > > We could although for this particular issue clearing the source is the one that > > needs attention. But I do not see why we could not have both. > > This was just sharing the idea, not a final patch. > > > > > > > --- > > > > > > > > This is just a rough idea, and needs ironing out the wrinkles, which are there, > > > > but that allows leaving the idle enter as is. I also believe this is the right > > > > approach for the interface itself, although I also see some drawbacks and > > > > potential issues (in its current state), especially that the functionality is > > > > being exposed to modules. > > > > Nevertheless, those are my two cents, untested, just sketched. > > > > > > As an aside, could we verify the functionality of the AMU's > > > SYS_AMEVCNTR0_CONST_EL0 in the current CPU before enabling amu_file? > > > To my knowledge, many chips currently have inaccurate errata in this counter. > > > Alternatively, could we introduce a command line that allows users to > > > dynamically disable this feature? > > > > > > Thanks! > > Do you have any particular issue in mind ? > > So far, from what I have been able to track, the issues reported are either > > handled by existing erratum or by the latest change that reads the counters in > > 'one go'. Can you share the details of the issue you are facing ? > > That would be helpful in potentially finding the right solution. > > For example: > There is an A725 errata: > [A725]The CNT_CYCLES event can have a significant increment error due to WFE/WFI > Status > Fault type: Programmer Category B > Fault status: Present in r0p0, r0p1, and r0p2. Open. > ...... > Workaround > There is no workaround. Right. Will be sharing a patch for that one soon. --- BR Beata > > Thanks! > > > > --- > > BR > > Beata > >