Re: [PATCH 1/4] dt-bindings: mfd: introduce the TC9564 config syscon

[Krzysztof Kozlowski <krzk@kernel.org>]

On 28/09/2026 16:52, Alex Elder wrote:
> On 9/23/26 2:25 AM, Krzysztof Kozlowski wrote:
>> I think nothing behind PCI EP should be described in DT, because
>> everything is internal to the device and implied by compatible (or
>> vid/pid). We do describe internals of devices in DT usually for complex
>> devices (like some display blocks with multiple subblocks) or when they
>> are used outside of that device. That's why I asked how are all these
>> clocks and resets exposed to the host. If the syscon is used only by the
>> device itself, I don't quite get the benefits of describing it in DT.
> 
> You say you think "nothing behind PCI EP should be described in DT".
> However the mere existence of the PCI endpoint bus as an option
> contradicts that statement, by providing a means of doing *exactly*
> that:  using devicetree to describe things behind a PCI endpoint.
> This is the model we are using.

No, the existence does not contradict. We allow further description as
long as things are not autodiscoverable and are necessary for the host
to deal with the device, like power sequencing. Same we did for
"onboard" USB hubs.

You are however describing internals of the device like syscon, which is
way beyond what is necessary for the host to instantiate that device.

> 
> In June we switched over to using the pci-ep-bus model based on a
> suggestion from Rob Herring (and Mani Sadhasivam).  Rob felt our
> previous auxiliary device approach wasn't right for the peripherals
> found within the SoC, given we were accessing them via PCI BARs.
>    https://lore.kernel.org/lkml/20260605144032.GA3659201-robh@kernel.org/

Oh, that's good, so let's quote:

"The ethernet nodes should be just these PCI function nodes."

"And really, a DT node for them should be completely optional (unless
there's some power on ctrl needed)."

"Everything else like SPI, GPIO, UART, etc. should be under the PCIe
switch upstream node in a pci-ep-bus."
Sure, but you add syscon. That's completely internal stuff.

> We found that using pci-ep-bus provided a very natural and familiar
> way of representing the organization of the TC9564 SoC, and used
> it to represent all of the peripherals (including XGMAC).  It
> nicely partitions the hardware design, as well as providing a
> well-understood connection with the software.
> 
> The switch involved quite a bit of work, and the result is a set
> of basically independent platform drivers that are modular and
> easily reviewed.  I really would rather not go back to to what
> we had before.
> 
> Do you have criteria for what in a chip/SoC is sufficiently
> "complex" to warrant allowing devicetree to describe some of
> its internal details?

For me criteria are the resources from the host. I think I said it
already, we do not describe internals of I2C or SPI devices: their
internal clocks, internal power supplies. We only describe the inputs
from the host. You can map it into the pins.

Same here, IMO.

> 
> I believe the TC9564 *is* such a "complex" SoC.  And in any case,
> anywhere pci-ep-bus is used, it implies that some chip internals
> would be described using devicetree.
> 
> Would incorporating the chip internals in a devicetree *overlay*
> have any effect on your opinion on this?  I.e., the "main"
> devicetree nodes would simply define the PCI device hierarchy,
> but anything behind an endpoint would be described in an overlay.
> This way, pci-ep-bus on a PCI endpoint just provides an external
> interface onto which a very complex device could be "mounted"
> (and described in an overlay).
> 
> I'd like to continue to move ahead with upstreaming support for
> this SoC, but to me it seems you have basic doubts about
> pci-ep-bus and I'd like to get past that.

Well, Rob might understand this better, so maybe review from him will
solve these questions.

Best regards,
Krzysztof