From owner-svn-src-all@FreeBSD.ORG Wed Oct 14 22:15:18 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31FEB106566C; Wed, 14 Oct 2009 22:15:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BF7958FC19; Wed, 14 Oct 2009 22:15:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9EM6nS7029380; Wed, 14 Oct 2009 16:06:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Oct 2009 16:07:01 -0600 (MDT) Message-Id: <20091014.160701.-736097942.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> References: <2D55EFED-675A-4CC7-AF39-DE83961552F0@mac.com> <200910141645.26010.jhb@freebsd.org> <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, jhb@freebsd.org Subject: Re: svn commit: r197969 - head/sys/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 22:15:18 -0000 In message: <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> Marcel Moolenaar writes: : : On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: : : > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: : >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: : >>> : >>> I can't be more clear than this. You keep ignoring me, and it is : >>> very : >>> frustrating. : >> : >> I'm not ignoring you. I'm still talking. You simply haven't convinced : >> me. While it's possible (likely?) that I don't understand the issues, : >> all you've achieved so far is that I'm more convinced that limiting : >> orm(4) to i386 and amd64 is the right thing, because the alternative : >> is not at all appealing. : >> : >>> The problem is that the : >>> powerpc and itanium isa modules allow memory ranges that shouldn't : >>> be : >>> allowed. That's the platform specific code that needs to be fixed. : >> : >> isa_set_resource() is MI code and it happily adds whatever resources : >> a driver wants. The only chance MD code has is to fail the : >> allocation, : >> but since the whole ISA code bypasses the newbus hierarchy, there's : >> no way we know in the isa MD code what is valid and what isn't unless : >> we add kluges to platform code. : >> : >> If you want to fix it for real, does that mean fix it for real or : >> does that mean add kluges to platform code? : >> : >> Shouldn't we have ISA bridges obtain the set of valid resources : >> from their parent in the newbus hierarchy? : > : > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't : > have any : > I/O limit registers like PCI-PCI bridges, instead they are : > subtractively : > decoded, i.e. they "eat" any memory request that no one else claims. : : The key here being requests that reach the PCI-ISA bridge. It's entirely : platform specific which I/O memory addresses generated by the CPU gets : decoded and forwarded in such a way that it's visible to the PCI-ISA : bridge. This is what needs to be obtained from the parent in the newbus : hierarchy. Rather than hardcoding [0xC0000 .. 0x100000> as the ISA : option : ROM memory range, it should be something like [isa_mem_base+0xC0000 .. : isa_mem_base + 0x100000> or even [isa_rom_base .. isa_rom_base + : 0x40000>. 0xc0000..0x100000 is the right range of addresses to use. It is the responsibility of the bus space to translate that to whatever physical address to use. These are bus addresses, and are by definition platform independent. If other platforms map these bus addresses to other physical addresses, then it is their responsibility to map them in the bus_space layer. I think that's the primary disconnect here. The powerpc bus_space doesn't do this at all, but should for those platforms that actually implement it. Warner