Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp888573imj; Fri, 15 Feb 2019 08:25:54 -0800 (PST) X-Google-Smtp-Source: AHgI3IaQ5daVUpL40tZROmZJ3E09niA75hbxuTZ2MreReLYjxwgVtVf/ST0RmpUv1Xd4QDDga2Ti X-Received: by 2002:a63:3541:: with SMTP id c62mr6163655pga.191.1550247954492; Fri, 15 Feb 2019 08:25:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550247954; cv=none; d=google.com; s=arc-20160816; b=J5SELimQGDeDnTmex5tayxGZf3ZczMvD0cJ2WkCwlQni5t0xrtzueYNVaWIlgj/nWk kgSJOZPL7+2fPGG4YIaV9PpizYfQHBy/LWFBOIZ2T2QuzVldBHaqXrivtliEBfqu3Hef 0pz64w6FvpoyUZMvHyfstHE67SsaAk0rq0m4wXRWrmWQVZ60S6rsP4hVqAdCHEWd30eW lNEQXY3DgmKIJsHopB/u39N4Z6S2l8HFgGixRzQeMZ72A1uLczNTHbcb+IW+yqJUd92u ekXxp9W2iVqNYFoiqYrHff2/xm3ZFi5VSgO3ndHrgzMmPb8NNjmjgqp/4H+pK6iW+hat 9UZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Y3YidLSkctVvsadv+w4uyst5vc5Sf2Xv/gtBWgdSpmc=; b=DGTW9Pexj8dwWlt9H6D0F2CaCjO7r7SIS+JEWd9c9erg2pt1Egr21lnD5Hy4XcHhJV 2HX2H1ZdIpo3Hv+mZqzCbP0BG/PK2Q81TUgDuYFzmqk7Ui6Wb+BZ5un5mj4w6hd/0wef Gkjg5FeP/JjfsSJD9l19Gkt/qjQ19V+Br0LWe2TE1gbdiryuWRK9N0KoFcQ4de5sau4J Rs2iy36Mx9jOlupI/Gc1BbDpn5mRuk9Jqc13EN8uzvLKyfuAzZ2saBU1XZZNiNsUlHhG +Dnm9bWJdDrs5b3RTJ2rr5ftU02iQmkCMz3PrC88lyeYyNPnYPs/h1dZLgigdzzB2vgI /12Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s11si5649788pgk.344.2019.02.15.08.25.38; Fri, 15 Feb 2019 08:25:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730100AbfBOPAX (ORCPT + 99 others); Fri, 15 Feb 2019 10:00:23 -0500 Received: from foss.arm.com ([217.140.101.70]:33158 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726139AbfBOPAX (ORCPT ); Fri, 15 Feb 2019 10:00:23 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6BC9CEBD; Fri, 15 Feb 2019 07:00:22 -0800 (PST) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7AD773F675; Fri, 15 Feb 2019 07:00:20 -0800 (PST) Date: Fri, 15 Feb 2019 15:00:15 +0000 From: Will Deacon To: Jeremy Linton Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, catalin.marinas@arm.com, mark.rutland@arm.com, robert.moore@intel.com, erik.schmauss@intel.com, rafael.j.wysocki@intel.com, lenb@kernel.org Subject: Re: [RFC 2/3] arm_pmu: acpi: spe: Add initial MADT/SPE probing Message-ID: <20190215150015.GA6803@fuggles.cambridge.arm.com> References: <20190209004718.3292087-1-jeremy.linton@arm.com> <20190209004718.3292087-3-jeremy.linton@arm.com> <20190214171125.GG2475@fuggles.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 14, 2019 at 12:03:57PM -0600, Jeremy Linton wrote: > On 2/14/19 11:11 AM, Will Deacon wrote: > > On Fri, Feb 08, 2019 at 06:47:17PM -0600, Jeremy Linton wrote: > > > +/* > > > + * For lack of a better place, hook the normal PMU MADT walk > > > + * and create a SPE device if we detect a recent MADT with > > > + * a homogeneous PPI mapping. > > > + */ > > > +static int arm_spe_acpi_parse_irqs(void) > > > +{ > > > + int cpu, ret, irq; > > > + u16 gsi = 0; > > > + bool first = true; > > > + > > > + struct acpi_madt_generic_interrupt *gicc; > > > + > > > + /* > > > + * sanity check all the GICC tables for the same interrupt number > > > + * for now we only support homogeneous ACPI/SPE machines. > > > + */ > > > + for_each_possible_cpu(cpu) { > > > + gicc = acpi_cpu_get_madt_gicc(cpu); > > > + > > > + if (gicc->header.length < ACPI_MADT_GICC_SPE) > > > + return -ENODEV; > > > + > > > + if (first) { > > > + gsi = gicc->spe_overflow_interrupt; > > > + if (!gsi) > > > + return -ENODEV; > > > + first = false; > > > + } else if (gsi != gicc->spe_overflow_interrupt) { > > > + pr_warn("ACPI: SPE must have homogeneous interrupts\n"); > > > + return -EINVAL; > > > + } > > > > Unfortunately, I don't think this is sufficient to detect a homogeneous > > system: we'll have to check the MIDRs instead, which is nasty. I would > > personally be in favour of enforcing homogeneity for ACPI systems when we > > bring up secondary CPUs, but I suspect others would disagree. > > Given that all the SPE capable machines i'm aware of at the moment are > homogeneous, are we ok with just doing an online CPU MIDR check for now, and > cleaning that up if/when someone builds a machine and complains? Yeah, I think we added a new bit to the PPTT to tell you that the machine is homogenous, so just check that first and bail if it's not set. Will