Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932074AbaD3HAv (ORCPT ); Wed, 30 Apr 2014 03:00:51 -0400 Received: from mail-ee0-f43.google.com ([74.125.83.43]:45714 "EHLO mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751713AbaD3HAs (ORCPT ); Wed, 30 Apr 2014 03:00:48 -0400 Date: Wed, 30 Apr 2014 09:00:42 +0200 From: Robert Richter To: Myron Stowe Cc: Borislav Petkov , Suravee Suthikulanit , Borislav Petkov , Andreas Herrmann , Bjorn Helgaas , Myron Stowe , Aravind Gopalakrishnan , linux-pci , kim.naru@amd.com, Daniel J Blueman , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86 , Steffen Persvold , "linux-acpi@vger.kernel.org" , LKML , Jan Beulich , Yinghai Lu Subject: Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities Message-ID: <20140430070042.GN32718@rric.localhost> References: <20140420075936.GA19672@pd.tnic> <20140426091031.GA10166@pd.tnic> <20140428214036.GA32143@pd.tnic> <20140429073309.GE10997@alberich> <20140429102013.GA4726@pd.tnic> <535FC269.2000808@amd.com> <20140429191454.GB4726@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.04.14 15:40:28, Myron Stowe wrote: > On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote: > > So sounds to me like we want to get rid of the whole IO ECS deal > > altogether then. > > > > Now, I'm wondering whether we should kill it completely since I don't > > think anyone cares about numa node info being correct on K8, or? I'm > > specifically turning to our numascale friends who love to have a lot of > > nodes. :-) Maybe I did get you wrong, but IO ECS was introduced with fam10h and is not related to k8. > I think we need to be careful here as there are two unrelated topics > being discussed together. What started this whole thread was the need > for sysfs related numa_node information with respect to PCI devices > (1). Without patch 1, platforms with newer AMD CPUs end up having > '-1' numa_node values for all PCI devices. > > IO ECS has no bearing on patch 1, it only comes into play with patch 2 > which is concerned with MMIO resource information when MCFG doesn't > exist. For the particular issue I'm trying to get resolved, patch 2 > is not needed. However, since we have expended time and effort on > this subject, perhaps we should get this cleaned up while it has our > attention. > > I'm all for deleting as much of amd_bus.c as possible due to its > "perennial maintenance headache". The obvious choices seem to be all, > or some combination, of: > o removing IO ECS logic, > o removing IO/MMIO logic (assuming MCFG issues were long enough ago > to no longer be a concern), > o start deprecating amd_bus.c by adding logic to skip if BIOS >= 2015 I don't see any reason for big changes actually. Just bind the IO ECS logic to fam10h (either with fam check or pci device depending on the implementation, xen's flavor would be pci). This is something stricter than 'if BIOS >= 2015'. It leaves code as it is which is maintainable. You implement the new logic for for newer families. No need for one implementation that fits all. -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/