Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Tue, 21 Jun 2005, Alan Cox wrote:

> >  How is the range defined -- is there a way for us to find it?  I'd assume 
> > in the absence of a PCI-ISA or PCI-EISA bridge all I/O port addresses 
> > belong to PCI.  Otherwise the usual rule of "(addr & 0x300) == 0" applies.  
> > Perhaps with the addition of "(addr & ~0xff) != 0" for safety as junk I/O 
> > is often not recorded properly in BARs, sigh...
> 
> No the low addresses belong to the chipset and motherboard. There is

 Well, that doesn't mean they can't be properly reported in a BAR.  

 Besides, does a modern i386 really require them?  DOS compatibility is no 
longer an issue for commodity hardware and the ISA bridge is gone.  
Apparently the only legacy device still not replaced by anything else is 
the RTC, which is rather surprising as there seems to be a lot of 
reasonable alternatives for I2C available these days and i386 boxes have 
had I2C for quite a while now.

> also magic then for video and IDE legacy port ranges. I suspect your

 Both IDE and video are distinct PCI devices these days, so there is no 
need for them to hide their decoded address ranges.  I've thought that has 
been sorted out.

> mips boxen might be a lot cleaner than the PC world.

 They are certainly cleaner, but if a lot, it depends on whether an (E)ISA 
bridge is there somewhere or not.  E.g. some PCI-ISA bridges positively 
decode some memory address ranges unconditionally which results in the 
corresponding range of RAM being unreachable from PCI.  And if there is no 
(E)ISA bridge, there may still be traces of legacy, like P2P bridges with 
an implicit special treatment of certain address ranges that traditionally 
used to be used for ISA.  Or APIC interrupt codes in messages sent over 
HT.

  Maciej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/