Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3106166imm; Sun, 7 Oct 2018 20:27:25 -0700 (PDT) X-Google-Smtp-Source: ACcGV631se5YxIKU7Zvi5PJdkMsXdKjFKtnxrw+vsD/+UVL02ltPh/1B+OIPYgxvMmtrBoeC1rCd X-Received: by 2002:a62:4ec9:: with SMTP id c192-v6mr23097703pfb.221.1538969245214; Sun, 07 Oct 2018 20:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538969245; cv=none; d=google.com; s=arc-20160816; b=P+Y7uMAL4qeJyrF+A7/381afXaE/hK7IsLmmWA+1VMI9m8lmBJ65ccf3OMFzqVtVRU qq6llS9OhmdtC8Up6GyFrfMogLDi/BbajgFqK2T9YBBMkDdYu/cqn3TMVjaFBJ9vczDJ b4QXrXH9XesNc/kT5DmHuxL6yfMO5Ql3mCglaT+qwn/b+WjoHdiNNbTBKcRvZakIB9PV sT2UVd3mJvhO24pDUm1lspweIVShGl46DBuMcwa1PmdK1drt0zRy6B3tyzSU01wUtYlB AfDOmGADUx674ICwvH5mAwEiHhjeXIyWi2iplTfvjVxQt6fJVCje0le7SZJDTqwfvDb7 2E3Q== 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=h3QNwClHBdTa7BkuQNEmon5wTiNIXb3QP+jxLIxu+jXHtkpQWroVsKsWcpORN5E/ju ltH6uKrWk1hSPm04NglffBGPpglg9XIRlGuWL381oel7rCl2RIfsqYeipHYVF3l/e0C1 Dty5mmzeVJpQiqNhPE6Cq/EA9ozKlMaFZH79m1KkBDsSEUI0CL7gmjPumE772TPVZ0NB vK6YBNRLhf2cnVWtP5TAsYfHn4ZG63v3F3AYqDakly5LqL2l0t3cWi47YddYINxl/oNL O72QxQxrc5r6jbRTVGvLDL+Z7+gKvqOlHkhOBHzgWzxBoXByIBO9KXKX3FexoGpELBFS pF0w== 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 v11-v6si13741233pgl.40.2018.10.07.20.27.09; Sun, 07 Oct 2018 20:27:25 -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 S1726867AbeJHKeo (ORCPT + 99 others); Mon, 8 Oct 2018 06:34:44 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:51367 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726656AbeJHKeo (ORCPT ); Mon, 8 Oct 2018 06:34:44 -0400 X-UUID: 2f31724e6c4a43c3883a2497b2c4eec9-20181008 X-UUID: 2f31724e6c4a43c3883a2497b2c4eec9-20181008 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 845126148; Mon, 08 Oct 2018 11:25:01 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Oct 2018 11:24:59 +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; Mon, 8 Oct 2018 11:24:59 +0800 From: To: , , , , , , CC: , , , , , , , , , Subject: [PATCH v6 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic Date: Mon, 8 Oct 2018 11:24:40 +0800 Message-ID: <1538969088-7136-2-git-send-email-honghui.zhang@mediatek.com> X-Mailer: git-send-email 2.6.4 In-Reply-To: <1538969088-7136-1-git-send-email-honghui.zhang@mediatek.com> References: <1538969088-7136-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