linux-kernel - Re: [PATCH v6 1/5] PCI: dwc: Allow adjusting the number of ob/ib windows in glue driver

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aPDTJKwmpxolGEyj@swlinux02>
Date: Thu, 16 Oct 2025 19:12:36 +0800
From: Randolph Lin <randolph@...estech.com>
To: Niklas Cassel <cassel@...nel.org>
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 v6 1/5] PCI: dwc: Allow adjusting the number of ob/ib
 windows in glue driver

Hi Niklas,

On Tue, Oct 14, 2025 at 11:43:53AM +0200, Niklas Cassel wrote:
> [EXTERNAL MAIL]
> 
> On Fri, Oct 03, 2025 at 10:35:23AM +0800, Randolph Lin wrote:
> > The number of ob/ib windows is determined through write-read loops
> > on registers in the core driver. Some glue drivers need to adjust
> > the number of ob/ib windows to meet specific requirements,such as
> 
> Missing space after comma.
> 
> 

Thanks a lot. I will fix it in the next patch.

> > hardware limitations. This change allows the glue driver to adjust
> > the number of ob/ib windows to satisfy platform-specific constraints.
> > The glue driver may adjust the number of ob/ib windows, but the values
> > must stay within hardware limits.
> 
> Could we please get a better explaination than "satisfy platform-specific
> constraints" ?
> 

Due to this SoC design, only iATU regions with mapped addresses within the
32-bits address range need to be programmed. However, this SoC has a design
limitation in which the maximum region size supported by a single iATU
entry is restricted to 4 GB, as it is based on a 32-bits address region.

For most EP devices, we can only define one entry in the "ranges" property
of the devicetree that maps an address within the 32-bit range,
as shown below:
	ranges = <0x02000000 0x0 0x10000000 0x0 0x10000000 0x0 0xf0000000>;

For EP devices that require 64-bits address mapping (e.g., GPUs), BAR
resources cannot be assigned.
To support such devices, an additional entry for 64-bits address mapping is
required, as shown below:
	ranges = <0x02000000 0x0 0x10000000 0x0 0x10000000 0x0 0xf0000000>,
		 <0x43000000 0x1 0x00000000 0x1 0x00000000 0x7 0x00000000>;

In the current common implementation, all ranges entries are programmed to
the iATU. However, the size of entry for 64-bit address mapping exceeds the
maximum region size that a single iATU entry can support. As a result, an
error is reported during iATU programming, showing that the size of 64-bit
address entry exceeds the region limit.

In this SoC design, 64-bit addresses are hard-wired and can skip iATU
programming. Thus, the driver needs to recount the "ranges" entries whose
size fits within the 4GB platform limit.

There are four scenarios:
32-bits address, size < 4GB: program to iATU
64-bits address, size < 4GB: program to iATU
32-bits address, size > 4GB: assuming this condition does not exist
64-bits address, size > 4GB: skip case

We will recount how many outbound windows will be programmed to the iATU; 
this is why we need to adjust the number of entries programmed to the iATU.

> Your PCIe controller is synthesized with a certain number of {in,out}bound
> windows, and I assume that dw_pcie_iatu_detect() correctly detects the number
> of {in,out}bound windows, and initializes num_ob_windows/num_ib_windows
> accordingly.
> 
> So, is the problem that because of some errata, you cannot use all the
> {in,out}bound windows of the iATU?
>

Similar to the erratum, all inbound and outbound windows remain functional,
as long as each iATU entry complies with the 4 GB size constraint.

> Because it is hard to understand what kind of "hardware limit" that would
> cause your SoC to not be able to use all the available {in,out}bound windows.
> 
> Because it is simply a mapping in the iATU (internal Address Translation Unit).
> 
> In fact, in many cases, e.g. the NVMe EPF driver, then number of {in,out}bound
> windows is a major limiting factor of how many outstanding I/Os you can have,
> so usually, you really want to be able to use the maximum that the hardware
> supports.
> 
> 
> TL;DR: to modify this common code, I think your reasoning has to be more
> detailed.
> 

I will include additional explanations along with the application scenarios of
this SoC, and refactor the commit message.

> 
> 
> Kind regards,
> Niklas

Sincerely,
Randolph