From owner-svn-src-all@FreeBSD.ORG Wed Oct 14 22:15:19 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 CEDB61065670; Wed, 14 Oct 2009 22:15:19 +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 796638FC1A; Wed, 14 Oct 2009 22:15:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9EMB37q029445; Wed, 14 Oct 2009 16:11:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Oct 2009 16:11:15 -0600 (MDT) Message-Id: <20091014.161115.-1796258170.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200910141738.43910.jhb@freebsd.org> References: <200910141645.26010.jhb@freebsd.org> <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> <200910141738.43910.jhb@freebsd.org> 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, xcllnt@mac.com, src-committers@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:20 -0000 In message: <200910141738.43910.jhb@freebsd.org> John Baldwin writes: : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: : > : > 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>. : : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a : ROM base. However, orm(4) should be enabled for all ISA bridges assuming : that is fixed. OTOH, the way many bus drivers I've seen handle this so far : is to change the base address of SYS_RES_MEMORY objects as they pass through : the relevant bridge so that the actual memory address is properly adjusted : when it gets to the equivalent of the nexus. This is how many of the : Foo->PCI bridges in arm that I've looked at work, and I think this is more : inline with Warner's original patch which is to allow the various : platform-specific ISA bridge drivers reject memory ranges they do not decode : and provide any needed adjustments to ranges they do decode to transform them : into suitable resources for their parent. Then orm(4) would just see it's : attempts to do bus_alloc_resource() fail and end up DTRT. Given that, I do : think this logic belongs in the ISA bridge drivers rather than in individual : ISA drivers. We don't make ISA peripheral drivers add an 'isa_mem_base' or : equivalent to their I/O resources, and in terms of I/O resources, orm(4) is : just a special blackhole device (much like the ACPI or PnPBIOS system : resource devices, or the ram0 or apic0 devices on x86). This is exactly what I've been trying to say: the memory addresses that orm is using are ISA BUS addresses. These just happen to map 1:1 on x86, but will map to something else on other platforms. But our kernel API is that the driver requests the bus address, and that any necessary translation happen in the bus_space layer. I disagree that it belongs entirely in the isa bridge drivers. They may communicate information to the bus_space implementation, but it is bus_space that ultimately does this translation. Warner