All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Alex Elder <elder@riscstar.com>
Cc: sboyd@kernel.org, bmasney+clk@redhat.com,
	jbrunet+clk@baylibre.com, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, lee@kernel.org, andersson@kernel.org,
	konradybcio@kernel.org, abelvesa@kernel.org, kees@kernel.org,
	gustavoars@kernel.org, p.zabel@pengutronix.de,
	daniel@riscstar.com, mohd.anwar@oss.qualcomm.com,
	lorenzo.bianconi@oss.qualcomm.com, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, mfd@lists.linux.dev,
	linux-arm-msm@vger.kernel.org, linux-hardening@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] dt-bindings: mfd: introduce the TC9564 config syscon
Date: Wed, 23 Sep 2026 09:25:34 +0200	[thread overview]
Message-ID: <fbeac5ba-a28d-4d34-8d23-4946aef515ea@kernel.org> (raw)
In-Reply-To: <7e32063f-f1a4-4259-96c9-fcbdd25c7f2f@riscstar.com>

On 22/09/2026 23:02, Alex Elder wrote:
> On 9/21/26 4:46 PM, Alex Elder wrote:
>>> I also have doubts that this is needed - I see no updates to the misc
>>> binding, which would be referencing it. But then another point would be,
>>> that you do not need separate child node, which has no properties.
> 
> Krzysztof, I've done some additional work on this based on
> your feedback.
> 
> I think you are correct that there is no need to define
> this as a special syscon with its own compatible string.
> 
> Instead, I can simply define a simple syscon with a label:
> 
>          tc9564_config_syscon0: syscon@0 {
>                  compatible = "syscon";

I never proposed anything like that. I asked to drop simple-mfd.

>                  reg = <0x0 0x2000>;
>          };
> 
> And then have the devices that need to use it, refer to
> its label using a phandle:
> 
>          tc9564_clock0: clock@1004 {
>                  compatible = "toshiba,tc9564-clock";
>                  toshiba,config-syscon = <&tc9564_config_syscon0>;
>                  #clock-cells = <1>;
>                  #reset-cells = <1>;
>          };
> 
>          tc9564_emac0: ethernet@40000 {
>                  compatible = "toshiba,tc9564-xgmac";
>                  reg = <0x40000 0x8000>;
>                  toshiba,config-syscon = <&tc9564_config_syscon0 0x1070>;
> 		. . .
> 	};
> 
>          tc9564_emac1: ethernet@48000 {
>                  compatible = "toshiba,tc9564-xgmac";
>                  reg = <0x48000 0x8000>;
>                  toshiba,config-syscon = <&tc9564_config_syscon0 0x1074>;
> 		. . .
> 	};
> 
> That simplifies things a bit, and requires no devicetree binding.
> 
> If you think this is incorrect, please let me know, otherwise it
> is the direction I plan to go with the next version of this
> series.
> 

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.

Best regards,
Krzysztof

  reply	other threads:[~2026-09-23  7:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 16:52 [PATCH 0/4] clk: introduce TC9564 clock and reset Alex Elder
2026-09-18 16:52 ` [PATCH 1/4] dt-bindings: mfd: introduce the TC9564 config syscon Alex Elder
2026-09-20 18:18   ` Krzysztof Kozlowski
2026-09-21 21:46     ` Alex Elder
2026-09-22 21:02       ` Alex Elder
2026-09-23  7:25         ` Krzysztof Kozlowski [this message]
2026-09-28 14:52           ` Alex Elder
2026-09-18 16:52 ` [PATCH 2/4] dt-bindings: clock: introduce toshiba,tc9564-clock.yaml Alex Elder
2026-09-20 18:21   ` Krzysztof Kozlowski
2026-09-21 21:46     ` Alex Elder
2026-09-22 13:13     ` Alex Elder
2026-09-23  7:18       ` Krzysztof Kozlowski
2026-09-18 16:52 ` [PATCH 3/4] clk: toshiba: introduce a TC9564 SoC clock and reset driver Alex Elder
2026-09-20 19:39   ` Uwe Kleine-König
2026-09-22 12:37     ` Alex Elder
2026-09-22 12:53       ` Uwe Kleine-König
2026-09-21 22:59   ` Brian Masney
2026-09-22 13:33     ` Alex Elder
2026-09-23 20:58       ` Jerome Brunet
2026-09-23 21:33         ` Alex Elder
2026-09-24  7:29           ` Jerome Brunet
2026-09-24 19:22       ` Brian Masney
2026-09-18 16:52 ` [PATCH 4/4] arm64: dts: qcom: qcs6490-rb3gen2: add the clock controller Alex Elder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fbeac5ba-a28d-4d34-8d23-4946aef515ea@kernel.org \
    --to=krzk@kernel.org \
    --cc=abelvesa@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bmasney+clk@redhat.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@riscstar.com \
    --cc=devicetree@vger.kernel.org \
    --cc=elder@riscstar.com \
    --cc=gustavoars@kernel.org \
    --cc=jbrunet+clk@baylibre.com \
    --cc=kees@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.bianconi@oss.qualcomm.com \
    --cc=mfd@lists.linux.dev \
    --cc=mohd.anwar@oss.qualcomm.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.