linux-kernel - Re: [PATCH v8 4/5] PCI: andes: Add Andes QiLai SoC PCIe host driver support

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] [day] [month] [year] [list]

Message-ID: <20251021170516.GA1193376@bhelgaas>
Date: Tue, 21 Oct 2025 12:05:16 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Randolph Lin <randolph@...estech.com>
Cc: linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
	jingoohan1@...il.com, mani@...nel.org, lpieralisi@...nel.org,
	kwilczynski@...nel.org, robh@...nel.org, bhelgaas@...gle.com,
	krzk+dt@...nel.org, conor+dt@...nel.org, alex@...ti.fr,
	aou@...s.berkeley.edu, palmer@...belt.com, paul.walmsley@...ive.com,
	ben717@...estech.com, inochiama@...il.com,
	thippeswamy.havalige@....com, namcao@...utronix.de,
	shradha.t@...sung.com, pjw@...nel.org, randolph.sklin@...il.com,
	tim609@...estech.com
Subject: Re: [PATCH v8 4/5] PCI: andes: Add Andes QiLai SoC PCIe host driver
 support

On Tue, Oct 14, 2025 at 08:03:48PM +0800, Randolph Lin wrote:
> Add driver support for DesignWare based PCIe controller in Andes
> QiLai SoC. The driver only supports the Root Complex mode.

> + * Setup the Qilai PCIe IOCP (IO Coherence Port) Read/Write Behaviors to the
> + * Write-Back, Read and Write Allocate mode.

s/Setup/Set up/
s/Qilai/QiLai/

> + * The QiLai SoC PCIe controller's outbound iATU region supports
> + * a maximum size of SZ_4G - 1. To prevent programming failures,
> + * only consider bridge->windows with sizes within this limit.
> + *
> + * To ensure compatibility with most endpoint devices, at least
> + * one memory region must be mapped within the 32-bits address space.
> + */
> +static int qilai_pcie_host_fix_ob_iatu_count(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct device *dev = pci->dev;
> +	struct resource_entry *entry;
> +	/* Reserved 1 ob iATU for config space */
> +	int count = 1;
> +	bool ranges_32bits = false;
> +	u64 pci_addr;
> +	u64 size;
> +
> +	resource_list_for_each_entry(entry, &pp->bridge->windows) {
> +		if (resource_type(entry->res) != IORESOURCE_MEM)
> +			continue;
> +
> +		size = resource_size(entry->res);
> +		if (size < SZ_4G)
> +			count++;
> +
> +		pci_addr = entry->res->start - entry->offset;
> +		if (pci_addr < SZ_4G)
> +			ranges_32bits = true;
> +	}
> +
> +	if (!ranges_32bits) {
> +		dev_err(dev, "Bridge window must contain 32-bits address\n");
> +		return -EINVAL;

Is this really a PCI host controller driver probe failure?  I assume
there are devices that only have 64-bit BARs and could work fine
without a 32-bit window?

If a device requires a 32-bit BAR, and the PCI core can't assign such
an address, and gracefully decline to enable a device where we
couldn't assign the BAR, I think that would be preferable and would
identify the specific device that doesn't work.

> +	}
> +
> +	pci->num_ob_windows = count;
> +
> +	return 0;
> +}