On Thu, Jun 12, 2025 at 04:29:50PM +0000, Shiju Jose wrote: [...] > > > >Just curious, would the new "faux" bus work for this use case? > > I tried with "faux" interface, following are the observations. > 1. RAS2 scrub control interface do present and work under /sys/bus/faux/devices/... > as expected. However it does not appear under /sys/bus/edac/devices/... as required. > It seems that the reason for this is that, with the faux device, the RAS2 faux probe function > and thus edac_dev_register() is called during the early boot stage, compared to the probe > of the present auxiliary device based solution. > I think EDAC is not fully initialized at that boot stage? > This issue is solved with late_initcall(acpi_ras2_init) instead of calling acpi_ras2_init() > from acpi_init() (drivers/acpi/bus.c). > > 2. The faux_device_create() function takes a struct faux_device_ops *, which requires the > faux_device_ops for RAS2 to be defined within this driver (drivers/acpi/ras2.c). Therefore, > registration with EDAC for RAS features may necessitate moving to a *ras2_faux_probe() > function here. This would also require moving the struct edac_scrub_ops ras2_scrub_ops and > the corresponding callback functions from drivers/ras/acpi_ras2.c to this location. > Alternatively, we could add and export a ras2_faux_init() function in drivers/ras/acpi_ras2.c > and call it from *ras2_faux_probe(). > > Thus not sure "faux" is a suitable interface for RAS2? > Right, maybe not. Or could be something to look at later. I only became aware of the "faux" interface recently, so I just thought to ask. :) Thanks, Yazen
