Re: [PATCH 4/4] EDAC/mc_sysfs: Begin deprecating legacy sysfs EDAC interface

Naik, Avadhut
2025-10-30T14:52:14Z

On 10/29/2025 12:24, Borislav Petkov wrote:
> + Greg to tell us whether that would be a proper deprecation strategy.
>
> On Mon, Oct 13, 2025 at 05:30:43PM +0000, Avadhut Naik wrote:
>> The legacy sysfs EDAC interface has been made obsolete more than a decade
>> ago through the introduction of a new per-DIMM interface.
>>
>> The legacy interface however, hasn't been removed till date.
>>
>> Begin deprecating it so that it can eventually be removed by v6.21.
>>
>> Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
>> ---
>> drivers/edac/Kconfig | 2 +-
>> drivers/edac/edac_mc.h | 5 +++++
>> drivers/edac/edac_mc_sysfs.c | 16 ++++++++++++++++
>> 3 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index 39352b9b7a7e..fdfeba848114 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -25,7 +25,7 @@ if EDAC
>>
>> config EDAC_LEGACY_SYSFS
>> bool "EDAC legacy sysfs"
>
> Add "DEPRECATED: EDAC ..."
>
> here.
>
Okay!
>> - default y
>> + default n
>> help
>> Enable the compatibility sysfs nodes.
>> Use 'Y' if your edac utilities aren't ported to work with the newer
>> diff --git a/drivers/edac/edac_mc.h b/drivers/edac/edac_mc.h
>> index 881b00eadf7a..78b49d6906fd 100644
>> --- a/drivers/edac/edac_mc.h
>> +++ b/drivers/edac/edac_mc.h
>> @@ -95,6 +95,11 @@ do { \
>>
>> #define to_mci(k) container_of(k, struct mem_ctl_info, dev)
>>
>> +static inline void deprecate_interface(void)
>> +{
>> + pr_warn_once("NOTICE: The legacy EDAC sysfs interface has been deprecated and will be removed by v6.21. Please switch to the new interface!\n");
>> +}
>
> You don't need to have a function which you replicate everywhere. Simply dump
> this notice once...
>
> edac_create_sysfs_mci_device:
>
> ...
>
> #ifdef CONFIG_EDAC_LEGACY_SYSFS
>
> <--- here.
>
> err = edac_create_csrow_objects(mci);
> if (err < 0)
> goto fail;
> #endif
>
> So that it gets issued and hopefully someone sees it.
>
> Then, I'd say around 6.19 we should make those functions return an error
> unconditionally and then zap them in 6.21.
>
> That is, if no one comes crawling out of the woodwork with a valid use case.
>
> Thx.
>
Sounds good! Will do!

Just one question:

Wouldn't it be more prudent to have a log of our intentions available when someone
tries to access or read stuff the old interface too?

--
Thanks,
Avadhut Naik