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

[Conor Dooley <conor@kernel.org>]

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

On Wed, Oct 14, 2026 at 11:57:08AM -0500, Alex Elder wrote:
> 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.

If that's it, I wouldn't really call this an SoC, you're just going to
confuse people (like me!) into thinking that this device can work
standalone...

> It does, in fact, have an embedded CPU that uses SRAM, but
> it's just an Arm Cortex M3 and is not Linux capable.

...but maybe it can, depending on whether the devices being discussed
appear in the address space of the M3 or if the M3 is just some sort of
monitor CPU running firmware and bringing the device out of reset.

> 
> So no, it is not a Linux-capable SoC the way the LAN966x is.

IIRC the LAN966x didn't expose the various peripherals as different
discoverable PCI functions and was just like "hey, we're a LAN966x".
What made it special was that there was already drivers etc for this
device from being an SoC, so the DT overlay solution neatly made use of
the existing stuff for the device.

If your device only exposes a single function for the whole device, I
feel like aping the LAN966x and describing it in DT via an overlay is
reasonable.

Cheers,
Conor.

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