Re: [PATCH] firmware: SDEI: Allow sdei initialization without ACPI_APEI_GHES

[Huang Yiwei <quic_hyiwei@quicinc.com>]

> On Mon, Apr 28, 2025 at 05:56:23PM +0800, Huang Yiwei wrote:
>> SDEI usually initialize with the ACPI table, but on platforms where
>> ACPI is not used, the SDEI feature can still be used to handle
>> specific firmware calls or other customized purposes. Therefore, it
>> ......
>>   	}
>> +
>> +	return ret;
>>   }
>> +#ifndef CONFIG_ACPI_APEI_GHES
>> +subsys_initcall_sync(sdei_init);
>> +#endif
> 
> Using an initcall purely for the non-ACPI case feels like a hack to me.

Yeah, I agree with you actually, but to address the dependency chain 
issue highlighted in commit dc4e8c07e9e2 ("ACPI: APEI: explicit init of 
HEST and GHES in acpi_init()"), where the following relationships need 
to be maintained:

     ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init()
     ghes_init() => sdei_init()

> Could we instead just call sdei_init() from the arch code (and remove
> the call from acpi_ghes_init()) so that the platform device is
> registered at the same time, regardless of the firmware?
> 
> Will

I propose splitting sdei_init() into two separate functions: sdei_init() 
and acpi_sdei_init(). This way, sdei_init() will be called by 
arch_initcall and will only initialize the platform driver, while 
acpi_sdei_init() will initialize the device from acpi_ghes_init() when 
ACPI is ready. This approach should help maintain the dependency chain 
without causing any breaks.

     sdei_init --> platform_driver_register
     arch_initcall(sdei_init)

     acpi_init
         acpi_bus_init();
         acpi_hest_init();
         acpi_ghes_init();
             acpi_sdei_init(); --> platform_device_register_simple
     subsys_initcall(acpi_init);