Arjan van de Ven wrote:I don't understand. If we're going to differentiate MMCONFIG from some other access mechanism, it only needs to be done at the Northbridge level. Devices are electrically ignorant of the protocol used between CPU and Northbridge to get the Northbridge to assert config cycles on the bus. Agreed. So we have Loic and Ivan's patch limiting MMCONFIG accesses to offsets >= 256. And we have Matthew's patch that abstracts the method for config accesses to offsets < 256. I beleive Matthew has already tested these patches for functionality on x86. All that's needed is to test for regressions on other arches. Is there any interest in providing the following? 1. The ability to use MMCONFIG for all accesses on systems that have no problems with MMCONFIG. 2. For systems using both PCI and PCI express, testing each bus for MMCONFIG compliance, to determine whether MMCONFIG can be used for all config accesses or whether the bus must be limited all to the method abstracted for offsets < 256. Or does that introduce unnecessary complications? --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Arjan van de Ven | [Announce] Development release 0.1 of the LatencyTOP tool |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 020/196] IDE: Convert from class_device to device for ide-tape |
git: | |
| Tantilov, Emil S | RE: [PATCH] net: sk_alloc() should not blindly overwrite memory |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
