Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp497998imm; Wed, 26 Sep 2018 02:09:49 -0700 (PDT) X-Google-Smtp-Source: ACcGV62hK8BBisURnY/qJMRZvDdFOL7Awh3SDSkxAdrO3esSsXnTIzw3wo2+Cd5Ot3JyOyCec7Av X-Received: by 2002:a17:902:b595:: with SMTP id a21-v6mr4862731pls.329.1537952989418; Wed, 26 Sep 2018 02:09:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537952989; cv=none; d=google.com; s=arc-20160816; b=SZ/DKWbL9GuSFx1A8IIJJMapouZZAF9iKLbq9u42TO1DJTIfGBBt5VNMz6gFFrGXbR BTYRrHxlasLhcxssbPxUsxq9q7+kSK9vSzAeBQG6pS+Ttylk3hLR36/QZ2RU8VQ6vgLx PVgXb9oTlReATOZK6MtzQXYkZc6/B0r1V1mrBEwtVYRd944LLIzLJu8MfVwDlkq6vTJ/ 77iIYnVwHk+eG8ehKB2jQsxSuZo5CHjwwX+glVFlDPtVPphAHAvnVoLyOxssTTGm71dK i5fdTQ0GRwi5l/WlAL6C5TXM0Hiu4ObBkVBJoFwtdAICFqFjOH3UF0qQr8BRDFLRS5u1 83Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=yUKyonS/PpXVlLMIHKmxuQq5viEPAbiK/ownmhaCnEs=; b=Kmh7Crl7hFfu5zTvEqM6DMCvqI6FELMVtOPKEeqpzJ8iCeXEhboQsMgkjSk10ZniXs l8LsJLqg927Httai8lDpQFKDZUAq/P9nhgMRypJg8tok9P2/4KyYfRJ4xWc9RZVVt0CK sES6YgtdI9uCQ0oS9aJMmn/FNn3dASmHYqA7c+roS6uJV+AAWrV7H0alqll+XeuFnsJR tk+a/FHeATSTkfxFuqmo6f/AmyWebRL8pQG/p3Qg3a4z1B+gzgTsbqkKvP/7j2c19Scu FIYaOGva61JbPiDkPouGEu46gm6iMDiheXWCdnMyxIrJuWxFKrcwv+ukXkLmMSx/JT9Q ATiw== 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 t192-v6si4641270pgc.485.2018.09.26.02.09.33; Wed, 26 Sep 2018 02:09:49 -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 S1727804AbeIZPTR (ORCPT + 99 others); Wed, 26 Sep 2018 11:19:17 -0400 Received: from Mailgw01.mediatek.com ([1.203.163.78]:58478 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727189AbeIZPTR (ORCPT ); Wed, 26 Sep 2018 11:19:17 -0400 X-UUID: 2d8760c218b84195a50847fd6a7fac91-20180926 Received: from mtkcas34.mediatek.inc [(172.27.4.250)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 1012302702; Wed, 26 Sep 2018 17:06:59 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N2.mediatek.inc (172.27.4.87) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 17:06:58 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Wed, 26 Sep 2018 17:06:57 +0800 Message-ID: <1537952817.14753.4.camel@mhfsdcap03> Subject: Re: [PATCH v4 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical From: Honghui Zhang To: Lorenzo Pieralisi CC: , , , , , , , , , , , , , , , , , Date: Wed, 26 Sep 2018 17:06:57 +0800 In-Reply-To: <20180921160745.GB21644@e107981-ln.cambridge.arm.com> References: <1536573023-6720-1-git-send-email-honghui.zhang@mediatek.com> <1536573023-6720-2-git-send-email-honghui.zhang@mediatek.com> <20180921160745.GB21644@e107981-ln.cambridge.arm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-09-21 at 17:07 +0100, Lorenzo Pieralisi wrote: > On Mon, Sep 10, 2018 at 05:50:20PM +0800, honghui.zhang@mediatek.com wrote: > > 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 logical by using the slot's > > devfn for match. > > > > Signed-off-by: Honghui Zhang > > Acked-by: Ryder Lee > > --- > > drivers/pci/controller/pcie-mediatek.c | 19 +++++++++++++++++-- > > 1 file changed, 17 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c > > index 861dda6..20b9088 100644 > > --- a/drivers/pci/controller/pcie-mediatek.c > > +++ b/drivers/pci/controller/pcie-mediatek.c > > @@ -337,11 +337,26 @@ 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; > > + struct pci_bus *pbus; > > > > - list_for_each_entry(port, &pcie->ports, list) > > - if (port->slot == PCI_SLOT(devfn)) > > + list_for_each_entry(port, &pcie->ports, list) { > > + if (!bus->number && port->slot == PCI_SLOT(devfn)) > > return port; > > > > + if (bus->number) { > > + pbus = bus; > > + > > + while (pbus->number) { > > + dev = pbus->self; > > + pbus = dev->bus; > > + } > > + > > + if (port->slot == PCI_SLOT(dev->devfn)) > > + return port; > > + } > > + } > > /* > * Walk the bus hierarchy to get the devfn value > * of the port in the root bus. > */ > while (bus && bus->number) { > devfn = bus->self->devfn; > bus = bus->parent; > } > > list_for_each_entry(port, &pcie->ports, list) { > if (port->slot == PCI_SLOT(devfn)) > return port; > > return NULL; > > Would it work ? Maybe it is a little easier to parse. > Thanks, this is much better. > I think this can even be made easier by using struct device_node* as > comparison (and store it in port->slot instead of the port number), I > think that the pci_dev representing the port should have the right > of_node associated with it by core code, so it is just a matter of > finding the first pci_dev parent with an of_node set and compare it > against port->slot (that should be converted to a struct device_node*). > > This ought to be tested and written but I think that's doable. > Thanks, I will do my homework and figure a way out through this solution. Currently port->slot is used in too much place to be removed, I guess I need to added a new parameter in the port struct to store the of_node for compare. I'm not sure which way is better, anyway, let me try the new solution. thanks. > Lorenzo