From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 612C7C32792 for ; Mon, 30 Sep 2019 16:57:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 336DA20815 for ; Mon, 30 Sep 2019 16:57:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lDMXPyHH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729590AbfI3Q5D (ORCPT ); Mon, 30 Sep 2019 12:57:03 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:35931 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727702AbfI3Q5D (ORCPT ); Mon, 30 Sep 2019 12:57:03 -0400 Received: by mail-ot1-f66.google.com with SMTP id 67so8965537oto.3 for ; Mon, 30 Sep 2019 09:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZJu5nMPyA3CcXPtrWusDX9FpZgNc7KiBqwKc0pCnNk=; b=lDMXPyHH0b4q5PAmhy6A3YLJAkPCddp6btlDUZ0fPsYCu5yMeJTt74gZ5ZUXWWwe/w QnXSoca9X+Ns+PkoKCftGvH+eaa8NqLQr1kdj58zJ2hiotXy2CBBNxVuUeD0NYk76Beu YBIyyDFD6dc6upQ597O4TV60qpD4y3gXNE7Jery+lSUTFIndraj1O/EcZ1NBkAY+sVH2 v9Ff9yFBknkTGA7ZEnjAI/tM6OntsNWbkiRuV6dtG3p13i1YVPGbTfhVgwtVRieZkRmM IFBRMzd0DiKPR74GE5cGaMLRvXbhOal7CevhadIXbfMyF4jjMUB76fGc/0EZmpPBcItS cFSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZJu5nMPyA3CcXPtrWusDX9FpZgNc7KiBqwKc0pCnNk=; b=W+UWjcxmHyZPT5c032Lq/rUk3Ymk31lsHJ9pvj6W4bI0hZ8/mKdMe2SzClj7fwPjPo CiuqxcJMBwHfJE3OhO9jJcQTJxSzPSwMj37bgj2tM54eszVPDKxwvMrOKoybO0GDsvO7 sgAwnDxT1RjGMN+5VjG/5w9tHlrhizUvD6bgjLmCb7aMCu8exZsrXUr63/WwOlM7YroK S7N/VJ6761uN8z2uZHcZVFhUrtr0bg/AolrPc+Cs1ePHZYSQltfAdRdwiel4xizbjrob H2BLsqxzzPRc4xNzcNgv3JRixUY12edjpkM9fTUcNWGnzmsagCXP/18h4frwMc9dBb2N 1hTA== X-Gm-Message-State: APjAAAXcREiynsq+WEppHDUkkpr0PeAqlKGJTYT95kNN9LgudxXjlBu9 sOo9tD7cfDCppcPQmmN+7ddinaG7yNQ+HOUkdhMiWQ== X-Google-Smtp-Source: APXvYqzB8H/7R2/+lg1XepUdOoHj928L8GWJV0m55A4x/X1lbYqO0HreOXXiM5k44rOocAfzJA5NKe2lpHDKrO0K8gI= X-Received: by 2002:a9d:562:: with SMTP id 89mr1391432otw.232.1569862622367; Mon, 30 Sep 2019 09:57:02 -0700 (PDT) MIME-Version: 1.0 References: <20190924214630.12817-1-robh@kernel.org> <20190924214630.12817-6-robh@kernel.org> <20190925103752.GS9720@e119886-lin.cambridge.arm.com> In-Reply-To: From: Peter Maydell Date: Mon, 30 Sep 2019 17:56:51 +0100 Message-ID: Subject: Re: [PATCH 05/11] PCI: versatile: Use pci_parse_request_of_pci_ranges() To: Rob Herring Cc: Andrew Murray , Bjorn Helgaas , linux-pci@vger.kernel.org, Lorenzo Pieralisi , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, 26 Sep 2019 at 22:45, Rob Herring wrote: > > On Wed, Sep 25, 2019 at 5:37 AM Andrew Murray wrote: > > > > On Tue, Sep 24, 2019 at 04:46:24PM -0500, Rob Herring wrote: > > > Convert ARM Versatile host bridge to use the common > > > pci_parse_request_of_pci_ranges(). > > > > > > Cc: Lorenzo Pieralisi > > > Cc: Bjorn Helgaas > > > Signed-off-by: Rob Herring > > > --- > > > static int versatile_pci_probe(struct platform_device *pdev) > > > { > > > struct device *dev = &pdev->dev; > > > struct resource *res; > > > - int ret, i, myslot = -1; > > > + struct resource_entry *entry; > > > + int ret, i, myslot = -1, mem = 0; > > > > I think 'mem' should be initialised to 1, at least that's what the original > > code did. However I'm not sure why it should start from 1. > > The original code I moved from arch/arm had 32MB @ 0x0c000000 called > "PCI unused" which was requested with request_resource(), but never > provided to the PCI core. Otherwise, I kept the setup the same. No one > has complained in 4 years, though I'm not sure anyone would have > noticed if I just deleted PCI support... Yes, QEMU users will notice if you drop or break PCI support :-) I don't think anybody is using real hardware PCI though. Anyway, the 'mem' indexes here matter because you're passing them to PCI_IMAP() and PCI_SMAP(), which are writing to hardware registers. If you write to PCI_IMAP0 when we were previously writing to PCI_IMAP1 then suddenly you're not configuring the behaviour for accesses to the PCI window that's at CPU physaddr 0x50000000, you're configuring the window that's at CPU physaddr 0x44000000, which is entirely different (and notably is smaller, being only 0x0c000000 in size rather than 0x10000000). If this is supposed to be a no-behaviour-change refactor then it would probably be a good test to check that we're writing exactly the same values to the hardware registers on the device as we were before the change. thanks -- PMM From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A7ACC32792 for ; Mon, 30 Sep 2019 16:57:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1FE7A20815 for ; Mon, 30 Sep 2019 16:57:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kR+EFSK+"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lDMXPyHH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FE7A20815 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+uCjPmUBXKlVvDN17xaDPaJbODnsodU8H4T12TwfIjM=; b=kR+EFSK+kEIgBD IQt/uI+gNusmGZZlKgL0J48req0A/BzGu4R5f/AWNNaQWwPlxtL9U3ZpBiQdw9lvMtEpYmNYPSnDG ZfaY5mlGE4NPYpeYIBbm826tiW5Bjwg706WSw66XCNwPaoSyv3hAKFKofhibnUbvVsE/gLEkfLpr0 asQz0EFGD7NWazF6uusRQc0gngVCDYGQfJ58t1fINCW3kWx5Ec/dx7eiC3+Zol7a1tfcYP1kwzvSC ctvm4NEABJpKzEV62Varjg5rABmM2fLwnlfoVHlL+o2cNXIR1n9G1gqKAZQAq4C0CqlWa6UqrffWs OtXFAEeIwxUr+7ghL4hA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iEyyw-0005HT-PY; Mon, 30 Sep 2019 16:57:06 +0000 Received: from mail-ot1-x342.google.com ([2607:f8b0:4864:20::342]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iEyyt-0005Gm-ST for linux-arm-kernel@lists.infradead.org; Mon, 30 Sep 2019 16:57:05 +0000 Received: by mail-ot1-x342.google.com with SMTP id m19so8987888otp.1 for ; Mon, 30 Sep 2019 09:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZJu5nMPyA3CcXPtrWusDX9FpZgNc7KiBqwKc0pCnNk=; b=lDMXPyHH0b4q5PAmhy6A3YLJAkPCddp6btlDUZ0fPsYCu5yMeJTt74gZ5ZUXWWwe/w QnXSoca9X+Ns+PkoKCftGvH+eaa8NqLQr1kdj58zJ2hiotXy2CBBNxVuUeD0NYk76Beu YBIyyDFD6dc6upQ597O4TV60qpD4y3gXNE7Jery+lSUTFIndraj1O/EcZ1NBkAY+sVH2 v9Ff9yFBknkTGA7ZEnjAI/tM6OntsNWbkiRuV6dtG3p13i1YVPGbTfhVgwtVRieZkRmM IFBRMzd0DiKPR74GE5cGaMLRvXbhOal7CevhadIXbfMyF4jjMUB76fGc/0EZmpPBcItS cFSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZJu5nMPyA3CcXPtrWusDX9FpZgNc7KiBqwKc0pCnNk=; b=XcToqOG2KrTj4hstf+Y89rOHFAk0Yrqb6E4BGrEQu42pLxJnFE8p3a6Snng+H1QBFX xz5sJyPtu99hZxQA5HmcFFrtRJhgt/fIsPBocb0aoBNX/OFRfx+bn457oZd8FxwMMuYI ZKpp/Puq5s5ot+bSE2SaFL2qYILVwSBHgUgMLn5ywKdqOG4UHgQuYcw+tHB1DngRi/Q9 fGqUylm1RvnNtZqSEC5+W5GFClgbsesA+ChveXjlhQBvGOqcwRGkZCTPwQMLxurGRksr H9HrrqQgbH7h3j7QnDZm50jlB2Ehuf5E/V2TemplFqwKs5P1pAYxYB4dmZbrAgBPmdop 53qA== X-Gm-Message-State: APjAAAXIC3AOGF8sTfMpwPHjCo0gLgK3Bgwhv+9PT4ohGhXknKoAmPsk LB0HTlQosUJAhUYrPgPofFRGUU/S7ffXodeQ141prA== X-Google-Smtp-Source: APXvYqzB8H/7R2/+lg1XepUdOoHj928L8GWJV0m55A4x/X1lbYqO0HreOXXiM5k44rOocAfzJA5NKe2lpHDKrO0K8gI= X-Received: by 2002:a9d:562:: with SMTP id 89mr1391432otw.232.1569862622367; Mon, 30 Sep 2019 09:57:02 -0700 (PDT) MIME-Version: 1.0 References: <20190924214630.12817-1-robh@kernel.org> <20190924214630.12817-6-robh@kernel.org> <20190925103752.GS9720@e119886-lin.cambridge.arm.com> In-Reply-To: From: Peter Maydell Date: Mon, 30 Sep 2019 17:56:51 +0100 Message-ID: Subject: Re: [PATCH 05/11] PCI: versatile: Use pci_parse_request_of_pci_ranges() To: Rob Herring X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190930_095703_947713_326339C7 X-CRM114-Status: GOOD ( 18.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bjorn Helgaas , Andrew Murray , Lorenzo Pieralisi , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-pci@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 26 Sep 2019 at 22:45, Rob Herring wrote: > > On Wed, Sep 25, 2019 at 5:37 AM Andrew Murray wrote: > > > > On Tue, Sep 24, 2019 at 04:46:24PM -0500, Rob Herring wrote: > > > Convert ARM Versatile host bridge to use the common > > > pci_parse_request_of_pci_ranges(). > > > > > > Cc: Lorenzo Pieralisi > > > Cc: Bjorn Helgaas > > > Signed-off-by: Rob Herring > > > --- > > > static int versatile_pci_probe(struct platform_device *pdev) > > > { > > > struct device *dev = &pdev->dev; > > > struct resource *res; > > > - int ret, i, myslot = -1; > > > + struct resource_entry *entry; > > > + int ret, i, myslot = -1, mem = 0; > > > > I think 'mem' should be initialised to 1, at least that's what the original > > code did. However I'm not sure why it should start from 1. > > The original code I moved from arch/arm had 32MB @ 0x0c000000 called > "PCI unused" which was requested with request_resource(), but never > provided to the PCI core. Otherwise, I kept the setup the same. No one > has complained in 4 years, though I'm not sure anyone would have > noticed if I just deleted PCI support... Yes, QEMU users will notice if you drop or break PCI support :-) I don't think anybody is using real hardware PCI though. Anyway, the 'mem' indexes here matter because you're passing them to PCI_IMAP() and PCI_SMAP(), which are writing to hardware registers. If you write to PCI_IMAP0 when we were previously writing to PCI_IMAP1 then suddenly you're not configuring the behaviour for accesses to the PCI window that's at CPU physaddr 0x50000000, you're configuring the window that's at CPU physaddr 0x44000000, which is entirely different (and notably is smaller, being only 0x0c000000 in size rather than 0x10000000). If this is supposed to be a no-behaviour-change refactor then it would probably be a good test to check that we're writing exactly the same values to the hardware registers on the device as we were before the change. thanks -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel