From mboxrd@z Thu Jan 1 00:00:00 1970 From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni) Date: Fri, 3 Jan 2014 20:01:06 +0100 Subject: Issue with the emulated PCI bridge implementation In-Reply-To: <201401031322.31433.arnd@arndb.de> References: <20131226160534.36cc4203@skate> <20131226165241.2c50b244@skate> <20140103002656.GA12098@obsidianresearch.com> <201401031322.31433.arnd@arndb.de> Message-ID: <20140103200106.5a0999a3@skate> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Dear Arnd Bergmann, On Fri, 3 Jan 2014 13:22:31 +0100, Arnd Bergmann wrote: > However the part that made me wonder is that an e1000e with a PCI bridge > actually /should/not/ need to allocate an I/O space window with a precious > mbus resource, since AFAIK this adapter does not have an I/O space BARs. > > Thomas, can you send the 'lspci -v' output of the system with this card > to confirm that the I/O space is actually needed? If not, we should probably > review the core PCI code to see why the bridge code tries to add this window. I don't have the hardware next to me, but IIRC the card does have an I/O space. It is not used by the mainline kernel driver, so I have a hacky patch that modifies the e1000e driver to make it use the I/O space and do a few I/O reads and writes. I've used that since the beginning to test I/O space functionality of the pci-mvebu driver. Digging in the LAKML archive, I found a lspci -v output about the e1000e, and it has an I/O space: 03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Intel Corporation PRO/1000 PT Server Adapter Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-