Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4271225pxb; Tue, 2 Nov 2021 07:04:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRKZ9uU5LLp7lSe7UQvkwqtTdHm15bt7r5XkrJi0XRUKfrvSZNSf5KDNNyOF6AU9T63gvO X-Received: by 2002:a05:6402:10d2:: with SMTP id p18mr51650714edu.161.1635861858978; Tue, 02 Nov 2021 07:04:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635861858; cv=none; d=google.com; s=arc-20160816; b=bSt186zWQt1DPu5PWxgq4bQR8d1lMavlshOI++TyOFEoJ5a5SKc+b+MXKPIMlGT24e bY3malKfT4ENWP+iVUP8iUZGHZe+FqVBPmoa/8w1EPOZNGYhVlYGyUVlHozmksIuYrps MSQ8rDa5q5LzRg/9G2vTEZClKQwCq4JEQB+ZghEFyFA7+Yh+2B2N4RIFCi8d8gkTrrP5 Ni4VTxtHCyP2GFtx4nDenYOjLFN9tvggb97OxQuv2K218Rx3vKMiatCihZO2vzT5k0Va 4jmnEjFMVHy2lULnmYGlIDXipaNHETKauuIGcrB+7vGf2FgFFSv+QJvq2NioRVCqu5S7 ubZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:message-id:in-reply-to:subject:cc:to:from :date; bh=ZKMGvQsPKcF9689XO62EaD6ymwZa/19XKqFXDfanRFI=; b=hMHnN+8Kgl2scU3iVMmgeGhX4qUQxuzQGI5opNR+cecG8gKxYSBJvxIipilSBJf6f7 JTFRkFwdm2kuYGYIph+PW7SRAEIiwl29qDtQxyipKITucWEt2/Uka6cwsLraMyVE2riX Z9/5G/dA+6gmU2JF8vK0lBy5k9LkK6cjZPZoXMOINDuDV5kEKJJ4YwcQ8xsCo2oc3ZNj Jno6dNVWuVhbKPEkuQA5jzLYlLjrP4aJCaarc6Hj8ruaUlw4b3HAA1seSyqPGkRz+7vn MeJ6DbxtmkGArpFzxsI2h1A8KDN0E2gJ0tYvikprmnpRa/mMPNZ1VEz2GpnuRqTtMVpe QfYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h5si22211755ejj.144.2021.11.02.07.03.49; Tue, 02 Nov 2021 07:04:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231138AbhKBOES (ORCPT + 99 others); Tue, 2 Nov 2021 10:04:18 -0400 Received: from angie.orcam.me.uk ([78.133.224.34]:36590 "EHLO angie.orcam.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230257AbhKBOES (ORCPT ); Tue, 2 Nov 2021 10:04:18 -0400 Received: by angie.orcam.me.uk (Postfix, from userid 500) id B92D992009D; Tue, 2 Nov 2021 15:01:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id B1C7B92009B; Tue, 2 Nov 2021 14:01:41 +0000 (GMT) Date: Tue, 2 Nov 2021 14:01:41 +0000 (GMT) From: "Maciej W. Rozycki" To: =?UTF-8?Q?Pali_Roh=C3=A1r?= cc: Thomas Bogendoerfer , Russell King , Andrew Lunn , Sebastian Hesselbarth , Gregory Clement , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] PCI: Marvell: Update PCIe fixup In-Reply-To: <20211102125843.sqsusis4krnmhorq@pali> Message-ID: References: <20211101150405.14618-1-pali@kernel.org> <20211102084241.GA6134@alpha.franken.de> <20211102090246.unmbruykfdjabfga@pali> <20211102094700.GA7376@alpha.franken.de> <20211102100034.rhcb3k2jvr6alm6y@pali> <20211102125843.sqsusis4krnmhorq@pali> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Nov 2021, Pali Rohár wrote: > > None of the Galileo system controllers I came across had the class code > > set incorrectly. > > In kernel there is quirk only for one device with id: > PCI_VENDOR_ID_MARVELL (0x11ab) PCI_DEVICE_ID_MARVELL_GT64111 (0x4146) > > So for some reasons quirk is needed... Anyway, patch for this quirk just > adds comment as there is no explanation for it. It does not modify quirk > code. > > So it is possible that Marvell (or rather Galileo at that time) included > some config space fixup in some products and 0x4146 did not have it. > Just guessing... We can really only guess what could happen at that time > 20 years ago... Ah, there you go! -- sadly I don't seem to have a copy of the datasheet for the GT-64111, but the GT-64115 has it[1]: Table 158: PCI Class Code and Revision ID, Offset: 0x008 Bits Field name Function Initial Value 7:0 RevID Indicates the GT-64115 PCI Revision 0x01 number. 15:8 Reserved Read only. 0x0 23:16 SubClass Indicates the GT-64115 Subclass - Mem- 0x80 ory controller. 31:24 BaseClass Indicates the GT-64115 Base Class - 0x05 memory controller. and then: "Device and Vendor ID (0x000), Class Code and Revision ID (0x008), and Header Type (0x00e) fields are read only from the PCI bus. These fields can be modified and read via the CPU bus." Likewise with the GT-64120[2]: Table 208: PCI_0 Class Code and Revision ID, Offset: 0x008 from PCI_0 or CPU; 0x088 from PCI_1 Bits Field name Function Initial Value 7:0 RevID Indicates the GT-64120 PCI_0 revision number. 0x02 15:8 Reserved Read Only 0. 0x0 23:16 SubClass Indicates the GT-64120 Subclass Depends on value 0x00 - Host Bridge Device. sampled at reset 0x80 - Memory Device. on BankSel[0]. See Table 44 on page 11-1. 31:24 BaseClass Indicates the GT-64120 Base Class Depends on value 0x06 - Bridge Device. sampled at reset 0x05 - Memory Device. on BankSel[0]. See Table 44 on page 11-1. Table 209: PCI_1 Class Code and Revision ID, Offset: 0x088 from PCI_0 or CPU; 0x008 from PCI_1 Bits Field name Function Initial Value 31:0 Various Same as for PCI_0 Class Code and Revision ID. and then also: "Device and Vendor ID (0x000), Class Code and Revision ID (0x008), and Header Type (0x00e) fields are read only from the PCI bus. These fields can be modified and read via the CPU bus." -- so this is system-specific and an intended chip feature rather than an erratum (or rather it is a system erratum if the reset strap or the boot firmware has got it wrong). The memory device class code is IIUC meant to be typically chosen when the Galileo/Marvell device is used without the CPU interface, i.e. as a PCI memory controller device only[3]. > > The lack of a quirk with a platform does not mean it cannot have a certain > > PCI/e device. > > This is 11ab:4620 device an there is no PCIe capability in its config > space (you can inspect it via 'lspci -F dump.txt -nn -vv' but there is > nothing interesting). Of course, just as Thomas told you about the GT-64111 too. But you were right in that the memory controller feature seems shared across all the chip line, whether PCI or PCIe. References: [1] "GT-64115 System Controller for RC4640, RM523X, and VR4300 CPUs", Galileo Technology, Datasheet Revision 1.11, APR 04, 2000, Section 18.16 "PCI Configuration", p. 161 [2] "GT-64120 System Controller For RC4650/4700/5000 and RM526X/527X/7000 CPUs", Galileo Technology, Datasheet Revision 1.4, SEP 14, 1999, Section 17.16 "PCI Configuration", p. 17-59 [3] same, Chapter 14. "Using the GT-64120 Without the CPU Interface", p. 14-1 Maciej