Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2369619imm; Mon, 24 Sep 2018 03:14:21 -0700 (PDT) X-Google-Smtp-Source: ACcGV617yut9W6MCaRu5xfDO/w79mqGYTOFkoNsg4wJt4CL2FyrM9C4Qzm/0V51IShSpT1Jzjxmx X-Received: by 2002:a17:902:64c2:: with SMTP id y2-v6mr9381950pli.35.1537784060996; Mon, 24 Sep 2018 03:14:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537784060; cv=none; d=google.com; s=arc-20160816; b=AgS7198KXro+9g6ynZ/V7Ey3e5y3HKXCzrmgajo7liG5oOZKsYTrZ69rgX+7YhO4Mc uANo+VwW5Hb0lC7HcX5+YeBwcAVpcIYGGNuePmDfFG746WXtRXqPsWM21yV+hMigOgKA rXQFhrfHt4LmaLuhDWS1k1isYAAXO1YKakoYlGwxKKoAYgv9V0I+FTueNsVI7fMqUvC2 i39ZqZ2dp6TEYij+mhuKcLzM+DrKwB3T1DXnXZ3PGWmOBKnD4cj4GVmMAYMT4c/OxclC LQ9zjL1OJwp9cf4f1NKuVfdglQOEuPlrDXHwKYQU2l2AM8VoJpcnNiJX2QZTMW1ygnYB 8hwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=uOUEzo9vk8s2/QTfoROwIEFHEF1EYVDuKjqMAO14YIc=; b=QI4lYoCpG4xg3vasGF6xvF3gWv31U1oLpvgmHTWcsu03sPBgPUXSS3MTN4/lUa3srG VUmCN43QCe/flkYNp1aj1tT3JqCQVelg9fRre8KdLuoQFmkcSQKONhd7EdQi2+Bp93EM 8KIbxwTJ/vrNH0k0inp6RaWmzc3ZqOBMIwpIJwfvO2a8pSod+NAJbAeiFbQkB6Ol4L4J g+L9MWWm3dsJ5xVOTeo2tHDZrLNZPaev7jPAYtM4Uvl4wD9N651lBC2SJiAeajZ5+Ie/ JG4UlLidUwyi9Dc8nGM2IsSnOnt4c9hpHoe4ed7dow/4joziBifwNN+9wwVw3oXrHdJ1 8xug== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=GK0TyoJG; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c31-v6si6222325pgl.166.2018.09.24.03.14.05; Mon, 24 Sep 2018 03:14:20 -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; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=GK0TyoJG; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728650AbeIXQN4 (ORCPT + 99 others); Mon, 24 Sep 2018 12:13:56 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:42114 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbeIXQNz (ORCPT ); Mon, 24 Sep 2018 12:13:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uOUEzo9vk8s2/QTfoROwIEFHEF1EYVDuKjqMAO14YIc=; b=GK0TyoJGW+p7Pdi8u+bP/3xci 4FBQFgSsDSFfLUsiYsef0fOj4ZFVcS8mp6jFMnHcpozczyr85s0P0OtcJ/MEEh/9eN6L5pcpOwo6c vv97tL/0Od7QI5r3YHMnCWkVSMcgcsti2Yo43SPXW0ZpmtJ9/TMZ7i5RW1RJamnfnkMJs=; Received: from n2100.armlinux.org.uk ([fd8f:7570:feb6:1:214:fdff:fe10:4f86]:37729) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1g4Nqq-0002dj-Qt; Mon, 24 Sep 2018 11:12:24 +0100 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1g4Nqk-000686-K6; Mon, 24 Sep 2018 11:12:19 +0100 Date: Mon, 24 Sep 2018 11:12:13 +0100 From: Russell King - ARM Linux To: Thomas Petazzoni Cc: Jan =?iso-8859-1?Q?Kundr=E1t?= , 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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180913104241.65db8243@windsurf> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote: > Hello, > > On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote: > > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote: > > > What about something like the below. I tested it, including the error > > > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled > > > after pci_unmap_iospace(). Actually, I would prefer to use > > > pci_remap_iospace() and pci_unmap_iospace() but for now this API > > > doesn't allow overloading the memory type used for the mapping. > > > > Thanks for providing this fix so quickly, Thomas. I can confirm that this > > patch -- tested on top of 54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge > > tag 'pci-v4.19-fixes-1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci"). Disclaimer: I > > have zero familiarity with Linux' PCI code. > > > > Tested-by: Jan Kundrát > > 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. 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. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up