Patchwork EDAC, {skx|i10nm}_edac: Fix randconfig build error

login
register
mail settings
Submitter Arnd Bergmann
Date March 15, 2019, 9:03 p.m.
Message ID <CAK8P3a2CFyF5wExbZPb20E56sJ=3DpsP+0m2Px6D5Sw_L3pKXA@mail.gmail.com>
Download mbox | patch
Permalink /patch/749987/
State New
Headers show

Comments

Arnd Bergmann - March 15, 2019, 9:03 p.m.
On Fri, Mar 15, 2019 at 7:11 PM Luck, Tony <tony.luck@intel.com> wrote:
>
> On Fri, Mar 15, 2019 at 07:02:06PM +0100, Borislav Petkov wrote:
> > On Fri, Mar 15, 2019 at 10:49:56AM -0700, Luck, Tony wrote:
> > > Yes - Qiuxu did that already ... patch reposted below.
> >
> > ... to which Arnd said that it were fragile because it might break if it
> > includes a THIS_MODULE reference. So I'd say we won't do that then. And
> > keep it strictly a library.
> >
> > Right?
>
> What is your definition of "library"?
>
> fsl_ddr_edac.c seems to have the same potential for breakage
> if someone makes a change to that, then it will hit the same
> problem.

I think they are a bit safer because CONFIG_EDAC_LAYERSCAPE and
CONFIG_EDAC_MPC85XX are mutually exclusive (one is only
on powerpc, the other is only on ARM). It would break though if
one were to make them build with CONFIG_COMPILE_TEST,
or if another driver gets added that for ARM.

I just thought about a possible Kconfig solution some more, and
had this idea:

 obj-$(CONFIG_EDAC_CELL)                        += cell_edac.o

Basically I cheat Kconfig, so if one driver is built-in and
the other is a loadable module, we compile both as built-in.


        Arnd
Luck, Tony - March 15, 2019, 9:28 p.m.
> Basically I cheat Kconfig, so if one driver is built-in and

> the other is a loadable module, we compile both as built-in.


My mail client may have munged that path. Both "git am" and "patch -p1"
barf when I try to apply it.  Since it was small I tried to replicate manually,
but I must have messed up something because Kconfig still seems content
to let me have CONFIG_EDAC_SKX=y with CONFIG_EDAC_I10NM=m

:-(

-Tony
Arnd Bergmann - March 22, 2019, 2 p.m.
On Fri, Mar 15, 2019 at 10:28 PM Luck, Tony <tony.luck@intel.com> wrote:
>
> > Basically I cheat Kconfig, so if one driver is built-in and
> > the other is a loadable module, we compile both as built-in.
>
> My mail client may have munged that path. Both "git am" and "patch -p1"
> barf when I try to apply it.  Since it was small I tried to replicate manually,
> but I must have messed up something because Kconfig still seems content
> to let me have CONFIG_EDAC_SKX=y with CONFIG_EDAC_I10NM=m
>
> :-(

Sorry, this was my mistake, my email was garbled. The patch was
correct though: the idea here is not to change the Kconfig symbols
but to change the Makefile to do the right thing even when Kconfig
is set wrong.

      Arnd
Luck, Tony - March 22, 2019, 5:55 p.m.
On Fri, Mar 22, 2019 at 03:00:25PM +0100, Arnd Bergmann wrote:
> Sorry, this was my mistake, my email was garbled. The patch was
> correct though: the idea here is not to change the Kconfig symbols
> but to change the Makefile to do the right thing even when Kconfig
> is set wrong.

Well this does seem like a "clever" way out of the randconfig
problem.  New patch applies and when I set .config to have:

CONFIG_EDAC_DEBUG=y
CONFIG_EDAC_SKX=y
CONFIG_EDAC_I10NM=m
CONFIG_EDAC_SKX_COMMON=y

I don't see any build errors.

There are lots of "skx_" symbols in System.map

But I'm not at all sure what happened to the I10NM driver.

I don't see it mentioned in the output from "make".

It didn't get built as a module (no ".ko" file for it).

It doesn't seem to be built in (no ".o" in drivers/edac/built-in.a)

So I added a #error line to the start of i10nm_edac.c and
ran "make" again.  Nothing.

So, I don't think this is doing what you think it should
do.  Even if it did, it would seem very confusing to a user
that asked for "one module, one built-in" in Kconfig, but
found both built-in.

Boris: I'm voting for Qiuxu's most recent solution (moving
all the EDAC_DEBUG bits out of skx_common.c).

-Tony
Arnd Bergmann - March 22, 2019, 7:56 p.m.
On Fri, Mar 22, 2019 at 6:55 PM Luck, Tony <tony.luck@intel.com> wrote:
>
> On Fri, Mar 22, 2019 at 03:00:25PM +0100, Arnd Bergmann wrote:
> > Sorry, this was my mistake, my email was garbled. The patch was
> > correct though: the idea here is not to change the Kconfig symbols
> > but to change the Makefile to do the right thing even when Kconfig
> > is set wrong.
>
> Well this does seem like a "clever" way out of the randconfig
> problem.  New patch applies and when I set .config to have:
>
> CONFIG_EDAC_DEBUG=y
> CONFIG_EDAC_SKX=y
> CONFIG_EDAC_I10NM=m
> CONFIG_EDAC_SKX_COMMON=y
>
> I don't see any build errors.
>
> There are lots of "skx_" symbols in System.map
>
> But I'm not at all sure what happened to the I10NM driver.
>
> I don't see it mentioned in the output from "make".
>
> It didn't get built as a module (no ".ko" file for it).
>
> It doesn't seem to be built in (no ".o" in drivers/edac/built-in.a)
>
> So I added a #error line to the start of i10nm_edac.c and
> ran "make" again.  Nothing.

Oops, I guess my testing method was also insufficient,
I only checked that the bug was gone, not that it actually
worked.

> So, I don't think this is doing what you think it should
> do.  Even if it did, it would seem very confusing to a user
> that asked for "one module, one built-in" in Kconfig, but
> found both built-in.
>
> Boris: I'm voting for Qiuxu's most recent solution (moving
> all the EDAC_DEBUG bits out of skx_common.c).

Yes, that's probably best then. My patch was likely close to
another correct solution, but I've screwed it up twice now ;-)

     Arnd

Patch

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 47eb4d13ed5f..70080926329f 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -235,6 +235,7 @@  config EDAC_SKX
        depends on ACPI_NFIT || !ACPI_NFIT # if ACPI_NFIT=m, EDAC_SKX can't be y
        select DMI
        select ACPI_ADXL
+       select EDAC_SKX_COMMON
        help
          Support for error detection and correction the Intel
          Skylake server Integrated Memory Controllers. If your
@@ -247,12 +248,20 @@  config EDAC_I10NM
        depends on ACPI_NFIT || !ACPI_NFIT # if ACPI_NFIT=m,
EDAC_I10NM can't be y
        select DMI
        select ACPI_ADXL
+       select EDAC_SKX_COMMON
        help
          Support for error detection and correction the Intel
          10nm server Integrated Memory Controllers. If your
          system has non-volatile DIMMs you should also manually
          select CONFIG_ACPI_NFIT.

+config EDAC_SKX_COMMON
+       tristate
+       help
+         This is an internal helper symbol to ensure that all variants
+         of the EDAC_SKX driver are either built-in or modular, as mixing
+         the two causes link time problems.
+
 config EDAC_PND2
        tristate "Intel Pondicherry2"
        depends on PCI && X86_64 && X86_MCE_INTEL
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 89ad4a84a0f6..01134051f5bf 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -58,10 +58,14 @@  layerscape_edac_mod-y                       :=
fsl_ddr_edac.o layerscape_edac.o
 obj-$(CONFIG_EDAC_LAYERSCAPE)          += layerscape_edac_mod.o

 skx_edac-y                             := skx_common.o skx_base.o
-obj-$(CONFIG_EDAC_SKX)                 += skx_edac.o
+ifdef CONFIG_EDAC_SKX
+obj-$(CONFIG_EDAC_SKX_COMMON)          += skx_edac.o
+endif

 i10nm_edac-y                           := skx_common.o i10nm_base.o
+ifdef CONFIG_EDAC_I10NM
 obj-$(CONFIG_EDAC_SKX_COMMON)           += i10nm_edac.o
+endif

 obj-$(CONFIG_EDAC_MV64X60)             += mv64x60_edac.o