From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934357AbcALObu (ORCPT ); Tue, 12 Jan 2016 09:31:50 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:63325 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762294AbcALObs (ORCPT ); Tue, 12 Jan 2016 09:31:48 -0500 From: Arnd Bergmann To: Sinan Kaya Cc: Lorenzo Pieralisi , Tomasz Nowicki , bhelgaas@google.com, will.deacon@arm.com, catalin.marinas@arm.com, rjw@rjwysocki.net, hanjun.guo@linaro.org, jiang.liu@linux.intel.com, stefano.stabellini@eu.citrix.com, robert.richter@caviumnetworks.com, mw@semihalf.com, liviu.dudau@arm.com, ddaney@caviumnetworks.com, tglx@linutronix.de, wangyijing@huawei.com, suravee.suthikulpanit@amd.com, msalter@redhat.com, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org, jchandra@broadcom.com, jcm@redhat.com Subject: Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Date: Tue, 12 Jan 2016 15:30:25 +0100 Message-ID: <4945809.OlUZI8D7JL@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5693D0AE.4020306@codeaurora.org> References: <1450278993-12664-1-git-send-email-tn@semihalf.com> <20160111153949.GA2366@red-moon> <5693D0AE.4020306@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:o4Jxl2ZCCDXKCeVw8Cs1U88dwLHzyGRQNvoKDtY7v+M7lVQhYuU /fHck/qzMVr1+f4YPjEOMlfjTypXmNenjZyZ5tTvsRYUN+zGmh2OZUrdQ16mco/jzOXKxhA XXh6tHno0Uyi72V33jNACfl6s4tTiisNUhFik5BIfAU7TsfIdVGGeEcdZzWI0SMgPImPSwn AGwyt953P8Si2WFrAM46g== X-UI-Out-Filterresults: notjunk:1;V01:K0:0HosStdZHsY=:uieBUymLhBY1S7+76sXHp/ IQUH7S+j8P8I6VZtIzTlCebc+uLFSMiNXBDHPsfyj00JSKV0pLgyx8Dww4rDI1IBXjm+bzfWS bPQX+39deULDnSM36VvRbmr3/E8rrEMHIZ+7AcTxUk3znqz1gdAePiRDSW5BIxoS6dCRHdaDT PbacStR9QGfF/TPT7uVDfJkvaCkLmiRd5y+uTLpE+KUZ+9GwY8z2HRuYAQ54JzK1+BlsKPsQ/ k2qxoXI9MtyrXklwp7o+jrG7h3R7sh9Ach0TYhOd1Dl2LBKvG03OVAlJ+VcJ0pi/hxwQyFVuX MRcGM6eibx8kpqoEytb4z95QJDv1YzXf4cj0tSOh19DKYTNzHtrTFvWBHf9oy80LeFdyUqx3W 8nwcqXn8wBe7GGnGuAOuUlG//2pfoJidHT+IWA49F1s1jfJx4Fn+TEb5jAycTdzcdqTjAgMy4 VGydCuXBhOG3Spu4mCcPEhW3D06F5wH2zEwWkCcm/FZfuG91wLellc+R6NdGILYXauhUu/pIy 09GZPTPxFqEzUZ7Grdvs+fc3UNKGgJmXbbxjx24HJYY+gm5QAMZz+KE9wtbSICB2zZcjuda8g T03D8OKYJvvadUEx+Zpf4FWbD5QsTugknF1/eQjPCx/Kp2v+X9nOPhuX8yq5+BVrSL/FD/xZn OqjyZJbyp/dcRHdWljfW4gGwf5dEA9x9LF8vzdxXTGFROfCbtQn+UCA5c0FRk4OQzfPtwTsIr P0b8xuou1AVwlst0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 11 January 2016 10:56:30 Sinan Kaya wrote: > > #_dmesg_|_grep_resource > [ 2.945762] pci_bus 0000:00: root bus resource [io 0x0000-0xefff window] (bus address [0x1000-0xffff]) > [ 3.652201] pci_bus 0002:00: root bus resource [io 0xf000-0x1dfff window] (bus address [0x1000-0xffff]) > [ 6.546716] pci_bus 0006:00: root bus resource [io 0x1e000-0x2cfff window] (bus address [0x1000-0xffff]) > / # This is bad. We normally want to stay out of the first 0x1000 bytes of the Linux space, to prevent drivers from poking into the ISA registers. We can have one of the buses be the "primary" bus that has its first 0x1000 bytes of I/O space mapped into the respective Linux addresses, but mapping the second 0x1000 bytes into the reserved space is the worst possible outcome here, as legacy ISA drivers will now poke at random other devices that are intentionally moved to high addresses to stay of of that range. > Since we are talking about what ACPI dictates vs. what kernel does. Here is something that got me > while testing. > > Somebody sneaked in a 0x10003 upper limit on PCI addresses for some reason below. There is nothing magic > about 0x10003 and I'm wonding why we have this limit. I/O ports are at aligned addresses, the highest 4-byte address you can access is 0xfffc with the default 0x10000 port limit per bus. This limit is generally seen as sufficient because that is what x86 has. Most PCI devices have no I/O ports at all, and the ones that have them have only a couple of bytes of address space in it. Arnd