From: Mikhail Rudenko <mike.rudenko@gmail.com>
To: Jacky Chou <jacky_chou@aspeedtech.com>
Cc: "Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Joel Stanley" <joel@jms.id.au>,
"Andrew Jeffery" <andrew@codeconstruct.com.au>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
linux-aspeed@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, "Andrew Jeffery" <andrew@aj.id.au>,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
"Mikhail Rudenko" <mike.rudenko@gmail.com>
Subject: Re: [PATCH v7 0/7] Add ASPEED PCIe Root Complex support
Date: Tue, 06 Jan 2026 12:58:40 +0300 [thread overview]
Message-ID: <875x9fuj7i.fsf@gmail.com> (raw)
In-Reply-To: <20251216-upstream_pcie_rc-v7-0-4aeb0f53c4ce@aspeedtech.com>
Hi Jacky,
On 2025-12-16 at 09:49 +08, Jacky Chou <jacky_chou@aspeedtech.com> wrote:
> This patch series adds support for the ASPEED PCIe Root Complex,
> including device tree bindings, pinctrl support, and the PCIe host controller
> driver. The patches introduce the necessary device tree nodes, pinmux groups,
> and driver implementation to enable PCIe functionality on ASPEED platforms.
> Currently, the ASPEED PCIe Root Complex only supports a single port.
>
> Summary of changes:
> - Add device tree binding documents for ASPEED PCIe PHY and PCIe RC
> - Update MAINTAINERS for new bindings and driver
> - Implement ASPEED PCIe PHY driver
> - Implement ASPEED PCIe Root Complex host controller driver
>
> This series has been tested on AST2600/AST2700 platforms and enables PCIe device
> enumeration and operation.
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?
--
Kind regards,
Mikhail Rudenko
WARNING: multiple messages have this Message-ID (diff)
From: Mikhail Rudenko <mike.rudenko@gmail.com>
To: Jacky Chou <jacky_chou@aspeedtech.com>
Cc: "Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Joel Stanley" <joel@jms.id.au>,
"Andrew Jeffery" <andrew@codeconstruct.com.au>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
linux-aspeed@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, "Andrew Jeffery" <andrew@aj.id.au>,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
"Mikhail Rudenko" <mike.rudenko@gmail.com>
Subject: Re: [PATCH v7 0/7] Add ASPEED PCIe Root Complex support
Date: Tue, 06 Jan 2026 12:58:40 +0300 [thread overview]
Message-ID: <875x9fuj7i.fsf@gmail.com> (raw)
In-Reply-To: <20251216-upstream_pcie_rc-v7-0-4aeb0f53c4ce@aspeedtech.com>
Hi Jacky,
On 2025-12-16 at 09:49 +08, Jacky Chou <jacky_chou@aspeedtech.com> wrote:
> This patch series adds support for the ASPEED PCIe Root Complex,
> including device tree bindings, pinctrl support, and the PCIe host controller
> driver. The patches introduce the necessary device tree nodes, pinmux groups,
> and driver implementation to enable PCIe functionality on ASPEED platforms.
> Currently, the ASPEED PCIe Root Complex only supports a single port.
>
> Summary of changes:
> - Add device tree binding documents for ASPEED PCIe PHY and PCIe RC
> - Update MAINTAINERS for new bindings and driver
> - Implement ASPEED PCIe PHY driver
> - Implement ASPEED PCIe Root Complex host controller driver
>
> This series has been tested on AST2600/AST2700 platforms and enables PCIe device
> enumeration and operation.
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?
--
Kind regards,
Mikhail Rudenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-01-06 22:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 1:49 [PATCH v7 0/7] Add ASPEED PCIe Root Complex support Jacky Chou
2025-12-16 1:49 ` Jacky Chou
2025-12-16 1:50 ` [PATCH v7 1/7] dt-bindings: phy: aspeed: Add ASPEED PCIe PHY Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-16 1:50 ` [PATCH v7 2/7] dt-bindings: PCI: Add ASPEED PCIe RC support Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-17 14:07 ` Rob Herring (Arm)
2025-12-17 14:07 ` Rob Herring (Arm)
2025-12-16 1:50 ` [PATCH v7 3/7] ARM: dts: aspeed-g6: Add PCIe RC and PCIe PHY node Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-16 1:50 ` [PATCH v7 4/7] PHY: aspeed: Add ASPEED PCIe PHY driver Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-23 15:38 ` Vinod Koul
2025-12-23 15:38 ` Vinod Koul
2025-12-24 5:32 ` Jacky Chou
2025-12-24 5:32 ` Jacky Chou
2025-12-16 1:50 ` [PATCH v7 5/7] PCI: Add FMT, TYPE and CPL status definition for TLP header Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-16 1:50 ` [PATCH v7 6/7] PCI: aspeed: Add ASPEED PCIe RC driver Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-16 1:50 ` [PATCH v7 7/7] MAINTAINERS: " Jacky Chou
2025-12-16 1:50 ` Jacky Chou
2025-12-23 15:59 ` Manivannan Sadhasivam
2025-12-23 15:59 ` Manivannan Sadhasivam
2025-12-23 15:58 ` (subset) [PATCH v7 0/7] Add ASPEED PCIe Root Complex support Manivannan Sadhasivam
2025-12-23 15:58 ` Manivannan Sadhasivam
2026-01-06 9:58 ` Mikhail Rudenko [this message]
2026-01-06 9:58 ` Mikhail Rudenko
2026-01-07 2:28 ` Jacky Chou
2026-01-07 2:28 ` Jacky Chou
2026-01-07 13:40 ` Mikhail Rudenko
2026-01-07 13:40 ` Mikhail Rudenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875x9fuj7i.fsf@gmail.com \
--to=mike.rudenko@gmail.com \
--cc=andrew@aj.id.au \
--cc=andrew@codeconstruct.com.au \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jacky_chou@aspeedtech.com \
--cc=joel@jms.id.au \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=openbmc@lists.ozlabs.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.