From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754831AbcALVjZ (ORCPT ); Tue, 12 Jan 2016 16:39:25 -0500 Received: from mout.kundenserver.de ([212.227.126.187]:62030 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753008AbcALVjU (ORCPT ); Tue, 12 Jan 2016 16:39:20 -0500 From: Arnd Bergmann To: Lorenzo Pieralisi Cc: Sinan Kaya , 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 22:37:54 +0100 Message-ID: <4627437.88HpJxySSc@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160112183854.GB5139@red-moon> References: <1450278993-12664-1-git-send-email-tn@semihalf.com> <4945809.OlUZI8D7JL@wuerfel> <20160112183854.GB5139@red-moon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:EkKpE7onLBDgTi59KqIqkZcxdUcXq/Iad4+7ahsLQALvRlb05p9 /v4rVod6DHHlhk5/zZQul2brGJBwjdo/Bb8uwG4WFmFkLVveZIXIU0OoD/O/Bfv7pTWOO4s R5sw1GFf9O2u5imDRGwCkuP9GNyrsSfZfeSE8WgFQ9L/ae9Ddg1jspLivrOR1bjfH/bR16T StOlfIhDczJosqguQkfWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:bwaf4yOCrdI=:NNpGmvMOPUj0Az6IRJdWEP yt5E+GeuQhniGxxz0WX6Xgj7+ANIt00TP7+fjQQmcSwNT6RWOTrvBQp0HaG4zJtp9LGQ0Cvvn +29sUlEkLsSUElnp4nKYBSM4bvYEXZlWtZQuJKw6Y2WzVJCCmsn8sMwRtJrj5InCuW6CbcbMH oaGWNo0c0kCPfvkU7M3IftaWTFIPGS0lK3iw4ITvNlHTS/mmMYCnSSP+5jqL1ADdS3bTsAk7h Sv8HGmYYijIVve8SUkkyb/sliJs4Rny5D4GPPesmVt3Wc6JyDRSfSGD+/4+zz2BUNYtFyLHUn k2lZYPf9QNjdDLKSEiMiPjxoIy3WPOWS/gv4arcwYUOjDTxbZeh0BNFlv5Un1dY4k2Wjo6CB3 GAsijBJyUGUA0SFsLqC7FEdXSkQ9hfTdInNfC1jecSfi5neakH4V85EykBe8ajpC5poXALvoK EZUaeLD7Pzpkecnww4MnIp5UqVgwvie4kgtVjwlFJevv5E5a+WFyhS0wYroblFrOdU/phMbUT zk6hDVYszARRHogkAHAuHz/KuDIin0hw7P5+gQDNIE/tXOIlI8wiuecXbZYDxEeIK1MtSxEdg HgSG4ekSXm+DQsRlDs0TS+C7bIeLHD8RLyQS+3oGdPJe/E1z6m0pMzR8XrMiSPByDVUG4MadL VhV1Kg/w9XhhFHJV+xY+tO77pu1itgOirxAyuKs+x/aR3iBTV7l2AHZkupMRtsv+/Ao7jv9ZB Ku/LZcdT/OtHtG41 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 12 January 2016 18:38:54 Lorenzo Pieralisi wrote: > On Tue, Jan 12, 2016 at 03:30:25PM +0100, Arnd Bergmann wrote: > > 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. > > You are referring to: > > pci_bus 0000:00: root bus resource [io 0x0000-0xefff window] > ^^^^^^ > here, right ? [0x0 - PCIBIOS_MIN_IO] is not assigned by the PCI > code that reassigns resources anyway, so devices with IO BARs won't > get assigned [0x0 - PCIBIOS_MIN_IO] address space (Linux space). > > Are you saying we should disallow the [0x0 - 0x1000] in the PCI busses > IO resource (Linux space) ? > > In pci_address_to_pio() the offset (Linux IO resource) we assign starts > from 0x0, so we always allocate that chunk of IO address space (that is > an offset into the Linux virtual address space), am I correct ? I think we can assign the address zero of the Linux I/O port range, but we should never assign it to a bus port range that does not also start at zero. If we encounter a firmware description that has bus range which excludes the first 1k, we should probably assign it to somewhere after 0x10000 (65536), so we can later assign a primary I/O space to a bus that has an ISA or LPC bridge with actual devices below 0x1000 (4096). > > 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. > > And you are referring to: > > root bus resource [io 0x0000-0xefff window] (bus address [0x1000-0xffff]) > ^^^^^^ ^^^^^^ > > here ? If ISA drivers poke at addresses in the [0x0 - 0x1000] > range (Linux space IO offset) they end up on the PCI bus with addresses > above 0x1000, is that what you are saying when you refer to "moved to > high addresses to stay out of that range" ? Correct. Arnd