Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1287723pxb; Fri, 21 Jan 2022 14:25:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJxIUlYUt+v1O6EeHB15nuTQnchnfsTQ7BnoLOHUhStjkYEc/LVb+DjxTueOQT0nd8Y6Yroq X-Received: by 2002:a17:902:ed85:b0:14a:2471:e11d with SMTP id e5-20020a170902ed8500b0014a2471e11dmr5374508plj.77.1642803949279; Fri, 21 Jan 2022 14:25:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642803949; cv=none; d=google.com; s=arc-20160816; b=PvEuawOIZw9R0WUiWjxzIGCzn9N82ax7igJ3fwAFwUyrFKw0fkJU5sCs0uAVmcEn1R thqeSuEJaaLBVk9Bi8Bkc7/t1tKlQr9rozcDAVVydrz/6TmfnASeBWK5rTQx8E1VbkR3 dzeIQE/BbKk6R4nXvjxgm1+0TELbEl5N7IgYUvO73IYwNMlsGkfQOj23YtZ+JQkvZFt/ E8LW/Q/mAr1Od/fVeA1RqRZ+ZreTmMf8X5rjH8nbyeFO0D80BeLAQvt8TJUVM3f4UR5z S4kXSjq0lgoUCOjD+JcpISumM2c2RVeRioU5wP2FTEkmEV7IR+t5kyAh/nN0bdhPXuQh Bk6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=uqR+M0f6nY5IGGBB8YyDUxIOM206oVa7rpzYzubIiNs=; b=CWT1AGqoYpALDS/exKc0/LaUHRPTEeduwYtWkeSqSGbceTXH9nfDgphcOHmjfpgOLS pl/L1HJVpQZqpUveaSR7zHqX8VBRCgcnEyfapBpWIU8FWSTB1y7ouVej3wcp91N2k57x o5THlQH2y3TclztvSjIIB2Y7qlEZAmhhXMx4Lno/9trPqgwIDbgnMuvfr4kRvv/Ekbjq tgY7KG/OEZmOShtVM7kVCMkbkTAJqOiHZFw7cTaeEJHHetWmbbJWfWM7FdP3adxaPTJE OUxCkfWACfbxcz/+RVG+iE6t0/657VJdQNEXa5L5ANZW2jqz92CwfvArqf9IRzXusV1G chTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="nMUoaQ/G"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l11si2608365pgh.463.2022.01.21.14.25.36; Fri, 21 Jan 2022 14:25:49 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="nMUoaQ/G"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377147AbiATQzf (ORCPT + 99 others); Thu, 20 Jan 2022 11:55:35 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:45288 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377150AbiATQz3 (ORCPT ); Thu, 20 Jan 2022 11:55:29 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 39CF9B81D9A; Thu, 20 Jan 2022 16:55:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B409FC340E0; Thu, 20 Jan 2022 16:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642697726; bh=o20Ul3D9Y2N1+dr7mv+rpVpkHpntzq/L0UM+ShSK1vI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nMUoaQ/Ghu4KvBsNlkhVvvfqakxkDHzLBpJhqUvfx5YkZieHnBgMLJnIWM/KT+EyA G7qUMz7AUxV05ngKCb5zYCmWxZTdl2W6fTJzSThJmpDRKe69BTz11+o1wLJIj+aQp3 PKLCYo/HkZk+CPdC7pYMcnzp6S2nQ/K70Bzuzl0I+3wUip+Nvx4Jt9kI7M701kDoxX 8vJ6tslAF2h6TVBLR7njLt2hzT3UPaQUOYLbkLddWgRMqdRRqlR3XeqTyKZqEXDlaz LtGJRRX9lh9Nw+UqXNrHN43QQ8EyfnVqKnmkM3WbKQGuBomslEFM8+WpguP5AqVJOe UKeBtcBUaPxow== Received: by pali.im (Postfix) id A979E791; Thu, 20 Jan 2022 17:55:22 +0100 (CET) Date: Thu, 20 Jan 2022 17:55:22 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Rob Herring Cc: Lorenzo Pieralisi , Bjorn Helgaas , Thomas Petazzoni , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Marek =?utf-8?B?QmVow7pu?= , Russell King , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 08/11] PCI: mvebu: Use child_ops API Message-ID: <20220120165522.v2xitzokcom4phmw@pali> References: <20220105150239.9628-1-pali@kernel.org> <20220112151814.24361-1-pali@kernel.org> <20220112151814.24361-9-pali@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 20 January 2022 10:49:05 Rob Herring wrote: > On Wed, Jan 12, 2022 at 04:18:11PM +0100, Pali Rohár wrote: > > Split struct pci_ops between ops and child_ops. Member ops is used for > > accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for > > accessing real PCIe cards. > > > > There is no need to mix these two struct pci_ops into one as PCI core code > > already provides separate callbacks via bridge->ops and bridge->child_ops. > > > > Signed-off-by: Pali Rohár > > --- > > drivers/pci/controller/pci-mvebu.c | 82 ++++++++++++++++-------------- > > 1 file changed, 44 insertions(+), 38 deletions(-) > > > > diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c > > index 9ea2f6a7c2b0..1e90ab888075 100644 > > --- a/drivers/pci/controller/pci-mvebu.c > > +++ b/drivers/pci/controller/pci-mvebu.c > > @@ -294,11 +294,29 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port) > > mvebu_writel(port, mask, PCIE_MASK_OFF); > > } > > > > -static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port, > > - struct pci_bus *bus, > > - u32 devfn, int where, int size, u32 *val) > > +static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie, > > + struct pci_bus *bus, > > + int devfn); > > + > > +static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where, > > + int size, u32 *val) > > { > > - void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF; > > + struct mvebu_pcie *pcie = bus->sysdata; > > + struct mvebu_pcie_port *port; > > + void __iomem *conf_data; > > + > > + port = mvebu_pcie_find_port(pcie, bus, devfn); > > + if (!port) { > > + *val = 0xffffffff; > > + return PCIBIOS_DEVICE_NOT_FOUND; > > + } > > + > > + if (!mvebu_pcie_link_up(port)) { > > + *val = 0xffffffff; > > + return PCIBIOS_DEVICE_NOT_FOUND; > > + } > > + > > + conf_data = port->base + PCIE_CONF_DATA_OFF; > > > > mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where), > > PCIE_CONF_ADDR_OFF); > > @@ -321,11 +339,21 @@ static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port, > > return PCIBIOS_SUCCESSFUL; > > } > > > > -static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port, > > - struct pci_bus *bus, > > - u32 devfn, int where, int size, u32 val) > > +static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn, > > + int where, int size, u32 val) > > { > > - void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF; > > + struct mvebu_pcie *pcie = bus->sysdata; > > + struct mvebu_pcie_port *port; > > + void __iomem *conf_data; > > + > > > + port = mvebu_pcie_find_port(pcie, bus, devfn); > > + if (!port) > > + return PCIBIOS_DEVICE_NOT_FOUND; > > + > > + if (!mvebu_pcie_link_up(port)) > > + return PCIBIOS_DEVICE_NOT_FOUND; > > + > > + conf_data = port->base + PCIE_CONF_DATA_OFF; > > Again, the same setup code in read and write is a sign to use > .map_bus(). You can copy it from my version I pointed you to. > > Rob I'm planning to do other cleanup in followup patches. But there are too many mvebu and aardvark patches on the list waiting, and I do not want to send another batch.