linux-kernel - Re: [PATCH v10 05/10] PCI: dwc: Use devicetree 'ranges' property to get rid of cpu_addr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250312213757.GA709739@bhelgaas>
Date: Wed, 12 Mar 2025 16:37:57 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Frank Li <Frank.Li@....com>
Cc: Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...gle.com>,
	Jingoo Han <jingoohan1@...il.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Richard Zhu <hongxing.zhu@....com>,
	Lucas Stach <l.stach@...gutronix.de>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, imx@...ts.linux.dev,
	Niklas Cassel <cassel@...nel.org>
Subject: Re: [PATCH v10 05/10] PCI: dwc: Use devicetree 'ranges' property to
 get rid of cpu_addr_fixup() callback

On Mon, Mar 10, 2025 at 04:16:43PM -0400, Frank Li wrote:
> parent_bus_offset in resource_entry can indicate address information just
> ahead of PCIe controller. Most system's bus fabric use 1:1 map between
> input and output address. but some hardware like i.MX8QXP doesn't use 1:1
> map. See below diagram:

> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -478,6 +478,15 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>  	bridge->ops = &dw_pcie_ops;
>  	bridge->child_ops = &dw_child_pcie_ops;
>  
> +	/*
> +	 * visconti_pcie_cpu_addr_fixup() use pp->io_base,
> +	 * so have to call dw_pcie_init_parent_bus_offset() after init
> +	 * pp->io_base.
> +	 */
> +	ret = dw_pcie_init_parent_bus_offset(pci, "config", pp->cfg0_base);
> +	if (ret)
> +		return ret;

The ordering in dw_pcie_host_init() doesn't look right to me.  We have
this:

  dw_pcie_host_init
    dw_pcie_get_resources
    dw_pcie_cfg0_setup
    devm_pci_alloc_host_bridge
    win = resource_list_first_type(&bridge->windows, IORESOURCE_IO)
    pp->io_base = pci_pio_to_address(win->res->start)
    bridge->ops = ...
    bridge->child_ops = ...
    dw_pcie_init_parent_bus_offset
    pp->ops->init

devm_pci_alloc_host_bridge() is generic, so it obviously can't depend
on any dwc-specific things.  I think the ordering should be more like
this:

  dw_pcie_host_init
    devm_pci_alloc_host_bridge             # generic
    dw_pcie_get_resources                  # dwc RP and EP

    dw_pcie_cfg0_setup
    win = resource_list_first_type(&bridge->windows, IORESOURCE_IO)
    pp->io_base = pci_pio_to_address(win->res->start)
    dw_pcie_init_parent_bus_offset

    bridge->ops = ...
    bridge->child_ops = ...
    pp->ops->init

and everything in the second block (dw_pcie_cfg0_setup() through
dw_pcie_init_parent_bus_offset()) is strictly DT-related resource
setup and could all go in a dw_pcie_host_get_resources() or similar.

>  	if (pp->ops->init) {
>  		ret = pp->ops->init(pp);
>  		if (ret)
> 
> -- 
> 2.34.1
>