On Fri, Mar 22, 2019 at 6:55 PM Luck, Tony <tony.l...@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