From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: EDAC, {skx|i10nm}_edac: Fix randconfig build error From: Borislav Petkov Message-Id: <20190314110413.GA32277@zn.tnic> Date: Thu, 14 Mar 2019 12:04:13 +0100 To: Arnd Bergmann , "Luck, Tony" Cc: Mauro Carvalho Chehab , James Morse , Qiuxu Zhuo , linux-edac@vger.kernel.org, Linux Kernel Mailing List List-ID: T24gVGh1LCBNYXIgMTQsIDIwMTkgYXQgMDg6MDk6MDZBTSArMDEwMCwgQXJuZCBCZXJnbWFubiB3 cm90ZToKPiA+IFNvIHdoZXJlIHNob3VsZCB3ZSBnby4gUHJvcG9zZWQgc29sdXRpb25zIGFyZSBw aWxpbmcgdXA6Cj4gPgo+ID4gMSkgTWFrZSBza3hfY29tbW9uIGEgbW9kdWxlCj4gPiAgICAgICAg IFtkb3duc2lkZTogaGF2ZSB0byBFWFBPUlQgZXZlcnl0aGluZyBpbiBpdF0KPiA+IDIpIE1vdmUg bW9kdWxlLWlzaCBiaXRzIG91dCBvZiBza3hfY29tbW9uCj4gPiAgICAgICAgIFtkb3duc2lkZTog cGVyaGFwcyBmcmFnaWxlXQo+ID4gMykgI2luY2x1ZGUgc2t4X2NvbW1vbi5jIGludG8ge3NreCxp MTBubX1fZWRhYy5jCj4gPiAgICAgICAgIFtkb3duc2lkZTogbm8gcGF0Y2ggeWV0LCBiaWdnZXIg Y29kZSBzaXplXQo+IAo+IFNvcnJ5IHRvIGFkZCBvbiB0byB0aGUgYWxyZWFkeSBsb25nIGxpc3Qs IGJ1dCBvbmUgbW9yZSBpZGVhIGFmdGVyCj4gbG9va2luZyBhdCB0aGUgdHdvIGZpbGVzOgo+IAo+ IDQpIEhhdmUgYSBzaW5nbGUgZHJpdmVyIG1vZHVsZSwgd2l0aCB0aGUgc2t4X2NvbW1vbi5jIGNv bnRhaW5pbmcKPiAgICAgdGhlIHRvcC1sZXZlbCBtb2R1bGVfaW5pdC9tb2R1bGVfZXhpdCBmdW5j dGlvbnMgdGhhdCBjYWxsIGludG8gdGhlCj4gICAgIGhhcmR3YXJlIHNwZWNpZmljIHZlcnNpb25z Lgo+IAo+IFRoaXMgaXMgdGhlIG9wcG9zaXRlIG9mIHRoZSB1c3VhbCByZWNvbW1lbmRhdGlvbiAo dGhlIGRyaXZlcgo+IGlzIGFscmVhZHkgc3RydWN0dXJlZCBuaWNlbHkgb3RoZXJ3aXNlKSwgYnV0 IGl0IHdvdWxkIGJlIGNoZWFwCj4gd2F5IG91dCBoZXJlLgoKVGhpcyBpcyB3aGF0IEkgdGhpbmsg cmlnaHQgbm93OiBpZiB0aGlzIGlzIGdvaW5nIHRvIGJlY29tZSBzdWNoIGEgcGFpbiwKdGhlbiB3 ZSBiZXR0ZXIga2VlcCB0aG9zZSB0d28gZHJpdmVycyBjb21wbGV0ZWx5IHNlcGFyYXRlLiBXaG8g Y2FyZXMgaWYKdGhlcmUncyBzb21lIGNvZGUgZHVwbGljYXRpb24/ISBCZXR0ZXIgdGhhdCB0aGFu IHNvbWUgb2JzY3VyZSByYW5kY29uZmlnCmJ1aWxkIGJyZWFrYWdlcyBhbmQgZml4ZXMgaW50cm9k dWNpbmcgbW9yZSB1Z2xpbmVzcy4gSU9XLCB3ZSBzaG91bGQga2VlcAppdCBzaW1wbGUuCgpVbmxl c3MsIFRvbnksIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gbWFrZSBjaGFuZ2VzIHRvIHRoZSBjb21t b24gY29kZSBpbgpvbmUgcGxhY2UgYW5kIGRvbid0IHdhbnQgdG8gcGF0Y2ggYm90aC4gVGhlbiBJ J2QgbGlicmFyaXplIHRoZSBjb21tb24KZnVuY3Rpb25hbGl0eSwgaS5lLiwgZG8gc29tZXRoaW5n IGFsb25nIHRoZSBsaW5lcyBvZiAyKS4KCkJ1dCBoYXZpbmcgdHdvIGNvbXBsZXRlbHkgc2VwYXJh dGUgZHJpdmVycyBpcyB0aGUgbW9zdCByb2J1c3QgdmFyaWFudCwKSU1PLgo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30E29C43381 for ; Thu, 14 Mar 2019 11:04:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F35F62063F for ; Thu, 14 Mar 2019 11:04:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="cCE0Y8Ek" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727493AbfCNLEN (ORCPT ); Thu, 14 Mar 2019 07:04:13 -0400 Received: from mail.skyhub.de ([5.9.137.197]:60838 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727394AbfCNLEN (ORCPT ); Thu, 14 Mar 2019 07:04:13 -0400 Received: from zn.tnic (p200300EC2F09800070FBD7F886F95E91.dip0.t-ipconnect.de [IPv6:2003:ec:2f09:8000:70fb:d7f8:86f9:5e91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 391BE1EC0104; Thu, 14 Mar 2019 12:04:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1552561451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=NJQS2sFIjRwOjYwg80igZbvEwiXBxafGLNLtHjj4LXA=; b=cCE0Y8Ek/T7CC9mwqcg1kOz0MRNulKLUR2j1cAXlHepelLpB5YDLcz46UjDVvfoXUztvZu 1Kk/gnAcnurVLjdk1cODyTRhY44qvpH6lHH/4YYKwzY8TUyFHOA2sPEr5iPmVlM6gT4U2p Ga/IunvX8Pa8xx1WlNPaGwFRmNaXRwA= Date: Thu, 14 Mar 2019 12:04:13 +0100 From: Borislav Petkov To: Arnd Bergmann , "Luck, Tony" Cc: Mauro Carvalho Chehab , James Morse , Qiuxu Zhuo , linux-edac@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH] EDAC, {skx|i10nm}_edac: Fix randconfig build error Message-ID: <20190314110413.GA32277@zn.tnic> References: <20190305132147.3739133-1-arnd@arndb.de> <20190305143453.GC8256@zn.tnic> <20190306175808.GA30016@agluck-desk> <20190313230137.GA12529@agluck-desk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 14, 2019 at 08:09:06AM +0100, Arnd Bergmann wrote: > > So where should we go. Proposed solutions are piling up: > > > > 1) Make skx_common a module > > [downside: have to EXPORT everything in it] > > 2) Move module-ish bits out of skx_common > > [downside: perhaps fragile] > > 3) #include skx_common.c into {skx,i10nm}_edac.c > > [downside: no patch yet, bigger code size] > > Sorry to add on to the already long list, but one more idea after > looking at the two files: > > 4) Have a single driver module, with the skx_common.c containing > the top-level module_init/module_exit functions that call into the > hardware specific versions. > > This is the opposite of the usual recommendation (the driver > is already structured nicely otherwise), but it would be cheap > way out here. This is what I think right now: if this is going to become such a pain, then we better keep those two drivers completely separate. Who cares if there's some code duplication?! Better that than some obscure randconfig build breakages and fixes introducing more ugliness. IOW, we should keep it simple. Unless, Tony, you want to be able to make changes to the common code in one place and don't want to patch both. Then I'd librarize the common functionality, i.e., do something along the lines of 2). But having two completely separate drivers is the most robust variant, IMO. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.