Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp817778imm; Fri, 12 Oct 2018 07:12:40 -0700 (PDT) X-Google-Smtp-Source: ACcGV60cwCkKhnQ+EaLuJsciufOFNpWJxNTgpZehtmnnxS5abSSn2r4IdIKKMpfht/hdbos5lj6k X-Received: by 2002:a62:d286:: with SMTP id c128-v6mr6285833pfg.14.1539353560808; Fri, 12 Oct 2018 07:12:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539353560; cv=none; d=google.com; s=arc-20160816; b=g7EKTNIpXzN9qGJI9ZDI1K+FEyQ6uyzcxEdu+cpmI67Kgv3xonHgok6fnM24AYSmn0 /wFDdFNrLRZ2Ekdn8ZByMeqzrEPg2IVFva1qHqwhPWJqRwI/LL1dfqZUdKyBpxY+Vhlo h77tDx1RuJqZPdaloAd8yJ0cP3qxX95pvOU1SrON0zEGpVzW6jQjKH/ZZlxg7zPYD/AG uPHBrmhbsadl46KlGdbl7TDFc2oQQj8FAg4kOD19NVfD6Y5p9NTM+M8w+s5FEsHAU5DB TYYkS+chgiavvT90QQPymO8CfKlzgdJd3u2uDdOKvPTvBaW/17vp0u5TbsZ4rOrZkovL Evbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=qSGuwHzRNuJd/CNgccUvY8J6UgRjG1rv2WoMcW7EUgo=; b=n7vQgOmlwRsVVxQkMT56rnR0r8uRPhSQzpbJ/0+lFiYJA73l2n3fDgRMGNSCc6JA6N /M2c9VIWfB+OTY9v4ckRZTAHF1hCGLHIKmtc2V7xXNlaNYPWwYpscvhktfilzFyZytTx 4mYb8FDNHSHaUE8R9Pz3kz0LgewaJ8aWbe7GyiA7jtRpCnlnQLyOTw2OFA3bjnJOHj/7 0vulzhnLF79BXJjH6gZk0wbiYJJX2JY8Y9Vp3xJMHv9WfmVmMZ7WuBWZ+DAaubm1zhj+ cywLeR4UImZnUNv5e/rLf8reQRfJED4dQCycmQG7CCvkQumBRYpd9h0HuzOqCn8l3P+/ HDTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vso2qTfJ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e68-v6si1459739plb.313.2018.10.12.07.12.25; Fri, 12 Oct 2018 07:12:40 -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; dkim=pass header.i=@kernel.org header.s=default header.b=vso2qTfJ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728697AbeJLVom (ORCPT + 99 others); Fri, 12 Oct 2018 17:44:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:50946 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727556AbeJLVom (ORCPT ); Fri, 12 Oct 2018 17:44:42 -0400 Received: from localhost (173-25-171-118.client.mchsi.com [173.25.171.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6BA0D20865; Fri, 12 Oct 2018 14:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539353523; bh=CKvCBuA6IzW7GHE1xVto+p7dZP7LSaW8b+nPCeM/5g0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vso2qTfJPU+23/psH5WDhwLR82G1Xu/UfJQCkrH3NZkxokrlfvAEsOSFfYWnR0k4Y sCcSQmX7eJSd0f76PdynlBHcB4FB81OQ/g/JarYFsUCBS4887qS0hxThnWFXybMSsJ bYjE3L0fLRn4oInjd2g39pm/OecWb2lw4j3dGgB4= Date: Fri, 12 Oct 2018 09:12:02 -0500 From: Bjorn Helgaas To: Lorenzo Pieralisi Cc: Honghui Zhang , youlin.pei@mediatek.com, devicetree@vger.kernel.org, ulf.hansson@linaro.org, ryder.lee@mediatek.com, marc.zyngier@arm.com, linux-pci@vger.kernel.org, sean.wang@mediatek.com, linux-kernel@vger.kernel.org, yt.shen@mediatek.com, matthias.bgg@gmail.com, linux-mediatek@lists.infradead.org, bhelgaas@google.com, yingjoe.chen@mediatek.com, eddie.huang@mediatek.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI Message-ID: <20181012141202.GV5906@bhelgaas-glaptop.roam.corp.google.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> <1539054495.6246.31.camel@mhfsdcap03> <20181011113748.GA3574@e107981-ln.cambridge.arm.com> <1539331289.6246.61.camel@mhfsdcap03> <20181012102230.GA23257@e107981-ln.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181012102230.GA23257@e107981-ln.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 12, 2018 at 11:22:30AM +0100, Lorenzo Pieralisi wrote: > On Fri, Oct 12, 2018 at 04:01:29PM +0800, Honghui Zhang wrote: >> On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote: >>> On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote: >>>> 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_HOSTe, 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. I think __pci_bus_assign_resources() should be testing dev->hdr_type instead of dev->class. The connection between "Header Type" and the layout of the rest of the header is very explicit (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9), and the reason for the switch statement in __pci_bus_assign_resources() is precisely to determine which layout to use. There are several other uses of dev->class in setup-bus.c that I think should also be changed to use dev->hdr_type. If we make these changes in setup-bus.c, I suspect the class code you assign won't matter too much. There are a few other tests of the class code to figure out whether to leave certain things untouched. These seem a little hacky to me, but we're probably stuck with them for now, so you should look and see whether they apply to your situation. >>>> And for MT7622, it integrated with block of internal control >>>> registers, type 1 configuration space, and is considered as a >>>> root complex. >>> >>> I assume you mean a type 1 config header here. I do not think it >>> is mandatory for a host bridge to have a type 1 config header (and >>> related bridge windows + primary/secondary/subordinate bus >>> numbers) but I do not know how the IP you are programming is >>> designed. It is definitely not mandatory for a host bridge to have a type 1 header. I'm not even sure that would make sense: the "Primary Bus Number" would not apply to a host bridge (since a host bridge's primary bus is some sort of CPU bus, not a PCI bus), and a type 1 device cannot perform address translation between its primary and secondary buses, while a host bridge can. A Root Port is a type 1 device where the primary bus is logically internal to the Root Complex. A host bridge bridges from the CPU bus to that internal bus and might perform address translation. The Root Port must be a PCI device. A host bridge, being a bridge *to* the PCI domain, is not itself generally programmed via PCI config space and might not even be visible as a device in PCI config space. Bjorn