From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54B35C433F5 for ; Fri, 12 Nov 2021 14:20:09 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D484C60C4A for ; Fri, 12 Nov 2021 14:20:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D484C60C4A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 751B182FDB; Fri, 12 Nov 2021 15:20:06 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1636726807; bh=QWrfRkponWDRwQCyhDdkhbaDefsFfUt1hdMgJHDABbc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ABnF3pCYt8H/oP18wzNSSubMNinXfYOgsZ/sNQxY8BMBdAbzoO/7NJBRBgGxlqwYk rZk5SFIsGa5Ux6OFE/HM2K3nVTse77XCk9ElYdwafJZThajkZK2hipM9wAKRbwH1qT zz5tOGBVU/KaE9AgzWfR9sBTIGiv2t4ZA03CgQImP932UO2JHgHeHldbCqpeLir5YU BNva3cPs/4HDS89XQoUoS5lRlb7jFMO0gEt6QYXXgGBQALN8wEEXmzqB4d2Q30GSfk D+fAJgxh4U96ZXCucb04kcnt6bFpO6XeBCJGvPzYwN7bNhaXCNbjfouEVplk26sdrD 756W7Mz7dgvuQ== Received: by phobos.denx.de (Postfix, from userid 109) id CAE0282FF0; Fri, 12 Nov 2021 15:20:03 +0100 (CET) Received: from mout-u-204.mailbox.org (mout-u-204.mailbox.org [IPv6:2001:67c:2050:1::465:204]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id CC89A82FD3 for ; Fri, 12 Nov 2021 15:19:59 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sr@denx.de Received: from smtp202.mailbox.org (unknown [91.198.250.118]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-204.mailbox.org (Postfix) with ESMTPS id 4HrLMM5Kf8zQkDy; Fri, 12 Nov 2021 15:19:59 +0100 (CET) Message-ID: <3e1b48a1-7bb1-1f7d-0cc0-fe848897b28e@denx.de> Date: Fri, 12 Nov 2021 15:19:56 +0100 MIME-Version: 1.0 Subject: Re: [PATCH u-boot-marvell 09/10] arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge Content-Language: en-US To: =?UTF-8?Q?Marek_Beh=c3=ban?= Cc: u-boot@lists.denx.de, =?UTF-8?Q?Pali_Roh=c3=a1r?= , =?UTF-8?Q?Marek_Beh=c3=ban?= References: <20211111153549.29111-1-kabel@kernel.org> <20211111153549.29111-10-kabel@kernel.org> From: Stefan Roese In-Reply-To: <20211111153549.29111-10-kabel@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.35 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 11/11/21 16:35, Marek Behún wrote: > From: Pali Rohár > > PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base > Address register at offset 0x30 but its meaning is different than PCI's > Expansion ROM BAR register. Only address format of register is same. > > In reality, this device does not have any configurable PCI BARs. So ensure > that write operation into BARs (including Expansion ROM BAR) is noop and > registers always contain zero address which indicates that bars are > unsupported. > > Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus") > Signed-off-by: Pali Rohár > Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan > --- > drivers/pci/pci-aardvark.c | 54 +++++++++++++++++++++----------------- > 1 file changed, 30 insertions(+), 24 deletions(-) > > diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c > index 8abbc3ffe8..a92f00d0af 100644 > --- a/drivers/pci/pci-aardvark.c > +++ b/drivers/pci/pci-aardvark.c > @@ -202,7 +202,7 @@ struct pcie_advk { > int sec_busno; > struct udevice *dev; > struct gpio_desc reset_gpio; > - u32 cfgcache[(0x34 - 0x10) / 4]; > + u32 cfgcache[(0x3c - 0x10) / 4]; > bool cfgcrssve; > }; > > @@ -389,20 +389,19 @@ static int pcie_advk_read_config(const struct udevice *bus, pci_dev_t bdf, > } > > /* > - * The configuration space of the PCI Bridge on primary (local) bus is > + * The configuration space of the PCI Bridge on primary (first) bus is > * not accessible via PIO transfers like all other PCIe devices. PCI > * Bridge config registers are available directly in Aardvark memory > - * space starting at offset zero. Moreover PCI Bridge registers in the > - * range 0x10 - 0x34 are not available and register 0x38 (Expansion ROM > - * Base Address) is at offset 0x30. > - * We therefore read configuration space content of the primary PCI > - * Bridge from our virtual cache. > + * space starting at offset zero. The PCI Bridge config space is of > + * Type 0, but the BAR registers (including ROM BAR) don't have the same > + * meaning as in the PCIe specification. Therefore do not access BAR > + * registers and non-common registers (those which have different > + * meaning for Type 0 and Type 1 config space) of the primary PCI Bridge > + * and instead read their content from driver virtual cfgcache[]. > */ > if (busno == pcie->first_busno) { > - if (offset >= 0x10 && offset < 0x34) > + if ((offset >= 0x10 && offset < 0x34) || (offset >= 0x38 && offset < 0x3c)) > data = pcie->cfgcache[(offset - 0x10) / 4]; > - else if ((offset & ~3) == PCI_ROM_ADDRESS1) > - data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG); > else > data = advk_readl(pcie, offset & ~3); > > @@ -576,23 +575,22 @@ static int pcie_advk_write_config(struct udevice *bus, pci_dev_t bdf, > } > > /* > - * As explained in pcie_advk_read_config(), for the configuration > - * space of the primary PCI Bridge, we write the content into virtual > - * cache. > + * As explained in pcie_advk_read_config(), PCI Bridge config registers > + * are available directly in Aardvark memory space starting at offset > + * zero. Type 1 specific registers are not available, so we write their > + * content only into driver virtual cfgcache[]. > */ > if (busno == pcie->first_busno) { > - if (offset >= 0x10 && offset < 0x34) { > + if ((offset >= 0x10 && offset < 0x34) || > + (offset >= 0x38 && offset < 0x3c)) { > data = pcie->cfgcache[(offset - 0x10) / 4]; > data = pci_conv_size_to_32(data, value, offset, size); > /* This PCI bridge does not have configurable bars */ > if ((offset & ~3) == PCI_BASE_ADDRESS_0 || > - (offset & ~3) == PCI_BASE_ADDRESS_1) > + (offset & ~3) == PCI_BASE_ADDRESS_1 || > + (offset & ~3) == PCI_ROM_ADDRESS1) > data = 0x0; > pcie->cfgcache[(offset - 0x10) / 4] = data; > - } else if ((offset & ~3) == PCI_ROM_ADDRESS1) { > - data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG); > - data = pci_conv_size_to_32(data, value, offset, size); > - advk_writel(pcie, data, PCIE_CORE_EXP_ROM_BAR_REG); > } else { > data = advk_readl(pcie, offset & ~3); > data = pci_conv_size_to_32(data, value, offset, size); > @@ -830,12 +828,20 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie) > * > * Note that this Aardvark PCI Bridge does not have a compliant Type 1 > * Configuration Space and it even cannot be accessed via Aardvark's > - * PCI config space access method. Something like config space is > + * PCI config space access method. Aardvark PCI Bridge Config space is > * available in internal Aardvark registers starting at offset 0x0 > - * and is reported as Type 0. In range 0x10 - 0x34 it has totally > - * different registers. So our driver reports Header Type as Type 1 and > - * for the above mentioned range redirects access to the virtual > - * cfgcache[] buffer, which avoids changing internal Aardvark registers. > + * and has format of Type 0 config space. > + * > + * Moreover Type 0 BAR registers (ranges 0x10 - 0x28 and 0x30 - 0x34) > + * have the same format in Marvell's specification as in PCIe > + * specification, but their meaning is totally different (and not even > + * the same meaning as explained in the corresponding comment in the > + * pci_mvebu driver; aardvark is still different). > + * > + * So our driver converts Type 0 config space to Type 1 and reports > + * Header Type as Type 1. Access to BAR registers and to non-existent > + * Type 1 registers is redirected to the virtual cfgcache[] buffer, > + * which avoids changing unrelated registers. > */ > reg = advk_readl(pcie, PCIE_CORE_DEV_REV_REG); > reg &= ~0xffffff00; > Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de