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

[Alex Elder <elder@riscstar.com>]

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.


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.

					-Alex