Re: [PATCH 0/4] soc: toshiba: tc9564: config system controller

[Krzysztof Kozlowski]

On 09/11/2026 18:42, Alex Elder wrote:
> On 11/5/26 2:26 PM, Krzysztof Kozlowski wrote:
>> On 04/11/2026 01:43, Alex Elder wrote:
>>> This series is comprised of some code that was previously sent
>>> separately.  It now incorporates a new system controller driver
>>> that advertises clock and reset functionality, as well as regmap
>>> access to its address range.  This combination is being treated
>>> as a new series.  (Details of previous versions are below.)
>>>
>>> The Toshiba TC9564 is an SoC that attaches to a host system via PCIe.
>>> It includes a PCIe switch with three downstream ports.  To one of
>>> these ports an embedded PCIe endpoint is attached, and that implements
>>> two PCI functions.  BAR 4 for both PCI functions provides access to
>>> registers controlling blocks within the SoC.
>>>
>>> The system controller driver adds the clock and reset devices
>>> using the mfd_add_devices() interface.  The clocks and resets
>>> are implemented by drivers included in this series.
>>
>> Toshiba TC9564 bindings and DTS should be posted completely. We spent
>> great amount of time on discussing already and I pointed more than once
>> that big picture is missing.
> 
> https://github.com/riscstar/linux/blob/tc9564-dts/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> 
> Node pcie@3,0 is the third switch port (within the TC9564), which
> has an embedded PCIe endpoint with two functions.  (You can ignore
> pci-ep-bus@0 for now.)
> 
>> You are not describing here parts of a SoC.
>>
>> You are describing one, single device how the host sees it and DT
>> maintainers (and writing bindings) ask for complete picture in such cases.
> 
> I'm glad to provide whatever information you need.  There is more
> than one way to provide the "complete picture" however, and I don't
> want to send something that isn't helpful.
> 
> If you want something different from just the DTS file linked above,
> please say so and I'll put something together.

The DTS was enough and it shows that you described internals of the
device. I keep my claim, that is not correct representation because it
is too detailed and too complicated.

Nothing related to the syscon should be represented in DT, because these
are internal registers handled by the device itself. DT does not
describe internals of the devices, but how the device is being
represented for the host.

And Rob Herring already expressed that, if I understand correctly:
https://lore.kernel.org/lkml/20260605144032.GA3659201-robh@xxxxxxxxxx/

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

You don't get multiple syscons and other internal routing elements.

Best regards,
Krzysztof