Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1245599ybj; Tue, 5 May 2020 16:17:05 -0700 (PDT) X-Google-Smtp-Source: APiQypKAFzSl2+uvdGVNoWfeTei/n236vm8dOCC63L6S3iPTLyCPoFK68MNt7E1ZDT015+ikvpAj X-Received: by 2002:a05:6402:1052:: with SMTP id e18mr4894856edu.63.1588720625418; Tue, 05 May 2020 16:17:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588720625; cv=none; d=google.com; s=arc-20160816; b=DArg2NQNTvXKU5Ja9ANBFpwrq5O5z0K8OGgBwfebO1lvoTj1dlw1cL5kPMEIFQpjcK 26iPdxPo+XqE2Cq/JGM6h/AoeBrYxpE4V+t8pDdM47bYAaz+lGunvb3qfTdvGINVcod2 G0BmmuFwWfywiSD4a+QHeK/AZHzLUntIGQd+9ut7BBcIEui8L4Hr6aRQCfLgEYqRJP3k nhfx8Eo22UUSBZBCT6d290tTUirK4+vdDKP+7IkZSGipNOMJk+kTrP/EOj/yHr10pOGJ js0kst0Oxw/ilG7W8X8RwczBHxAFqU2Cswu4YH9FmbiyhMl1lPWC15JUQeXARtN9heHg 1Oxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=UXnue6WqavufjFAh/swMBfif04zT3JTobLUhS5rdGSk=; b=oQWsPORH6IXXeN6YkEDcJoImy+So8xv32/f4Et0vm61UFmyYylhpoAfzXHjLN1ncVU V+7jdG6jazLAv1X95u6LZy2/nspKON+UpdsmWC5cry6lK8AemY/JIKUvo4eQr8wm6X6p cGb9RGn32TBToOoAcpEIWbxFqQeAta8NXP/jUcJlCiG2REdFtHydrDwxZlaXQctfyxAS ZnH49Z0ISM6m9nYFQfZFMoJmkltWr2TwneU9zxncIh3+522jQqaEBveTwgiprJRSAeQK sEQxGKA82Mv7Nfbijb+5gHNX7VJQJsZP2FLRcdlX1DO6kK8dNAqXgYOF9PxEB6+Xbu3l AmGA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w16si51648edq.89.2020.05.05.16.16.36; Tue, 05 May 2020 16:17:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729222AbgEEXOv (ORCPT + 99 others); Tue, 5 May 2020 19:14:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727089AbgEEXOv (ORCPT ); Tue, 5 May 2020 19:14:51 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D59C2C061A0F for ; Tue, 5 May 2020 16:14:50 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jW6ls-0006ls-MP; Wed, 06 May 2020 01:14:41 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 329981001F5; Wed, 6 May 2020 01:14:40 +0200 (CEST) From: Thomas Gleixner To: Dimitri Sivanich , Christoph Hellwig Cc: x86@kernel.org, Mike Travis , Russ Anderson , Dimitri Sivanich , linux-kernel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: x86/uv cleanups In-Reply-To: <20200505153944.GD2297@hpe.com> References: <20200504171527.2845224-1-hch@lst.de> <20200505153944.GD2297@hpe.com> Date: Wed, 06 May 2020 01:14:40 +0200 Message-ID: <87sggenfdr.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dimitri Sivanich writes: > Yes, we do see a need to clean up old code where it exists, but we would like > to assume this responsibility ourselves in order to ensure functional continuity > with externally available open-sourced modules that our customers rely on. This > code supports current Superdome Flex systems, as well as forthcoming platforms > based on Intel Cooper Lake and Sapphire Rapids processors. Some cleanup is > already being included as part of a forthcoming patchset in support of the > upcoming Sapphire Rapids platform. That's a completely bogus argument. 1) You could have cleaned up that code long ago 2) The rule for code which is unused in the mainline kernel is that it can be removed during spring cleaning unless there is a compelling reason. I can't see one here. 3) Out of tree modules are not supported independent of the license. It's not our problem that you have code out of tree which you could have upstreamed long ago. Look at the history of platform/uv code. All we see from you guys is: - Drops of adding support for new platforms - Occasional fixes when we managed to break UV or you found some bug in your precious code. > Nacked-by: Dimitri Sivanich I'm happy to add that tag when merging this cleanup. Thanks, tglx