From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 530E0C3DA4A for ; Sat, 27 Jul 2024 06:52:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:CC:To: Subject:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PDFZQp6yRfoXpB+WE4cc+3z9ByTflDslCEAFZr0o2wE=; b=q3UE1ciokrP5xmPf3LrTYu2xgj nsPGYy3bqz3S+Wu+QumtcENeLARGULJ4AdZgmkKkdAPNLA9Oaolzb+h9W41SQedm5dOJvNYk7pUvR If3crwjzxxeLZDEdkUKfwkJA9yD7gFgovHcOqPfqtJFDxk8hCqvHNZAQW8V6YjsOTRkVzSyfi/6xW 1keva1ehOMm5NdIFxdPsCOo3ZKSFasWfvU9unFmIjGlCamwG/H5s9qvzddT8w+5cScG1N2R7oMNfV sRpPdMYDQZhuzDvwddCCrlQ8ZQqk2IK6lILAG7RQkKLTCMQ2EqAIEQUW3aVe9bb/uw1SLR+Uk8jR6 qgd5VgcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXbIM-00000006DRM-0EbA; Sat, 27 Jul 2024 06:52:46 +0000 Received: from szxga02-in.huawei.com ([45.249.212.188]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXbHv-00000006DPU-2ry2 for linux-arm-kernel@lists.infradead.org; Sat, 27 Jul 2024 06:52:21 +0000 Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4WWFdV05k4znbTc; Sat, 27 Jul 2024 14:51:10 +0800 (CST) Received: from dggpemf500002.china.huawei.com (unknown [7.185.36.57]) by mail.maildlp.com (Postfix) with ESMTPS id 22BC81800A1; Sat, 27 Jul 2024 14:52:03 +0800 (CST) Received: from [10.174.178.247] (10.174.178.247) by dggpemf500002.china.huawei.com (7.185.36.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 27 Jul 2024 14:52:02 +0800 Subject: Re: [PATCH] ACPI: rename acpi_arm_init to acpi_arch_init To: Miao Wang , Sunil V L CC: Sudeep Holla , , , "Rafael J. Wysocki" , Len Brown References: <446b96d0-4b61-11ef-9239-3f7ac1938848@innull.com> <1A59AB2E-58A6-4D9F-9976-DABFAA825EE0@gmail.com> From: Hanjun Guo Message-ID: Date: Sat, 27 Jul 2024 14:52:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1A59AB2E-58A6-4D9F-9976-DABFAA825EE0@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.247] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf500002.china.huawei.com (7.185.36.57) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240726_235219_921817_73E69151 X-CRM114-Status: GOOD ( 14.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024/7/27 2:23, Miao Wang wrote: > >> 2024年7月27日 01:55，Sunil V L 写道： >> >> On Sat, Jul 27, 2024 at 12:39:03AM +0800, Miao Wang wrote: >>> Hi, >>> >>> Thanks for your quick reply. >>> >>>> 2024年7月27日 00:05，Sudeep Holla 写道： >>>> >>>> On Fri, Jul 26, 2024 at 11:03:01PM +0800, Miao Wang via B4 Relay wrote: [...] >>>>> >>>>> -#ifdef CONFIG_ARM64 >>>>> -void acpi_arm_init(void); >>>>> +#ifdef ACPI_HAVE_ARCH_INIT >>>>> +void acpi_arch_init(void); >>>> >>>> This is bit inconsistent. The Makefile is still conditional on >>>> CONFIG_ARM64 while here you move to ACPI_HAVE_ARCH_INIT. >>>> So while not just undefine and redefine acpi_arch_init to acpi_arm_init. >>>> Something like this must work ? >>>> >>>> #define acpi_arch_init() do { }while(0) >>>> >>>> #ifdef CONFIG_ARM64 >>>> #undef acpi_arch_init >>>> #define acpi_arch_init() acpi_arm_init() >>>> #endif >>> >>> It will work. However I can see the pattern in other parts, where >>> the definition of a macro named HAVE_xxx is checked, and define an >>> inline static function with empty body if such macro is not defined >>> or define a function prototype with the same name otherwise, like >>> acpi_arch_set_root_pointer. I'm just trying to follow this pattern. >>> >> I was thinking to make it weak function similar to cpc_read_ffh(). >> Wouldn't it be better than ifdefery? > > I believe there would be performance loss for those arches with a stub > function definition if a weak function is used (correct me if wrong). > So the approach with a static inline stub is more common in the kernel > code. ACPI init is not in the hot code path, no worries for the performance loss. Weak function is my preference too :) Thanks Hanjun