Re: [PATCH v3] ACPI: introduce acpi_arch_init

[Sudeep Holla <sudeep.holla@arm.com>]

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 <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Aug 28, 2024 at 04:40:29AM +0800, Miao Wang wrote:
> > >
> > >
> > > > 2024年8月8日 17:43，Hanjun Guo <guohanjun@huawei.com> 写道：
> > > >
> > > > On 2024/8/8 17:00, Miao Wang via B4 Relay wrote:
> > > >> From: Miao Wang <shankerwangmiao@gmail.com>
> > > >> 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 <shankerwangmiao@gmail.com>
> > > >> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
> > > >> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > > >> ---
> > > >> 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 <guohanjun@huawei.com>
> > >
> > > 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