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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3666 bytes --]

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.

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?

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]