Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp5355303rwb; Tue, 1 Aug 2023 00:46:23 -0700 (PDT) X-Google-Smtp-Source: APBJJlGlbcONqVNSDR+tl5tLrfPFj0eIyLXRx8pRTX5kvQIpqYFv0e+MDPoQgJrAgMX0lj24qi8B X-Received: by 2002:a05:6808:13c9:b0:3a4:7afb:2ac6 with SMTP id d9-20020a05680813c900b003a47afb2ac6mr14739413oiw.44.1690875983388; Tue, 01 Aug 2023 00:46:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690875983; cv=none; d=google.com; s=arc-20160816; b=L52HokHby29aTQh7fQPHaWcaXw2pforbYOFqvsvHRPL41rRabNLETtwEKJfM4gCqeB p/3XFDsWmDMC9NSkx9hKWpi/OLB6mXUfOcujswkJ+BTRdyjcjlOShFZt4bciseCS7uVA 50HC+VhOU+g8xJg40quFwEHuJNOENrX5sS3N3jqVnqeh55WdEaym62Hc7I6+eHZq+KlL aIRf4g8LFl7sNp/LLCg+3ucyF68Ozw/iN9so4EyREBHy/zMju9xz01sxXb/U+Xj6DCdy y0KgWZHxW3YFlfSrEX29srng7zAPmplaze9wV/USnY6AMYPIaXi7qCcrBC7wdIUeWRtV D8rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=LaKL3FSFkJUNNlvpbHg6KeSuPfWDgJYZbCZZ2xSkGJg=; fh=rP1wqdNNppR78dp50hstggubIp8hTsZfm4IB+1rAXI0=; b=lFFzDpxhSfmRMNKsRK5sfaoNWPC7pfycACGZnyNbUqbjsWnC7f2t8aN96mB4ex7or1 8Wv/v2URygoy9QLKSXMzrhi0vQWZ3V4qjRQ+M5+swcDlybUKa3w7nXFqkMhi5iV9sz9F d4nfq8Jrw5Le9xIdW9rCargSAgC1aC+6Bu7Jm7BP3ADdmVcxAYK9uIfw+TlkskO1+BL+ uiQppYpuCjzhN795WU1szVQqUYMOEYjfkymvVSs9m6Cwf18V49dx2PPL6NN5wFTHWPYj 1qjlFgKjDPYxlhqS+hduIjzjYvXTd0TUswbQuqPBMVcxrBBGs77lxo3KPfybYk4tgX7H P5tA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gZFNsDxU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d10-20020a170902654a00b001bba894ac4asi8687755pln.274.2023.08.01.00.46.10; Tue, 01 Aug 2023 00:46:23 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gZFNsDxU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231641AbjHAHjI (ORCPT + 99 others); Tue, 1 Aug 2023 03:39:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229904AbjHAHjG (ORCPT ); Tue, 1 Aug 2023 03:39:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 776E6E4 for ; Tue, 1 Aug 2023 00:39:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1F55F614AE for ; Tue, 1 Aug 2023 07:39:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43641C433C8; Tue, 1 Aug 2023 07:39:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690875543; bh=wwBgT18fdpN0KXFIrhM72nS2dRxAnqmy34KeChSDIbw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gZFNsDxU+dWNETreZWJZKhdqsJ9HV277bK9dY5ji0DIr4M1CpJzjE6HW4RWtY0/aN f0/tDjQxg4Rs/wEhgUJLiwUPavnaiLbt6fpJ/zooFqBSY7/9Fkn+AvmyoNnsxyVTAW Jg/fzRY5Eu8JmQw8rAGCavlAUgcig6AszCEyCFPgHdQzyWiCAelnvPU4poRgZmBHK2 YV0wnllckczij6MQOrth/uJLIURqyJCWeO3Z9buPYtVsSscGOiWXGK86F++tNcGRPj dP4IRJ4kpO/aSSjVm8vSxaQFMo+ue8ZHzsNi5oLfiE9K93DfoLLRpcaqQxL3P40gWT 6PuFW80SMDF+w== Date: Tue, 1 Aug 2023 08:38:58 +0100 From: Will Deacon To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com, Catalin Marinas , Mark Rutland , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] arm_pmu: acpi: Add a representative platform device for TRBE Message-ID: <20230801073857.GB25854@willie-the-truck> References: <20230728112733.359620-1-anshuman.khandual@arm.com> <20230728112733.359620-2-anshuman.khandual@arm.com> <20230728144056.GE21718@willie-the-truck> <3ee165d7-3727-53cc-295d-a2108734952d@arm.com> <20230731145922.GB24881@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 01, 2023 at 09:05:54AM +0530, Anshuman Khandual wrote: > > > On 7/31/23 20:29, Will Deacon wrote: > > On Mon, Jul 31, 2023 at 05:38:38PM +0530, Anshuman Khandual wrote: > >> On 7/28/23 20:10, Will Deacon wrote: > >>> On Fri, Jul 28, 2023 at 04:57:31PM +0530, Anshuman Khandual wrote: > >>>> diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c > >>>> index 90815ad762eb..dd3df6729808 100644 > >>>> --- a/drivers/perf/arm_pmu_acpi.c > >>>> +++ b/drivers/perf/arm_pmu_acpi.c > > > > [...] > > > >>>> + ret = platform_device_register(&trbe_acpi_dev); > >>>> + if (ret < 0) { > >>>> + pr_warn("ACPI: TRBE: Unable to register device\n"); > >>>> + acpi_unregister_gsi(gsi); > >>>> + } > >>>> +} > >>>> +#else > >>>> +static inline void arm_trbe_acpi_register_device(void) > >>>> +{ > >>>> + > >>>> +} > >>>> +#endif /* CONFIG_CORESIGHT_TRBE */ > >>> > >>> This looks like you ran s/spe/trbe/ over the SPE device registration > >>> code :) > >> > >> Yeah, almost :) > >> > >>> Please can you refactor things so we don't have all the duplication? I > >>> suspect this won't be the last device which needs the same treatement. > >> > >> Should the refactoring just accommodate SPE, and TRBE or make it more generic to > >> accommodate future devices as well. Something like the following enumeration. > >> > >> enum arm_platform_device { > >> ARM_PLATFORM_DEVICE_SPE, > >> ARM_PLATFORM_DEVICE_TRBE, > >> ARM_PLATFORM_DEVICE_MAX, > >> }; > >> > >> But that would require adding some helper functions to select these following > >> elements based on the above enumeration via a common function > >> > >> - gicc->XXX_interrupt > >> - ACPI_MADT_GICC_SPE/TRBE for header length comparison > >> - static struct platform_device/resources (static objects in the file) > >> > >> Seems like will add much more code for a refactor. Did you have something else > >> in mind for the refactor. > > > > All I'm saying is that we shouldn't have identical copies of the code to > > walk the MADT, pull out the irqs and register the device. > > > > So something like the totally untested hack below. I probably broke > > something, but hopefully you see what I mean. > > > > Will > > > > --->8 > > > > diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c > > index 90815ad762eb..7f1cf36c6e69 100644 > > --- a/drivers/perf/arm_pmu_acpi.c > > +++ b/drivers/perf/arm_pmu_acpi.c > > @@ -69,6 +69,62 @@ static void arm_pmu_acpi_unregister_irq(int cpu) > > acpi_unregister_gsi(gsi); > > } > > > > +static int > > +arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len, > > + u16 (*parse_gsi)(struct acpi_madt_generic_interrupt *)) > > This factored out helper should be wrapped inside CONFIG_ARM_SPE_PMU > and CONFIG_CORESIGHT_TRBE ? Otherwise, there will be no callers left > for this helper triggering warning. > > drivers/perf/arm_pmu_acpi.c:73:1: warning: ‘arm_acpi_register_pmu_device’ defined but not used [-Wunused-function] > 73 | arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > But in that case, we have to keep adding new configs when new devices > require platform devices to be registered. Is there a better way ? __maybe_unused? Like I said, I didn't test that thing at all, I was just trying to illustrate the sort of refactoring I had in mind. Will