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

[Daniel Thompson <daniel@riscstar.com>]

On Mon, Oct 19, 2026 at 08:49:40PM +0100, Conor Dooley wrote:
> 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.

FWIW I'm believe you *could* build a standalone system using the
Cortex-M3. It has direct access to all the peripherals that we are
describing using devicetree. However the C-M3 has very little RAM
so the list of plausible fully-standalone systems is very short!

More likely would be a system design that gives the microcontroller
ownership of just a few of the peripherals and is partially
independent of the host. If that firmware was running a DT-centric OS
such as Zephyr there might be binding reuse in that case.

I should be clear that this is entirely speculative at this point. We
don't have such a firmware (we currently don't use any firmware at all).


Daniel.