Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp5415936rwb; Tue, 1 Aug 2023 02:03:56 -0700 (PDT) X-Google-Smtp-Source: APBJJlFpscRkPJqn+7tOtw3GlrA8CJcVfk/ptxJyQtAZK3TGqPpUnvukY7LcnsuUjvBW3jdoK1F/ X-Received: by 2002:a17:903:481:b0:1bb:c971:ef92 with SMTP id jj1-20020a170903048100b001bbc971ef92mr9588540plb.59.1690880635637; Tue, 01 Aug 2023 02:03:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690880635; cv=none; d=google.com; s=arc-20160816; b=GPELbs+XKdnLEZi5obe+WyBHlEZT3SEEWsm3lrcCytMZ4P74uTzNPTsDxZnikyXee7 vZDrFTv9D2RbIUiKREIT0q8260bjAiCuovXjhDcqy32NXtthAPFTjJKMfg/Ws/sjmxPN YvNz+JOI6H1mcDYvYozYUKOx30/7p82SZnLgX5wJQuepDnHK+2YbAqeUiAUzx8NQAMxk hQfHlQRLa8qwJVoS76iEQtQ6grsttyGPa/h8HMVwMSt2qpDSa0L/hlCIwaPpKJDVGVh/ Zy0zpe/8gX8zNOIn/vsh8ACLe9gvHQrLsIAyO3Sv05pM1d9rKlH2Y9YYUNlVl3+ZeIVV Pi7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=y7cPlTg8UworIQNOe8mJ9cOVtIIGJsE3xyoduhf1+KI=; fh=wXQHeUX2YWiyX4bejncPsbaHlLxl5ufU21pcvgJ56lo=; b=PSU7/5WUichWWE71eI3wRcyruqnQBE6RwZsL6BZ3RAqyyjLtYZqcg6Wbu4ph22am6e ZiCY6rZI1U7mxk12IWb5d6gQ13xUKo6ab5wGA61su2rPLsSTU76vnNfXQA/TB4Dj6Jx7 hD9IgapN3+ZKmSSjPdf7yx/uOogz7yWvL10pLNwhm1mBQbaoscix//Gsa35ZAy/yH+iK YTk99khzw/Bs37BsaDU23uGdNc9C6DLPkYnn8N9P05kvoY56GRvRIcbloV3M8akblzSb nkdyZFwzHuLsXBe11WQMY6IVU2AAZAa0TZiD290TU4nTWL7ugEg1UgV8d6WchAucTcPo Rq8w== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kz14-20020a170902f9ce00b001b8944aa943si8605354plb.315.2023.08.01.02.03.43; Tue, 01 Aug 2023 02:03:55 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231624AbjHAIxp (ORCPT + 99 others); Tue, 1 Aug 2023 04:53:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231133AbjHAIxo (ORCPT ); Tue, 1 Aug 2023 04:53:44 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6E5881711 for ; Tue, 1 Aug 2023 01:53:43 -0700 (PDT) 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 61688D75; Tue, 1 Aug 2023 01:54:26 -0700 (PDT) Received: from [10.163.53.114] (unknown [10.163.53.114]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF3B43F5A1; Tue, 1 Aug 2023 01:53:40 -0700 (PDT) Message-ID: <3380a12b-605e-394c-c711-e31ce4112e60@arm.com> Date: Tue, 1 Aug 2023 14:23:38 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 1/3] arm_pmu: acpi: Add a representative platform device for TRBE Content-Language: en-US To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com, Catalin Marinas , Mark Rutland , linux-kernel@vger.kernel.org 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> <20230801073857.GB25854@willie-the-truck> From: Anshuman Khandual In-Reply-To: <20230801073857.GB25854@willie-the-truck> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,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 8/1/23 13:08, Will Deacon wrote: > 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. Sure. If it's okay, will use your Co-developed-by/Signed-off-by tags for this refactoring patch.