From: "André Draszik" <andre.draszik@linaro.org>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Peter Griffin <peter.griffin@linaro.org>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Juan Yescas <jyescas@google.com>,
Will McVicker <willmcvicker@google.com>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v4 01/10] dt-bindings: soc: google: add google,gs101-dtzpc
Date: Fri, 30 Jan 2026 05:40:13 +0000 [thread overview]
Message-ID: <74eb8fb542966c46d0a8c77041aeef21dd1a7e14.camel@linaro.org> (raw)
In-Reply-To: <20260129165531.GA1269692-robh@kernel.org>
Hi Rob,
On Thu, 2026-01-29 at 10:55 -0600, Rob Herring wrote:
> On Wed, Jan 28, 2026 at 04:10:50PM +0000, André Draszik wrote:
> > The Exynos Distributed TruztZone Protection Control (D_TZPC) provides
> > an interface to the protection bits that are included in the TrustZone
> > design in a secure system. It configures each area of the memory as
> > secure or non-secure.
>
> This sounds like what access-controllers binding is for. Does that work
> here?
Thank you for the pointer, and yes, I did consider it, but decided against
it in the end for the following reasons:
* downstream drivers don't actually do much with this, it's only used to
issue a request to the firmware to save / restore the configuration
when power domains are turned off / on (via SMC call). There is no
actual configuration happening unlike e.g. the drivers/bus/stm32_*
case. Configuration etc. seems to be handled statically in the firmware
in my case.
* therefore I didn't write an actual driver for this compatible and my
patches are proposing to simply issue the SMC from the power domain
driver in the respective paths.
What I observed without having a driver matching the compatible, Linux
will defer binding of consumer drivers (power domain via phandle in my
case) until the access controller driver has bound. Since no such driver
exists in my case, Linux keeps deferring the binding of my power domain
driver forever, meaning it doesn't probe.
Maybe this restriction could be loosened for cases like this instead. Or
maybe I do need to write a dtzpc driver with the only purpose to issue the
SMC calls at the right time. Having such a driver seemed like overkill,
though.
I realise not using access-controller in DT looks like working-around an
issue in the kernel, but due to the minimal interaction from the Linux-side
I was hoping for that to be OK.
What do you think?
Cheers,
Andre'
>
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > ---
> > .../bindings/soc/google/google,gs101-dtzpc.yaml | 42 ++++++++++++++++++++++
> > MAINTAINERS | 1 +
> > 2 files changed, 43 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-dtzpc.yaml
> > b/Documentation/devicetree/bindings/soc/google/google,gs101-dtzpc.yaml
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..a8c61ce069d6910c47753bf14a792eb58e6ae182
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/google/google,gs101-dtzpc.yaml
> > @@ -0,0 +1,42 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/soc/google/google,gs101-dtzpc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Samsung Exynos Distributed TruztZone Protection Control.
> > +
> > +description:
> > + Distributed TrustZone Protection Control (D_TZPC) provides an interface to the
> > + protection bits that are included in the TrustZone design in a secure system.
> > + It configures each area of the memory as secure or non-secure.
> > +
> > +maintainers:
> > + - André Draszik <andre.draszik@linaro.org>
> > +
> > +properties:
> > + compatible:
> > + const: google,gs101-dtzpc
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - clocks
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/google,gs101.h>
> > +
> > + dtzpc_hsi0: dtzpc@11010000 {
> > + compatible = "google,gs101-dtzpc";
> > + reg = <0x11010000 0x10000>;
> > + clocks = <&cmu_hsi0 CLK_GOUT_HSI0_D_TZPC_HSI0_PCLK>;
> > + };
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a56f8f00aebb938aa765a8a6d66dfeb7f062dac8..98b2ef47c809ac0232e6941c9483b19d7c798bb4 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10833,6 +10833,7 @@ P: Documentation/process/maintainer-soc-clean-dts.rst
> > C: irc://irc.oftc.net/pixel6-kernel-dev
> > F: Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> > F: Documentation/devicetree/bindings/phy/google,lga-usb-phy.yaml
> > +F: Documentation/devicetree/bindings/soc/google/google,gs101-dtzpc.yaml
> > F: Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
> > F: Documentation/devicetree/bindings/usb/google,lga-dwc3.yaml
> > F: arch/arm64/boot/dts/exynos/google/
> >
> > --
> > 2.52.0.457.g6b5491de43-goog
> >
next prev parent reply other threads:[~2026-01-30 5:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 16:10 [PATCH v4 00/10] pmdomain: samsung: add support for Google GS101 André Draszik
2026-01-28 16:10 ` [PATCH v4 01/10] dt-bindings: soc: google: add google,gs101-dtzpc André Draszik
2026-01-29 16:55 ` Rob Herring
2026-01-30 5:40 ` André Draszik [this message]
2026-01-28 16:10 ` [PATCH v4 02/10] dt-bindings: power: samsung: add google,gs101-pd André Draszik
2026-01-28 16:10 ` [PATCH v4 03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding André Draszik
2026-01-28 16:10 ` [PATCH v4 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children André Draszik
2026-01-28 16:10 ` [PATCH v4 05/10] pmdomain: samsung: convert to using regmap André Draszik
2026-01-28 16:10 ` [PATCH v4 06/10] pmdomain: samsung: don't hard-code offset for registers to 0 and 4 André Draszik
2026-01-28 16:10 ` [PATCH v4 07/10] pmdomain: samsung: add support for google,gs101-pd André Draszik
2026-01-28 16:10 ` [PATCH v4 08/10] pmdomain: samsung: use dev_err() instead of pr_err() André Draszik
2026-01-28 16:10 ` [PATCH v4 09/10] pmdomain: samsung: implement SMC to save / restore TZ config André Draszik
2026-01-28 16:10 ` [PATCH v4 10/10] pmdomain: samsung: implement domain-supply regulator André Draszik
2026-01-29 7:53 ` André Draszik
2026-01-28 18:53 ` [PATCH v4 00/10] pmdomain: samsung: add support for Google GS101 Krzysztof Kozlowski
2026-02-05 12:05 ` Ulf Hansson
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=74eb8fb542966c46d0a8c77041aeef21dd1a7e14.camel@linaro.org \
--to=andre.draszik@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jyescas@google.com \
--cc=kernel-team@android.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=ulf.hansson@linaro.org \
--cc=willmcvicker@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).