Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3524455imm; Sun, 14 Oct 2018 22:46:13 -0700 (PDT) X-Google-Smtp-Source: ACcGV602dSJ9SOkM86MiKDDW1Of0tUpDWF8KluROvjvCo8Wppz/2/QIyTCBHmaXtNwQLVpGHqy+p X-Received: by 2002:a63:dc14:: with SMTP id s20-v6mr14967531pgg.398.1539582373554; Sun, 14 Oct 2018 22:46:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539582373; cv=none; d=google.com; s=arc-20160816; b=BzS108asIiMZL/i7zGWc4sxUhJ8ThIFVw6SS51EzI+BM+tYD7g8CypZJnB/R266ujS ILL555O3D2wYo8gQ/ieOiNUtA4VrM7vftJDI9E12hHXYbITKsn7IuECR+4uotXcNVsej mQmh6E/ZlCWtXSED5CnwvQuj2dcdmLy8zf5jAs+n+vRT5wdGcjcviGo6shTZzMwOoyLu kNfjxXrK8mS7p4tIusXV1S1Fa0/33vLjSpF6ORrEa1wecoTo829T101f6aYIj53CSgz0 y9M1QnCig14upth7sWnBoqZ19m5KnKq4V2q/ywsDaUrnYdLHSRliALvLs4cyawi7zOcO qcPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=odXE+PQxFKWASN+tzu5oty5p4+lS/mn/w9MPwm+kjxQ=; b=tprNM4Soxtz3nmHxnaA1QBJrsa3iVl1qgShHhnEPhKxkPvi6u3llZ4/tRIWAN/YeEB 21nw+cckaYjCHQFo1IrAm5xMhmK1IqtHZT1k5x5EpzNTLs0JX2IJYilMDIc7EBgLdrDT 9W5KPbEOdaqH5Msl/dK26o1+oXhvfsPf5AgZocemPsPuVQD3KRoi59R3jLUXHMjaUp0a R8GcgLIE88gECV8v+JKmT0CqmuLyZ0PixsJAqIUiMvN0Um5kkSR/8+Oq1rBIeaD0ud8W fe4YJMQZQXb4G6KSoWVdaL5M+HSL3KUaB2I0jvjzL7udTX8JD7LPQEPrinSiaeNvGIhq jnrw== 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 n188-v6si9985290pfn.113.2018.10.14.22.45.58; Sun, 14 Oct 2018 22:46:13 -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 S1727003AbeJON2w (ORCPT + 99 others); Mon, 15 Oct 2018 09:28:52 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:15915 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726663AbeJON2v (ORCPT ); Mon, 15 Oct 2018 09:28:51 -0400 X-UUID: f457e6d1e0234f75a2ca186a799dc132-20181015 X-UUID: f457e6d1e0234f75a2ca186a799dc132-20181015 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1005407080; Mon, 15 Oct 2018 13:44:52 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Oct 2018 13:44:50 +0800 Received: from localhost.localdomain (10.17.3.153) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 15 Oct 2018 13:44:50 +0800 From: To: , , , , , , CC: , , , , , , , , , Subject: [PATCH v7 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic Date: Mon, 15 Oct 2018 13:44:39 +0800 Message-ID: <1539582287-9171-2-git-send-email-honghui.zhang@mediatek.com> X-Mailer: git-send-email 2.6.4 In-Reply-To: <1539582287-9171-1-git-send-email-honghui.zhang@mediatek.com> References: <1539582287-9171-1-git-send-email-honghui.zhang@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Honghui Zhang The Mediatek's host controller has two slots, each with it's own control registers. The host driver need to identify which slot was connected in order to access the device's configuration space. There's problem for current host driver to find out which slot was connected to for a given EP device. Assuming each slot have connect with one EP device as below: host bridge bus 0 --> __________|_______ | | | | slot 0 slot 1 bus 1 -->| bus 2 --> | | | EP 0 EP 1 During PCI enumeration, system software will scan all the PCI device starting from devfn 0. So it will get the proper port for slot0 and slot1 device when using PCI_SLOT(devfn) for match. But it will get the wrong slot for EP1: The devfn will be start from 0 when scanning EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match for port0's slot value. So the host driver should not using EP's devfn but the slot's devfn(the slot which EP was connected to) for match. This patch fix the mtk_pcie_find_port's logic by using the slot's devfn for match if finding device connected to the subordinate bus. Signed-off-by: Honghui Zhang --- drivers/pci/controller/pcie-mediatek.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c index 9999dae..288b8e2 100644 --- a/drivers/pci/controller/pcie-mediatek.c +++ b/drivers/pci/controller/pcie-mediatek.c @@ -337,6 +337,17 @@ static struct mtk_pcie_port *mtk_pcie_find_port(struct pci_bus *bus, { struct mtk_pcie *pcie = bus->sysdata; struct mtk_pcie_port *port; + struct pci_dev *dev = NULL; + + /* + * Walk the bus hierarchy to get the devfn value + * of the port in the root bus. + */ + while (bus && bus->number) { + dev = bus->self; + bus = dev->bus; + devfn = dev->devfn; + } list_for_each_entry(port, &pcie->ports, list) if (port->slot == PCI_SLOT(devfn)) -- 2.6.4