Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 30 Nov 2022 13:29:45 +0000
From:   Will Deacon <will@kernel.org>
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Geoff Blake <blakgeof@amazon.com>, linux-kernel@vger.kernel.org,
        catalin.marinas@arm.com, kernel-team@android.com,
        linux-arm-kernel@lists.infradead.org,
        Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] perf/arm-cmn: Add shutdown routine
Message-ID: <20221130132945.GA27624@willie-the-truck>
References: <20221125230153.49468-1-blakgeof@amazon.com>
 <166973320082.112522.10687339610259452670.b4-ty@kernel.org>
 <c7acc1af-b97e-f9f7-4891-64bc9380a12e@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c7acc1af-b97e-f9f7-4891-64bc9380a12e@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Wed, Nov 30, 2022 at 12:28:17PM +0000, Robin Murphy wrote:
> On 2022-11-29 19:52, Will Deacon wrote:
> > On Fri, 25 Nov 2022 17:01:53 -0600, Geoff Blake wrote:
> > > The CMN driver does not gracefully handle all
> > > restart cases, such as kexec.  On a kexec if the
> > > arm-cmn driver is in use it can be left in a state
> > > with still active  events that can cause spurious and/or
> > > unhandled interrupts that appear as non-fatal kernel errors
> > > like below, that can be confusing and misleading:
> > > 
> > > [...]
> > 
> > Applied to will (for-next/perf), thanks!
> > 
> > [1/1] perf/arm-cmn: Add shutdown routine
> >        https://git.kernel.org/will/c/316f862a787c
> 
> Oh, if I'd seen this I'd have said the same thing as when asked about it
> off-list, that it's needlessly overcomplicated and doesn't really solve the
> problem anyway. If there's a need to be robust against spurious interrupts
> then that needs to be done in the interrupt handler.
> 
> Even if we do think it's worth stopping the PMU on shutdown, as we do on
> remove, that still only needs a single register write (per the current
> remove implementation).

Sorry Robin, I didn't spot that you weren't on cc for this. I've dropped the
patch locally and I'll update the branches later on today.

Please can you help Geoff come up with something better?

Will