From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from top.free-electrons.com ([176.31.233.9]:45527 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751432AbaACTBJ (ORCPT ); Fri, 3 Jan 2014 14:01:09 -0500 Date: Fri, 3 Jan 2014 20:01:06 +0100 From: Thomas Petazzoni To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, Jason Gunthorpe , Lior Amsalem , linux-pci@vger.kernel.org, "Gregory Cl??ment" , Ezequiel Garcia , Bjorn Helgaas Subject: Re: Issue with the emulated PCI bridge implementation Message-ID: <20140103200106.5a0999a3@skate> In-Reply-To: <201401031322.31433.arnd@arndb.de> References: <20131226160534.36cc4203@skate> <20131226165241.2c50b244@skate> <20140103002656.GA12098@obsidianresearch.com> <201401031322.31433.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-pci-owner@vger.kernel.org List-ID: 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- 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-