From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 209741B5824 for ; Thu, 29 Aug 2024 17:59:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724954355; cv=none; b=UHokmGOH0VfH+cd2hVssaNv/K7NAbloX+DMIL6HZV/i3/Ylbl6KXTif3xUSEaKpnIYEIDdvVYTa0U10z6UWO4vpmibb/L2mKt7h682W62QMU4kqYanhK+sYE2vOD+MgUBifz+J20ddRPrjdXJU7MG9ghY5p0YgRBUYZaJTMXy40= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724954355; c=relaxed/simple; bh=1uBP7ZtDpO7WmioTXxs7gKKRM78GV0Ri0C+m8EiT3y0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uWmGd3pVn8eg8kmc5Pr/+QhJWFx1u9z0tTeK10/itqrk9cSR3dlXPfB7NKu8KJzUPUZbTOZ5Dj6eUlVIH69PyDMJYBvdX0yfhXdwdDvl53FzsYqFJpPmxd3FEP6k7WU15KSzLJstHzR7peDRFPCmLYC22qk7DoTdotuCI6z/r6I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 636061477; Thu, 29 Aug 2024 10:59:38 -0700 (PDT) Received: from bogus (unknown [10.57.87.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5E3D83F762; Thu, 29 Aug 2024 10:59:10 -0700 (PDT) Date: Thu, 29 Aug 2024 18:58:56 +0100 From: Sudeep Holla To: "Rafael J. Wysocki" Cc: Miao Wang , Sudeep Holla , Hanjun Guo , Len Brown , Sunil V L , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3] ACPI: introduce acpi_arch_init Message-ID: <20240829175856.GA936920@bogus> References: <20240808-intro-acpi-arch-init-v3-1-ba510859baff@gmail.com> <64bd9991-61a9-5cb5-60fe-941cb4171290@huawei.com> <4EC8AF0D-321F-437B-93C6-E597E4D4BB34@gmail.com> Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Aug 29, 2024 at 06:42:16PM +0200, Rafael J. Wysocki wrote: > On Thu, Aug 29, 2024 at 6:00 PM Sudeep Holla wrote: > > > > On Wed, Aug 28, 2024 at 04:40:29AM +0800, Miao Wang wrote: > > > > > > > > > > 2024年8月8日 17:43，Hanjun Guo 写道： > > > > > > > > On 2024/8/8 17:00, Miao Wang via B4 Relay wrote: > > > >> From: Miao Wang > > > >> To avoid arch-specific code in general ACPI initialization flow, > > > >> we introduce a weak symbol acpi_arch_init. Currently, arm64 can > > > >> utillize this to insert its specific flow. In the future, > > > >> other architectures can also have chance to define their own > > > >> arch-specific acpi initialization process if necessary. > > > >> Signed-off-by: Miao Wang > > > >> Reviewed-by: Sunil V L > > > >> Reviewed-by: Sudeep Holla > > > >> --- > > > >> Changes from v1 > > > >> - Change acpi_arch_init from a static inline stub to a weak function > > > >> according to Haijun Guo's advice > > > >> --- > > > >> Changes from v2: > > > >> - Add __init attribute to the weak acpi_arch_init stub > > > >> - Link to v2: https://lore.kernel.org/r/20240807-intro-acpi-arch-init-v2-1-9231e23a7721@gmail.com > > > > > > > > Thanks for the quick update, > > > > > > > > Acked-by: Hanjun Guo > > > > > > Hi, all. I wonder whether this patch is good to be applied or > > > any improvement is needed. > > > > > > > LGTM. Rafael, do you want to take this via your tree or arm64(need your ack) > > once you are happy with the change ? > > Actually, I'd prefer the RISCV ACPI changes to land first: > > https://lore.kernel.org/linux-acpi/20240812005929.113499-1-sunilvl@ventanamicro.com/ > > and then it can be consolidated to use acpi_arch_init() in both places. > > I'm going to move the RISCV material to linux-next on Monday, but I'd > prefer to defer the consolidation to the 6.13 cycle (after 6.12-rc1 is > out). Makes sense, thanks! -- Regards, Sudeep