Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4325999imm; Mon, 8 Oct 2018 20:09:31 -0700 (PDT) X-Google-Smtp-Source: ACcGV610SvLnvQdmvcuK097QsM03b8IEYDauhaQkFawd7j87So3X198WOpn9yDOMQBOH2bgVq2A9 X-Received: by 2002:a62:38d0:: with SMTP id f199-v6mr28034886pfa.48.1539054571716; Mon, 08 Oct 2018 20:09:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539054571; cv=none; d=google.com; s=arc-20160816; b=a4U+lwn37ZPi1W2CW3FPG6dHPwSOYj7+1SENC03QUNPBPV+s4xUr6ahywyrElLXDSD 1h15TFi7TtG9xYsfeXSDPPwSuttUVB6dWLtgeBuRxierSIRCAqcaPgLQQC8nDxlgCUBN F99KhvYZnpwGhxJIy4RJQXl713+TUweuvCBZFvagklZNB6w11pmD0X0+auKCloAtlD9e C0jJx0u9KG/QCemA+9F6VkrDrfz8Mn6fbuTxpRCy9YxJ8t5eQDhwmt5gl4cpzI+qlImP uODEiJOrL0hcGflYlkisowQk/1j4lq3oxqzI/hwT7NOf3TIFKkJKzQHPnBluGb56+GYK nvRg== 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=Z4TQ3Ug5Ld3+xcG66DKKt2sc/64e1eu+J+NFHUxGIHY=; b=lgziYKVHt93YfdFWG4AqqhxVQa6Ljq319aSOZGZG1pDIpJ1u/g+c/sRoNFaqBhPA3d GYmXaDYKKUCagEH5c3PtycJsCgV99jwRxA3HqXnLg2Kq/15Q2NAGh/LXt711+VzU+2bM ypLwtWXnJvKIKQTr/V82Yuq8VqwBxgDyz+66Y5+0x3xwnNkxhlvNidwd+l6TAUOfTz+K 0OVbkshmQPUtXLya0bKSExNeX7CJyyrRFrEPBuCrO+s2KN2Bl1oBMyEuGebk2XWn99a9 YtnloGuJuKIwZ32xm35Oc4mCuTwlrdXGHDxv6HNCoiwfiNZQf990kSbkztqC6+m5RoIF iOpQ== 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 f9-v6si18742552pgh.325.2018.10.08.20.09.04; Mon, 08 Oct 2018 20:09:31 -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 S1725947AbeJIKXQ (ORCPT + 99 others); Tue, 9 Oct 2018 06:23:16 -0400 Received: from Mailgw01.mediatek.com ([1.203.163.78]:21647 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725749AbeJIKXQ (ORCPT ); Tue, 9 Oct 2018 06:23:16 -0400 X-UUID: 5096bdfdada14104b1f0fd2f11514021-20181009 X-UUID: 5096bdfdada14104b1f0fd2f11514021-20181009 Received: from mtkcas32.mediatek.inc [(172.27.4.250)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 746380465; Tue, 09 Oct 2018 11:08:17 +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; Tue, 9 Oct 2018 11:08:16 +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; Tue, 9 Oct 2018 11:08:15 +0800 Message-ID: <1539054495.6246.31.camel@mhfsdcap03> Subject: Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI From: Honghui Zhang To: Lorenzo Pieralisi CC: , , , , , , , , , , , , , , Date: Tue, 9 Oct 2018 11:08:15 +0800 In-Reply-To: <20181008172337.GA13538@e107981-ln.cambridge.arm.com> References: <1538969088-7136-1-git-send-email-honghui.zhang@mediatek.com> <1538969088-7136-3-git-send-email-honghui.zhang@mediatek.com> <20181008172337.GA13538@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 Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote: > On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zhang@mediatek.com wrote: > > From: Honghui Zhang > > > > The PCIe controller of MT7622 has TYPE 1 configuration space type, but > > the HW default class type values is invalid. > > > > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class > > type for MT7622") have set the class ID for MT7622 as > > PCI_CLASS_BRIDGE_HOST, but it's not workable for MT7622: > > > > In __pci_bus_assign_resources, the framework only setup bridge's > > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it > > will leave the subordinary PCIe device's MMIO window un-touched. > > > > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller > > driver do. > > I think that this patch is correct but the commit log fails to pin point > the problem. The IP you are programming is a root port, that's why you > have to have the proper class code, the patch looks fine but I would > like to peek Bjorn's brain on this since it is a fundamental concept. > I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and PCI_CLASS_BRIDGE_PCI, from PCI express spec, 4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is "part of a Root Complex that connects a host CPU or CPUs to a Hierarchy". While Root Complex defines as "A defined System Element that includes at least one Host Bridge, Root port, or Root complex Integrated Endpoint". But according to my understanding, most of the root port IPs integrated with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and could be saw as a pci device when using lspci. And for MT7622, it integrated with block of internal control registers, type 1 configuration space, and is considered as a root complex. I'm not sure which CLASS type it should have: From PCI_Code-ID_r_1_10__v8-Nov_2017, class type of 0x0604(PCI_CLASS_BRIDGE_PCI) is defined as a PCI-to-PCI bridge, not literally suitable for MT7622(which is a root complex)(In my personal opinion). But it is the only workable CLASS type for MT7622 in current kernel. > If the kernel does not assign resources unless it detects a > PCI_CLASS_BRIDGE_PCI this means that for components that are > actually PCI_CLASS_BRIDGE_HOST their register set must come > preprogrammed unless I am missing something. > In the function pci_request_resource_alignment, it will by pass the resource assignment for PCI_CLASS_BRIDGE_HOST, though I'm not figured out why. > I would like to get to the bottom of this since it is a fundamental > enumeration concept. > Do you like me to re-write the commit message for this patch and put the above information in? Or just not mention the PCI_CLASS_BRIDGE_HOST assign resource routine? Thanks > Thanks, > Lorenzo > > > > > Signed-off-by: Honghui Zhang > > Acked-by: Ryder Lee > > --- > > drivers/pci/controller/pcie-mediatek.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c > > index 288b8e2..bcdac9b 100644 > > --- a/drivers/pci/controller/pcie-mediatek.c > > +++ b/drivers/pci/controller/pcie-mediatek.c > > @@ -432,7 +432,7 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port) > > val = PCI_VENDOR_ID_MEDIATEK; > > writew(val, port->base + PCIE_CONF_VEND_ID); > > > > - val = PCI_CLASS_BRIDGE_HOST; > > + val = PCI_CLASS_BRIDGE_PCI; > > writew(val, port->base + PCIE_CONF_CLASS_ID); > > } > > > > -- > > 2.6.4 > >