linux-kernel - [PATCH v7 0/7] Add ASPEED PCIe Root Complex 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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SEYPR06MB513404EB419B7850159F3CC29D84A@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Wed, 7 Jan 2026 02:28:57 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Mikhail Rudenko <mike.rudenko@...il.com>
CC: Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>, Andrew
 Jeffery <andrew@...econstruct.com.au>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>, Manivannan
 Sadhasivam <mani@...nel.org>, Linus Walleij <linus.walleij@...aro.org>,
	Philipp Zabel <p.zabel@...gutronix.de>, Neil Armstrong
	<neil.armstrong@...aro.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "linux-phy@...ts.infradead.org"
	<linux-phy@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Andrew Jeffery <andrew@...id.au>,
	"openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: [PATCH v7 0/7] Add ASPEED PCIe Root Complex support

Hi Mikhail Rudenko,

> First of all, thank you for your efforts in getting this driver upstreamed! I am
> trying to understand whether this driver supports PCIe devices that have an I/O
> port BAR, where CPU access to I/O ports is required for proper device
> operation.
> 
> If I understand correctly, this line in the Aspeed 2600 dtsi file declares the I/O
> port range:
> 
>     ranges = <0x01000000 0x0 0x00018000 0x00018000 0x0 0x00008000
> 
> During system initialization, the pci_remap_iospace() function in
> arch/arm/mm/ioremap.c maps the physical address range
> 0x00018000-0x00020000 to the virtual address PCI_IO_VIRT_BASE
> (0xfee00000). After this mapping, inb() and outb() calls work by converting I/O
> port addresses to virtual addresses starting at PCI_IO_VIRT_BASE, then
> performing reads and writes to those virtual addresses.
> 
> What I don't understand is this: according to the Aspeed 2600 datasheet, the
> address range 0x00000000-0x0fffffff (which contains
> 0x00018000-0x00020000) is mapped to Firmware SPI Memory. This would
> mean that outb() operations get routed to memory-mapped SPI flash instead of
> PCIe.
> 
> It seems like there's a missing piece to this puzzle. Could you help clarify how
> this is supposed to work?
>

Thank you for pointing this out, and sorry for the confusion.

You are correct that, as things stand, this does not make sense from a real hardware perspective.

In fact, the I/O addressing support you noticed was something we experimented with internally
only. There is no actual hardware design on AST2600 that supports PCIe I/O port addressing in 
this way. To enable those experiments, we modified our internal kernel accordingly, but this was 
never intended to represent real, supported hardware behavior.

This is our mistake for leaving this description in the DTS, as it can indeed be misleading. We 
will remove this part to avoid further confusion.

Thank you again for your careful review and for bringing this to our attention.

Thanks,
Jacky