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 5A37EC3DA49 for ; Fri, 26 Jul 2024 18:25:05 +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:To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=THBvAPKKoZ+vsoz9t6UaOmfjXawep1fZfGgaZL/1yYE=; b=Uk/BIKmf6hEaFd/7Y0eEPA4Arf cpnf15Uch9nmonAbSz4YHWTDuHGiNAjg2DrrBXu3g83PN4ahxRSdWdOkrknpHkhy7RS4aKsNNdbIY r/M+w3xRNSSDEJjlcNQ+DQakfIzvCf2M91E5HparQLU245OiAdsTIYHGVOuc1C98/MX44eWol5oA0 yJW9HtksUaOF4OHdNmPQBTJW7THTXS4XvO91t2u49RJPMG512ETwk7KL6QBGefRrOylebh4XOXhyo a7hq9W0L3PmIAdHHGx5hwzWLFbE1PvugUuFmJwDGcNph6H5d3WzFqRJFSWEa0c+9nrCdXcZYMjkB7 vByj75fQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXPcb-00000004fSU-1y5K; Fri, 26 Jul 2024 18:24:53 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXPbm-00000004fKy-3wgG for linux-arm-kernel@lists.infradead.org; Fri, 26 Jul 2024 18:24:04 +0000 Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1fd66cddd07so8320485ad.2 for ; Fri, 26 Jul 2024 11:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722018242; x=1722623042; darn=lists.infradead.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=THBvAPKKoZ+vsoz9t6UaOmfjXawep1fZfGgaZL/1yYE=; b=N4L4bxsuFWFuCi1lsBfmZur/XavBgjQr3z0V/fuPtTTGKvJnnDYLB2uxRRQpQVzeLR 9eh9cU+OObp/sqUtJb3khC/ksQ8E3D4k11BEwTmxPo+E3pm/5FzcQK0g4+fdlBXZeAXL NKrR7BG/UrnsHrIZUg1M4375UH7g/2iE8U0KjIpMru6MIUZe4hQaP1m4zyRmNJQ300W7 z2iap2LKQg+zoMEMjGwVTwe/XnhprmR8QyWVfnvBy6SrOxq+o4sExbSQlGgoiZTC76VP VJLvFwsHS+cpZKYRvUQSwKczgF+xP8CAqA/2j2JpHrry5fvf3j3JA2DiSO9nxdgxECEs i5mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722018242; x=1722623042; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=THBvAPKKoZ+vsoz9t6UaOmfjXawep1fZfGgaZL/1yYE=; b=jf773E52rBth+lylVFR+XRWPyDypDkoJavrqq34LOS3Yuno0giHnitqrfkL8m6Xfi7 g7vRL9+ZJG36Uaiqivzq8gOZs7Oh7hUqmHG/ToExOq71Ze4SqifbeFDAYzEs/s+icDX+ fqn52Zsuf7wmmfE7m99gVYAIgmnYig3ZsLm08qIegj1xL6Lks6dC0DTLZE6hySu3eRzf wqigNweZnYzFy9W4YHM1+PpCwOZEp85Xc3nDhBDYJ523GpgfuLc+91mgXTjHVj67g5JT LP7WpmaOlVT20pNsclftyKONnQaIhpqhg0LEAExU+X/NgQONgcdjQTzdP/z8vP76sx5Q YeuA== X-Forwarded-Encrypted: i=1; AJvYcCWUzbPITAOilCj2c6Whp836S2lA0UXJTAD+eb0wBUparUXvoVdLDZ22jRhVz5e6vKEt+RoGXD+dPA+2kdyjdos9HqzoiH3U/ZIin20TLcjfR5RUKto= X-Gm-Message-State: AOJu0Yz4SoP8UBjuDYxd9RqlXX10a88WvpUkSftxchSE2lxDNsUCFgj0 vFTxGishI6WJQ/SKPAAkzx5yOnzFP+PLcMapKliJ1EZ6hQ+2I7uY X-Google-Smtp-Source: AGHT+IHIPspasYIEYYItlIVyGSxQu8fkWzwR8pfaH7cv/7C7zYCW1M75JsV//f8iDk+nBqj4XS/NmQ== X-Received: by 2002:a17:902:db06:b0:1fd:6529:7447 with SMTP id d9443c01a7336-1ff0485b001mr5731535ad.29.1722018241381; Fri, 26 Jul 2024 11:24:01 -0700 (PDT) Received: from smtpclient.apple (va133-130-115-230-f.a04e.g.tyo1.static.cnode.io. [2400:8500:1301:747:a133:130:115:230f]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fed7f1aa18sm36051745ad.190.2024.07.26.11.23.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2024 11:24:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PATCH] ACPI: rename acpi_arm_init to acpi_arch_init From: Miao Wang In-Reply-To: Date: Sat, 27 Jul 2024 02:23:43 +0800 Cc: Sudeep Holla , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Rafael J. Wysocki" , Len Brown , Hanjun Guo Content-Transfer-Encoding: quoted-printable Message-Id: <1A59AB2E-58A6-4D9F-9976-DABFAA825EE0@gmail.com> References: <446b96d0-4b61-11ef-9239-3f7ac1938848@innull.com> To: Sunil V L X-Mailer: Apple Mail (2.3774.600.62) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240726_112403_007378_4A82B286 X-CRM114-Status: GOOD ( 27.01 ) 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 > 2024=E5=B9=B47=E6=9C=8827=E6=97=A5 01:55=EF=BC=8CSunil V L = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Sat, Jul 27, 2024 at 12:39:03AM +0800, Miao Wang wrote: >> Hi, >>=20 >> Thanks for your quick reply. >>=20 >>> 2024=E5=B9=B47=E6=9C=8827=E6=97=A5 00:05=EF=BC=8CSudeep Holla = =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> On Fri, Jul 26, 2024 at 11:03:01PM +0800, Miao Wang via B4 Relay = wrote: >>>> From: Miao Wang >>>>=20 >>>> So that we avoid arch-specific code in general ACPI initialization = flow. >>>> Other architectures can also have chance to define their own >>>> arch-specific acpi initialization process if necessary. >>>>=20 >>>=20 >>> Nice, but I assume you are adding something similar to another = arch(riscv >>> or loongarch ?). It would be nice to have those changes as well = together to >>> make it easy to understand the intention much quicker. >>=20 >> Yes, you are right about it. I'm trying to add some codes for = loongarch, >> after DSDT is loaded and namespace is created, before the devices are >> enumerated, so I'll have chance to add a _DEP method to one of the = device >> using acpi_install_method to provide compatibility for some early = loongarch >> devices which are produced before the loongarch related ACPI standard = is >> finalized. >>=20 > I have arch-specific initialization need for RISC-V as well. So, good = to > see this patch!. >=20 >>>=20 >>>> Signed-off-by: Miao Wang >>>> --- >>>> arch/arm64/include/asm/acpi.h | 2 ++ >>>> drivers/acpi/arm64/init.c | 2 +- >>>> drivers/acpi/bus.c | 2 +- >>>> include/linux/acpi.h | 6 +++--- >>>> 4 files changed, 7 insertions(+), 5 deletions(-) >>>>=20 >>>> diff --git a/arch/arm64/include/asm/acpi.h = b/arch/arm64/include/asm/acpi.h >>>> index a407f9cd549e..0d24e920e143 100644 >>>> --- a/arch/arm64/include/asm/acpi.h >>>> +++ b/arch/arm64/include/asm/acpi.h >>>> @@ -188,4 +188,6 @@ static inline void acpi_map_cpus_to_nodes(void) = { } >>>>=20 >>>> #define ACPI_TABLE_UPGRADE_MAX_PHYS MEMBLOCK_ALLOC_ACCESSIBLE >>>>=20 >>>> +#define ACPI_HAVE_ARCH_INIT >>>> + >>>=20 >>> There is nothing core arm66 arch specific in acpi_arm_init() and = hence it >>> is in drivers/acpi/arm64. I would like to avoid adding anything in = arch/arm64 >>> if possible. Also I don't think we need to define this = ACPI_HAVE_ARCH_INIT >>>=20 >>>> #endif /*_ASM_ACPI_H*/ >>>> diff --git a/drivers/acpi/arm64/init.c b/drivers/acpi/arm64/init.c >>>> index d0c8aed90fd1..7a47d8095a7d 100644 >>>> --- a/drivers/acpi/arm64/init.c >>>> +++ b/drivers/acpi/arm64/init.c >>>> @@ -2,7 +2,7 @@ >>>> #include >>>> #include "init.h" >>>>=20 >>>> -void __init acpi_arm_init(void) >>>> +void __init acpi_arch_init(void) >>>=20 >>> Keep the name acpi_arm_init as is. >>>=20 >>>> { >>>> if (IS_ENABLED(CONFIG_ACPI_AGDI)) >>>> acpi_agdi_init(); >>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c >>>> index 284bc2e03580..662f69e379ef 100644 >>>> --- a/drivers/acpi/bus.c >>>> +++ b/drivers/acpi/bus.c >>>> @@ -1458,7 +1458,7 @@ static int __init acpi_init(void) >>>> acpi_viot_early_init(); >>>> acpi_hest_init(); >>>> acpi_ghes_init(); >>>> - acpi_arm_init(); >>>> + acpi_arch_init(); >>>=20 >>> Here we need acpi_arch_init() like you have changed. >>>=20 >>>> acpi_scan_init(); >>>> acpi_ec_init(); >>>> acpi_debugfs_init(); >>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h >>>> index f0b95c76c707..3c3a83499c2d 100644 >>>> --- a/include/linux/acpi.h >>>> +++ b/include/linux/acpi.h >>>> @@ -1517,10 +1517,10 @@ static inline int = find_acpi_cpu_topology_hetero_id(unsigned int cpu) >>>> } >>>> #endif >>>>=20 >>>> -#ifdef CONFIG_ARM64 >>>> -void acpi_arm_init(void); >>>> +#ifdef ACPI_HAVE_ARCH_INIT >>>> +void acpi_arch_init(void); >>>=20 >>> 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 ? >>>=20 >>> #define acpi_arch_init() do { }while(0) >>>=20 >>> #ifdef CONFIG_ARM64 >>> #undef acpi_arch_init >>> #define acpi_arch_init() acpi_arm_init() >>> #endif >>=20 >> 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. >>=20 > 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. Cheers, Miao Wang