On Fri Jul 31, 2026 at 4:28 AM CEST, Borislav Petkov wrote:
> On Thu, Jul 30, 2026 at 10:35:20PM +0200, Michael Walle wrote:
>> I don't get what you are trying to say. CONFIG_EDAC_MPC85XX is
>> enabled in the that config already.
>
> You mean, *because* CONFIG_EDAC_MPC85XX is =y, then RAS=y? I guess that is
> true for this particular config.

No. CONFIG_RAS is not set although CONFIG_EDAC_MPC85XX is set.
Because CONFIG_RAS was *automatically* selected before the mentioned
commit.

>> It's just that the mentioned commit broke it because it removed the "select
>> RAS", while EDAC depends on it.
>
> No, that commit dropped a select statement which is good in its own right.

And while doing that it will break (at least) the corenet32_smp_defconfig,
because it removes the "select RAS" (which was on the EDAC_MM_EDAC symbol).

How would that work without adding CONFIG_RAS=y to the defconfigs
where EDAC (or rather EDAC_MM_EDAC) is enabled?

Here's a quick test:

git checkout e3c4ff6d8c94

# remove "default y" from PCIEAER, because that is also selecting
# RAS. But it was removed in 8c8ff55b4da7 ("PCI/AER: Don't select
# CONFIG_PCIEAER by default").
sed -i "/default y/d" drivers/pci/pcie/aer/Kconfig

ARCH=powerpc make corenet32_smp_defconfig
grep CONFIG_EDAC .config # no CONFIG_EDAC, nor CONFIG_EDAC_MPC85XX

git revert e3c4ff6d8c94
grep CONFIG_EDAC .config

You see, before that commit, the driver was actually enabled, and
after that commit it is not.

I'm really not sure what I still have to show you that you agree,
that it's a regression.

>> Still, it's already enabled in that config and it somewhat recently
>> got IMX9 support,
>
> Who got IMX9 support?

Disregard that, I was confused, it's in the fsl_ddr_edac.c (which is
shared between EDAC_LAYERSCAPE and EDAC_MPC85XX).

..

> I can pick up well tested patches tho.

Good to hear.

-michael