svn commit: r197969 - head/sys/conf

[M. Warner Losh]

In message: <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2 at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> 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