From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755524AbcCXDPM (ORCPT ); Wed, 23 Mar 2016 23:15:12 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:40919 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295AbcCXDPK (ORCPT ); Wed, 23 Mar 2016 23:15:10 -0400 Subject: Re: Question about PCI I/O space in ARM64 To: Arnd Bergmann , Catalin Marinas References: <56F209A9.4040304@huawei.com> <20160323101840.GA21390@e104818-lin.cambridge.arm.com> <8793380.nuVa09lFue@wuerfel> CC: , linux-arm-kernel , , "Gabriele Paoloni" , Linuxarm , , Zhou Wang From: Kefeng Wang Message-ID: <56F35BAA.50800@huawei.com> Date: Thu, 24 Mar 2016 11:14:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <8793380.nuVa09lFue@wuerfel> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.19.180] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56F35BB5.00D7,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ee4692533e316d54e1e0075d3308834e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/3/23 20:26, Arnd Bergmann wrote: > On Wednesday 23 March 2016 10:18:40 Catalin Marinas wrote: >> On Wed, Mar 23, 2016 at 11:12:41AM +0800, Kefeng Wang wrote: >>> If no pci, the PCI I/O space(16M) is mapped into an irrelevant mem space(right ?), >> >> No. It is not mapped at all. >> >>> not a right IO space, >>> that is, no one call pci_remap_iospace() to remap the memory mapped I/O space, once driver >>> like f71805f loaded, write value to IO space(see f71805f_init->f71805f_find->superio_enter->outb), >>> we met following oops, >>> ------------------------ >>> Unable to handle kernel paging request at virtual address ffffffbffee0002e >>> pgd = ffffffc1d68d4000 >>> [ffffffbffee0002e] *pgd=0000000000000000, *pud=0000000000000000 >>> Internal error: Oops: 94000046 [#1] PREEMPT SMP >>> Modules linked in: f71805f(+) hwmon >>> CPU: 3 PID: 1659 Comm: insmod Not tainted 4.5.0+ #88 >>> Hardware name: linux,dummy-virt (DT) >>> task: ffffffc1f6665400 ti: ffffffc1d6418000 task.ti: ffffffc1d6418000 >>> PC is at f71805f_find+0x6c/0x358 [f71805f] >>> ------------------------ >> >> That's caused by not having a mapped PCI I/O space. Clear. >> >>> I am not clear about PCI I/O, but if this is indeed a bug, how to solve this issue, >>> any advice will be appreciated. >> >> You need a PCI host controller driver (e.g. >> drivers/pci/host/pci-host-generic.c) and corresponding bindings in DT or >> ACPI. In our inner test, there are some board without pcie host driver(even without pci host controller). > > I think getting an Oops is not the best behavior though, it would be > nice if that could be improved in some way. > > Ideally, each driver that accesses PCI I/O space would call request_region() > before doing so, and it would be good if that call could be made to > return an error when asked about an address that has not been mapped. > > I see that ioport_resource gets initialized to the {0, IO_SPACE_LIMIT} > range. If we could change it so that pci_remap_iospace() hooks up > to ioport_resource and extends it whenever something gets mapped > there up to IO_SPACE_LIMIT, we can change the default range to > {0,0}, which would fail for any request_region call before the > first pci_remap_iospace. > > This won't help for the specific f71805f driver example, because that > does not call request_region(), but we can treat that as a driver bug > and fix it. Yes, we met same error with several modules(at least 8+), so it's better to find a good way to avoid it, change modules one by one maybe not a good choice. Define some arch in/out func instead of generic ops? when in/out vals, check whether or not the pci_iobase is mapped. Thanks catalin and arnd for your reply. > > Arnd > > . >