Re: [PATCH 1/2] dt-bindings: interrupt-controller: introduce toshiba,tc9564-msigen.yaml
From: Alex Elder
Date: Wed Oct 14 2026 - 12:57:22 EST
On 10/14/26 11:41 AM, Conor Dooley wrote:
On Wed, Oct 14, 2026 at 09:55:03AM -0500, Alex Elder wrote:
On 10/14/26 5:22 AM, Krzysztof Kozlowski wrote:
I still do not understand why do we need to describe the inner wiringsAnd as shown here:
of the tc9564 device. So far I found no posting of DTS showing proper
usage of it on the host. Without proper usage, what is the point exactly
to describe the inner specifics of tc9564?
https://lore.kernel.org/all/20261012152408.3729237-5-elder@xxxxxxxxxxxx/
there is no single user of any of this (this=reset, clock, irqchip
probably and more) in upstreamed patches.
I am getting tired to keep discussing it, so next time instead of words,
please post CODE which is the argument - who uses any of these devices
you keep adding.
I'll take a break from my in-order responses to messages, and will
respond to this first.
Not really replying to any of this, but figured it was worth
mentioning that I am reviewing with the assumption that it's similar
to the microchip lan9xxx devices that can either be a standalone SoC
or connected as PCI endpoint.
Yes, that was one of two things that this was modeled upon.
The other is the Raspberry Pi RP1, which is probably a more
similar example.
You keep calling it an SoC, which I took to mean that this had
linux-capable CPU cores on it. Is that not actually the case?
Well it is an SoC, in that it has numerous interacting
components that are aggregated into a single chip.
It does, in fact, have an embedded CPU that uses SRAM, but
it's just an Arm Cortex M3 and is not Linux capable.
So no, it is not a Linux-capable SoC the way the LAN966x is.
-Alex
Our ultimate goal is to support the two DWMAC interfaces attached
to PCIe functions within the TC9564. This is a complex SoC which
interfaces with the host via an upstream PCIe switch port, and
incorporates an embedded PCIe endpoint with two functions.
Based on your request, I will plan to send *all* of the code that's
required for DWMAC support for review later today and tomorrow. I
have been pacing myself (in part not to inundate the lists with
patches).
A block diagram representing the TC9564 SoC is included in this
devicetree binding:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=ed0a1c1eaa376e11cf8c97d898f2811b8ded322f
That explains (and attempts to show) that devices (including clock
and reset functionality) use PCI endpoint BARs for access to their
registers. Other IP blocks shown are an address translation unit,
a block of SRAM, two XGMAC interfaces, and an MSI generator for
each of the two embedded PCI functions.
To show the final DTS file, I have squashed the working code I have
and refer you here, starting at line 994:
https://github.com/riscstar/linux/blob/18d7146c807a6264388c919391b77a795612e342/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts#L994
Note that this exposes many internal details of the SoC, which
Krzysztof objected to here:
https://lore.kernel.org/lkml/fbeac5ba-a28d-4d34-8d23-4946aef515ea@xxxxxxxxxx/
I responded, explaining some history on this code and asking
for clarification on criteria for when it's acceptable to
describe chip internals in devicetree, but received no answer.
The PCI endpoint bus enables a PCI endpoint to be treated as
a *bus* that provides access to multiple peripherals, rather
than as a simple single-peripheral device. This goes well
beyond the capability of the PCI enumeration process to
discover the nature of the hardware, leveraging devicetree as
a hardware description language to describe the organization
within a complex chip.
I understand the desire to consider the PCI endpoint (function)
as the boundary for devicetree descriptions. But I also see
great benefit from viewing the SoC as a subsystem in itself,
whose IP blocks and connections between them are described
using devicetree.