svn commit: r197969 - head/sys/conf

[John Baldwin]

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.  I'm not 
sure if other platforms have a way of knowing this however.  Are you aware of 
something in OFW to communicate this?  ACPI does this for Host-PCI bridges 
via ResourceProvider() resource entries, but I've never seen ACPI do it for a 
PCI-ISA bridge.

-- 
John Baldwin