Re: [PATCH 1/2] dt-bindings: interrupt-controller: introduce toshiba,tc9564-msigen.yaml

[Alex Elder <elder@riscstar.com>]

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 wirings
>>>> 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?
>>> And as shown here:
>>> https://lore.kernel.org/all/20261012152408.3729237-5-elder@riscstar.com/
>>>
>>> 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@kernel.org/
>>
>> 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.