Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2381926imm; Mon, 24 Sep 2018 03:29:30 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaDIqxP8bpkdHurV+ypcqc1B5mbUGvRnHhXTX819W8HUx3XC6pEA1uRemFDuN+Sll1JbjNN X-Received: by 2002:a62:9b46:: with SMTP id r67-v6mr9684071pfd.105.1537784970364; Mon, 24 Sep 2018 03:29:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537784970; cv=none; d=google.com; s=arc-20160816; b=XR80+XKQ97TbKcb5vJICx/p3ujcqvYCHq6ir6p1rMoX+GmiNJdnNBL8QTd2SWiD5H1 ZLMuanowqj7FP4ho1zbxiQHOYwgkOpxux1p8P/o6WWf+18Or32UbYmriLSycQWFKzTOf dcbhtq3nbZMdMDJK7RGYDSuqpCK3i7O7dREAgz0dru6q2pwttTK5sZWs6tDOrktWa9W8 BWXHdBoBsdFh6ZyZ+2e7LxBWtLKeFD0YBUhPvzKGoZqoR+TaGtOOaDNPnuFjjV9ggi6z OXsSvAxDHFD4iGgk4/t/trWlutPqBcuWngmkHYP2qM0mKQvNvWLXjlhtVnRrkN1zscNW tgGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=4a31kKTy+7QfjgsN4IrkWOP39BdwEBkzfZz7mu60zWA=; b=ifjeEg1XKWYyX4iDZTG6mDrIB/2pQel026ZeDRxgmwdpgntYSOvqGQkNaP621Lf3kN LRIfc+deqnGLYvd++nADp+RvXZs4IsyLjnDlAtX/b1Fl9OGziP4HycSI/aKo3PB3WoeZ MlTtfA6HU0N9vq2MemsP+oYZLLE6AkJj8gfy/OZO9EQZUeANbDl8ZtG+yLt+BQQDGXeT hzaqzFfeO/2KTKTeNwxx3y36cbU0f+WFT7yxyRPwMrvuo3ndUQgwUZX6pvzNJfXoAXiW WOySaFudtAtql24BdwniHmIm9ymAE53pq4Z/r6pkWBAt0+c2ZCq9OS5Pn0j5d0V/myz+ a0Ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y4-v6si33434361pgh.225.2018.09.24.03.29.14; Mon, 24 Sep 2018 03:29:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728208AbeIXQ1v (ORCPT + 99 others); Mon, 24 Sep 2018 12:27:51 -0400 Received: from mail.bootlin.com ([62.4.15.54]:59669 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726074AbeIXQ1v (ORCPT ); Mon, 24 Sep 2018 12:27:51 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 345F0208B1; Mon, 24 Sep 2018 12:26:26 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from windsurf (AAubervilliers-681-1-42-80.w90-88.abo.wanadoo.fr [90.88.160.80]) by mail.bootlin.com (Postfix) with ESMTPSA id 1FD97208C7; Mon, 24 Sep 2018 12:26:14 +0200 (CEST) Date: Mon, 24 Sep 2018 12:26:14 +0200 From: Thomas Petazzoni To: Russell King - ARM Linux Cc: Jan =?UTF-8?B?S3VuZHLDoXQ=?= , Baruch Siach , Lorenzo Pieralisi , Jason Cooper , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Helgaas , linux-arm-kernel@lists.infradead.org Subject: Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" Message-ID: <20180924122614.70738b5c@windsurf> In-Reply-To: <20180924101213.GO30658@n2100.armlinux.org.uk> References: <61fdfd69-2bb6-478c-b0d5-69d8744adae3@cesnet.cz> <87zhwm4kl6.fsf@tkos.co.il> <20180912231050.GX30658@n2100.armlinux.org.uk> <20180913094515.351967bb@windsurf> <5ad46fec-a71a-477a-b23f-d20aacfb481d@cesnet.cz> <20180913104241.65db8243@windsurf> <20180924101213.GO30658@n2100.armlinux.org.uk> Organization: Bootlin (formerly Free Electrons) X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote: > > Thanks for the testing. I'll wait for Russell to say if he is happy > > (or not) with the addition of pci_unmap_io() in the ARM code, if that's > > the case, I'll send a proper patch to fix the issue. > > I'd prefer not to provide an unmapping API, because it gives the > impression that it's okay to unmap the IO space mapping, and we'll > end up with drivers that decide to call it in their cleanup path. > IO space isn't expected to ever go away - eg, on a PC, it's always > present. But being able to unmap it would also be needed to be able to remove PCI host controller drivers, and therefore compile them as module, and make them more like any other drivers. I'm not sure why we need to guarantee that the I/O space is always mapped: - It isn't mapped before the PCI controller driver does the mapping. - There is no reason for it to be accessed when the PCI controller driver is not initialized: PCI devices can only be probed and initialized when the PCI controller driver is probed/initialized. Also, in general, pci_ioremap_io() is ARM specific, and is now only used by very few drivers: - Dove (Marvell platform) - IOP13xx - MV78xx0 (Marvell platform, should be moved to use pci-mvebu) - Orion5x (Marvell platform, should be moved to use pci-mvebu) - pci-mvebu - at91_cf All other drivers, including on ARM, use pci_remap_iospace(), which does provide the pci_unmap_iospace() counter part. The only reason I have not changed pci-mvebu to use pci_{remap,unmap}_iospace() is because it doesn't allow to change the memory attributes. But to me, the general direction is that the ARM-specific pci_remap_io() API is fading away, and its replacement already provides an unmapping capability. So why not add the same unmapping capability to pci_remap_io() ? > I've been toying with the idea of making pci_map_io() ignore > subsequent attempts to overwrite the mapping with an identical > mapping, and WARN() if there is an attempt to overwrite an existing > mapping with other physical address, but I'm not entirely happy > with that either (which is why I haven't responded sooner.) > > At the moment, I don't have a way forward that I'm happy with for > this. But we have a regression and we need to fix it. Do you suggest to not use the new pci_host_probe() API ? Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com