Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp557234imm; Fri, 28 Sep 2018 03:06:37 -0700 (PDT) X-Google-Smtp-Source: ACcGV604XgIZyxhkqOYL8sjKhRv5whR1up57e5ToVW3BkALUTQGu3rbPMJeYNjP9seDpjmMvAcjk X-Received: by 2002:a62:51c6:: with SMTP id f189-v6mr16019371pfb.7.1538129197674; Fri, 28 Sep 2018 03:06:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538129197; cv=none; d=google.com; s=arc-20160816; b=dmRx4mYJmg431rgwiMy6eJ8WG0zA0IL2qDK/sxKTygiB13JutgHmxU2Gniq3xKuYrA JYHqEco3tPWs/SSho9VUcv5540t+8YxogyaNGIODHDQxumhjYbRkZeCsKov7bM4wrg++ X5JObYL8kctBOJyevkVHL2Rn4lhv2a8jCMOz+0TxxSUwgeM+iOnHsS3CblzAIukfH/s1 1mtWAX35XDrnFBp2OrVMTqHbQuRgp41NOoLybPFNLQWQrox5UCuk6rSyERDlGibzjfsd 0WJTB7YvkqWiD7E5qCNJpWGNy7oIstLSj9kx1Z59xJ+zu4vnHozwL54kGYVfill9Y/sv 6oeA== 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=lIJ+VNi65LLQWWt0SG1ppunFcrE4/TnvflcKiCUf9Ps=; b=U7lOQidVcWoGFmbnBF5OdXtG+MHFmJb1O962H3gV5PLq0GUm4dpQlU8DlWRqE2yo9J fjJdZaWNftI2Hui0UEQrrMavb8kMEqCt5kAuUKk/tZUQC/v3AJKxXRL0TFQp4ZHgvHMB EOFhrT07TbiomvCYDlWqIXlG91T55FCgXYPHLG4TjGLOAU2F9BGZMp8ViV7BmcHIW/Ym DQZ0stYWL8Yxaf8C+SrqkrKpYWKP/qw3hWghYdbF80XIr3A3Oh19+Kyz3jqUJyiqX0RQ xoD9ipoO3i06L10p7y4yc8g+AQpXTUmVSx+wxjbRM+Ag2OdX6CBYH4kTZ4RBe7383+U2 2KtQ== 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 r3-v6si3512945pga.321.2018.09.28.03.06.22; Fri, 28 Sep 2018 03:06:37 -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 S1729300AbeI1Q1u (ORCPT + 99 others); Fri, 28 Sep 2018 12:27:50 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:45099 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729268AbeI1Q1s (ORCPT ); Fri, 28 Sep 2018 12:27:48 -0400 X-UUID: fdd5fcdeb3d944f9bf6fef344bfe3795-20180928 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 2050651582; Fri, 28 Sep 2018 18:04:45 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Sep 2018 18:04:43 +0800 Received: from localhost.localdomain (10.17.3.153) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 28 Sep 2018 18:04:42 +0800 From: To: , , , , , , CC: , , , , , , , , , Subject: [PATCH v5 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic Date: Fri, 28 Sep 2018 18:04:32 +0800 Message-ID: <1538129080-8206-2-git-send-email-honghui.zhang@mediatek.com> X-Mailer: git-send-email 2.6.4 In-Reply-To: <1538129080-8206-1-git-send-email-honghui.zhang@mediatek.com> References: <1538129080-8206-1-git-send-email-honghui.zhang@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-SNTS-SMTP: 5855F8BC4DEC6CD93D2617F41CDD3F62E583445DEB4E583805C1A9F4FD3E039E2000:8 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 | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c index 9999dae..264e03f 100644 --- a/drivers/pci/controller/pcie-mediatek.c +++ b/drivers/pci/controller/pcie-mediatek.c @@ -337,10 +337,25 @@ 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; + } + + list_for_each_entry(port, &pcie->ports, list) { + /* Using slot's devfn to compare for subordinary bus. */ + if (dev) + devfn = dev->devfn; - list_for_each_entry(port, &pcie->ports, list) if (port->slot == PCI_SLOT(devfn)) return port; + } return NULL; } -- 2.6.4