Document the device tree bindings for the USB PHY interfaces integrated
with the DWC3 controller on Google Tensor SoCs, starting with G5
generation. The USB PHY on Tensor G5 includes two integrated Synopsys
PHY IPs: the eUSB 2.0 PHY IP and the USB 3.2/DisplayPort combo PHY IP.
Due to a complete architectural overhaul in the Google Tensor G5, the
existing Samsung/Exynos USB PHY binding for older generations of Google
silicons such as gs101 are no longer compatible, necessitating this new
device tree binding.
Signed-off-by: Roy Luo <royluo@google.com>
---
.../bindings/phy/google,gs5-usb-phy.yaml | 88 +++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/google,gs5-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/google,gs5-usb-phy.yaml b/Documentation/devicetree/bindings/phy/google,gs5-usb-phy.yaml
new file mode 100644
index 000000000000..a40de31ac768
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/google,gs5-usb-phy.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2025, Google LLC
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/google,gs5-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor Series (G5+) USB PHY
+
+maintainers:
+ - Roy Luo <royluo@google.com>
+
+description: |
+ Describes the USB PHY interfaces integrated with the DWC3 USB controller on
+ Google Tensor SoCs, starting with the G5 generation.
+ Two specific PHY IPs from Synopsys are integrated, including eUSB 2.0 PHY IP
+ and USB 3.2/DisplayPort combo PHY IP.
+ The hardware can support three PHY interfaces, which are selected using the
+ first phandle argument in the PHY specifier::
+ 0 - USB high-speed.
+ 1 - USB super-speed.
+ 2 - DisplayPort
+
+properties:
+ compatible:
+ const: google,gs5-usb-phy
+
+ reg:
+ items:
+ - description: USB2 PHY configuration registers.
+ - description: DisplayPort top-level registers.
+ - description: USB top-level configuration registers.
+
+ reg-names:
+ items:
+ - const: u2phy_cfg
+ - const: dp_top
+ - const: usb_top_cfg
+
+ "#phy-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ orientation-switch:
+ type: boolean
+ description:
+ Indicates the PHY as a handler of USB Type-C orientation changes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#phy-cells"
+ - clocks
+ - resets
+ - power-domains
+ - orientation-switch
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb_phy: usb_phy@c410000 {
+ compatible = "google,gs5-usb-phy";
+ reg = <0 0x0c450014 0 0xc>,
+ <0 0x0c637000 0 0xa0>,
+ <0 0x0c45002c 0 0x4>;
+ reg-names = "u2phy_cfg", "dp_top", "usb_top_cfg";
+ #phy-cells = <1>;
+ clocks = <&hsion_usb2_phy_reset_clk>;
+ resets = <&hsion_resets_usb2_phy>;
+ power-domains = <&hsio_n_usb_pd>;
+ orientation-switch;
+ };
+ };
+...
--
2.51.0.740.g6adb054d12-googOn 10/10/2025 22:16, Roy Luo wrote:
> + reg:
> + items:
> + - description: USB2 PHY configuration registers.
> + - description: DisplayPort top-level registers.
> + - description: USB top-level configuration registers.
> +
> + reg-names:
> + items:
> + - const: u2phy_cfg
> + - const: dp_top
> + - const: usb_top_cfg
> +
> + "#phy-cells":
> + const: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + orientation-switch:
> + type: boolean
> + description:
> + Indicates the PHY as a handler of USB Type-C orientation changes
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - "#phy-cells"
> + - clocks
> + - resets
> + - power-domains
> + - orientation-switch
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + usb_phy: usb_phy@c410000 {
> + compatible = "google,gs5-usb-phy";
> + reg = <0 0x0c450014 0 0xc>,
> + <0 0x0c637000 0 0xa0>,
You probably miss DP support and this does not belong here.
> + <0 0x0c45002c 0 0x4>;
That's not a separate address space. I really, really doubt that
hardware engineers came with address spaces of one word long.
> + reg-names = "u2phy_cfg", "dp_top", "usb_top_cfg";
> + #phy-cells = <1>;
> + clocks = <&hsion_usb2_phy_reset_clk>;
> + resets = <&hsion_resets_usb2_phy>;
> + power-domains = <&hsio_n_usb_pd>;
> + orientation-switch;
> + };
> + };
> +...
Best regards,
Krzysztof
On Fri, Oct 10, 2025 at 5:11 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 10/10/2025 22:16, Roy Luo wrote:
> > + reg:
> > + items:
> > + - description: USB2 PHY configuration registers.
> > + - description: DisplayPort top-level registers.
> > + - description: USB top-level configuration registers.
> > +
> > + reg-names:
> > + items:
> > + - const: u2phy_cfg
> > + - const: dp_top
> > + - const: usb_top_cfg
> > +
> > + "#phy-cells":
> > + const: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + orientation-switch:
> > + type: boolean
> > + description:
> > + Indicates the PHY as a handler of USB Type-C orientation changes
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - "#phy-cells"
> > + - clocks
> > + - resets
> > + - power-domains
> > + - orientation-switch
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + usb_phy: usb_phy@c410000 {
> > + compatible = "google,gs5-usb-phy";
> > + reg = <0 0x0c450014 0 0xc>,
> > + <0 0x0c637000 0 0xa0>,
>
> You probably miss DP support and this does not belong here.
This register space isn't solely for DP operation, a significant portion
manages the custom combo PHY. Consequently, this space is essential
even for USB-only operation. We can expect more registers in the space
to be utilized when DP support is added.
While I acknowledge the current name is confusing, it directly reflects
the hardware documentation. We can either adhere to the hardware
documentation's naming or propose a more descriptive alternative.
What's your preference?
>
> > + <0 0x0c45002c 0 0x4>;
>
> That's not a separate address space. I really, really doubt that
> hardware engineers came with address spaces of one word long.
I initially created this space to access the usb2only mode register,
which must be programmed when the controller operates in high-speed
only mode without the USB3 PHY initialized. Upon review, I now
believe the controller driver is the better location for this configuration,
as the register logically belongs there and the controller can tell
whether usb3 phy is going to be initialized.
That is, I'm removing this register space in the next patch.
Thanks,
Roy Luo
>
> > + reg-names = "u2phy_cfg", "dp_top", "usb_top_cfg";
> > + #phy-cells = <1>;
> > + clocks = <&hsion_usb2_phy_reset_clk>;
> > + resets = <&hsion_resets_usb2_phy>;
> > + power-domains = <&hsio_n_usb_pd>;
> > + orientation-switch;
> > + };
> > + };
> > +...
>
>
> Best regards,
> Krzysztof
On Mon, Oct 13, 2025 at 06:46:39PM -0700, Roy Luo wrote:
> On Fri, Oct 10, 2025 at 5:11 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On 10/10/2025 22:16, Roy Luo wrote:
> > > + reg:
> > > + items:
> > > + - description: USB2 PHY configuration registers.
> > > + - description: DisplayPort top-level registers.
> > > + - description: USB top-level configuration registers.
> > > +
> > > + reg-names:
> > > + items:
> > > + - const: u2phy_cfg
> > > + - const: dp_top
> > > + - const: usb_top_cfg
> > > +
> > > + "#phy-cells":
> > > + const: 1
> > > +
> > > + clocks:
> > > + maxItems: 1
> > > +
> > > + resets:
> > > + maxItems: 1
> > > +
> > > + power-domains:
> > > + maxItems: 1
> > > +
> > > + orientation-switch:
> > > + type: boolean
> > > + description:
> > > + Indicates the PHY as a handler of USB Type-C orientation changes
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - reg-names
> > > + - "#phy-cells"
> > > + - clocks
> > > + - resets
> > > + - power-domains
> > > + - orientation-switch
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + soc {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > +
> > > + usb_phy: usb_phy@c410000 {
> > > + compatible = "google,gs5-usb-phy";
> > > + reg = <0 0x0c450014 0 0xc>,
> > > + <0 0x0c637000 0 0xa0>,
> >
> > You probably miss DP support and this does not belong here.
>
> This register space isn't solely for DP operation, a significant portion
> manages the custom combo PHY. Consequently, this space is essential
> even for USB-only operation. We can expect more registers in the space
> to be utilized when DP support is added.
>
> While I acknowledge the current name is confusing, it directly reflects
> the hardware documentation. We can either adhere to the hardware
> documentation's naming or propose a more descriptive alternative.
> What's your preference?
>
> >
> > > + <0 0x0c45002c 0 0x4>;
> >
> > That's not a separate address space. I really, really doubt that
> > hardware engineers came with address spaces of one word long.
>
> I initially created this space to access the usb2only mode register,
> which must be programmed when the controller operates in high-speed
> only mode without the USB3 PHY initialized. Upon review, I now
> believe the controller driver is the better location for this configuration,
> as the register logically belongs there and the controller can tell
> whether usb3 phy is going to be initialized.
>
> That is, I'm removing this register space in the next patch.
You are missing the point. What exists from 0x0c450020-2c and
0x0c450000-0x14 for that matter? Hardware blocks don't just start on
unaligned boundaries like 0x14 or 0x2c. DT describes the h/w blocks, not
just nodes of what a driver needs. So if the 0x2c register needs to be
accessed by the USB driver, that's fine, but the register doesn't go in
the USB controller node 'reg'. A property with a phandle to the node
defining all the 0x0c450000 registers and an offset (if needed) is
typically what we do there. Or you can just find that node by
compatible.
Rob
On Wed, Oct 15, 2025 at 6:05 AM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Oct 13, 2025 at 06:46:39PM -0700, Roy Luo wrote:
> > On Fri, Oct 10, 2025 at 5:11 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > On 10/10/2025 22:16, Roy Luo wrote:
> > > > + reg:
> > > > + items:
> > > > + - description: USB2 PHY configuration registers.
> > > > + - description: DisplayPort top-level registers.
> > > > + - description: USB top-level configuration registers.
> > > > +
> > > > + reg-names:
> > > > + items:
> > > > + - const: u2phy_cfg
> > > > + - const: dp_top
> > > > + - const: usb_top_cfg
> > > > +
> > > > + "#phy-cells":
> > > > + const: 1
> > > > +
> > > > + clocks:
> > > > + maxItems: 1
> > > > +
> > > > + resets:
> > > > + maxItems: 1
> > > > +
> > > > + power-domains:
> > > > + maxItems: 1
> > > > +
> > > > + orientation-switch:
> > > > + type: boolean
> > > > + description:
> > > > + Indicates the PHY as a handler of USB Type-C orientation changes
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - reg-names
> > > > + - "#phy-cells"
> > > > + - clocks
> > > > + - resets
> > > > + - power-domains
> > > > + - orientation-switch
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + soc {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > +
> > > > + usb_phy: usb_phy@c410000 {
> > > > + compatible = "google,gs5-usb-phy";
> > > > + reg = <0 0x0c450014 0 0xc>,
> > > > + <0 0x0c637000 0 0xa0>,
> > >
> > > You probably miss DP support and this does not belong here.
> >
> > This register space isn't solely for DP operation, a significant portion
> > manages the custom combo PHY. Consequently, this space is essential
> > even for USB-only operation. We can expect more registers in the space
> > to be utilized when DP support is added.
> >
> > While I acknowledge the current name is confusing, it directly reflects
> > the hardware documentation. We can either adhere to the hardware
> > documentation's naming or propose a more descriptive alternative.
> > What's your preference?
> >
> > >
> > > > + <0 0x0c45002c 0 0x4>;
> > >
> > > That's not a separate address space. I really, really doubt that
> > > hardware engineers came with address spaces of one word long.
> >
> > I initially created this space to access the usb2only mode register,
> > which must be programmed when the controller operates in high-speed
> > only mode without the USB3 PHY initialized. Upon review, I now
> > believe the controller driver is the better location for this configuration,
> > as the register logically belongs there and the controller can tell
> > whether usb3 phy is going to be initialized.
> >
> > That is, I'm removing this register space in the next patch.
>
> You are missing the point. What exists from 0x0c450020-2c and
> 0x0c450000-0x14 for that matter? Hardware blocks don't just start on
> unaligned boundaries like 0x14 or 0x2c. DT describes the h/w blocks, not
Rob,
Thanks for chiming in. Let me elaborate the register layout here:
The register space 0x0c450000 - 0x00450043 is supposed to
be assigned to the USB controller. However, the USB phy has
to access a small portion of it, i.e. 0x0c450014 - 0x0c450020,
in order to initialize usb2 phy. This is really unfortunate and
makes things more complicated than it should've been.
The current patch is addressing it by splitting the register space:
- USB phy: <0 0x0c450014 0 0xc>
- USB controller: <0 0x0c450000 0 0x14>, <0 0x0c450020 0 0x23>
> just nodes of what a driver needs. So if the 0x2c register needs to be
> accessed by the USB driver, that's fine, but the register doesn't go in
> the USB controller node 'reg'. A property with a phandle to the node
> defining all the 0x0c450000 registers and an offset (if needed) is
> typically what we do there. Or you can just find that node by
> compatible.
Just to make sure we're on the same page, are you suggesting
making the register space a syscon node [1]? something like this:
usb_cfg_csr: usb_cfg_csr@c450000 {
compatible = "syscon";
reg = <0 0x0c450000 0x0 0x43>;
};
usb@c400000 {
...
usb-cfg-syscon = <&usb_cfg_csr>;
...
};
usb_phy@c637000 {
...
usb-cfg-syscon = <&usb_cfg_csr>;
...
}
[1] Documentation/devicetree/bindings/mfd/syscon.yaml
Thanks,
Roy Luo
>
> Rob
On Wed, Oct 15, 2025 at 11:57 AM Roy Luo <royluo@google.com> wrote:
>
> On Wed, Oct 15, 2025 at 6:05 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Mon, Oct 13, 2025 at 06:46:39PM -0700, Roy Luo wrote:
> > > On Fri, Oct 10, 2025 at 5:11 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > >
> > > > On 10/10/2025 22:16, Roy Luo wrote:
> > > > > + reg:
> > > > > + items:
> > > > > + - description: USB2 PHY configuration registers.
> > > > > + - description: DisplayPort top-level registers.
> > > > > + - description: USB top-level configuration registers.
> > > > > +
> > > > > + reg-names:
> > > > > + items:
> > > > > + - const: u2phy_cfg
> > > > > + - const: dp_top
> > > > > + - const: usb_top_cfg
> > > > > +
> > > > > + "#phy-cells":
> > > > > + const: 1
> > > > > +
> > > > > + clocks:
> > > > > + maxItems: 1
> > > > > +
> > > > > + resets:
> > > > > + maxItems: 1
> > > > > +
> > > > > + power-domains:
> > > > > + maxItems: 1
> > > > > +
> > > > > + orientation-switch:
> > > > > + type: boolean
> > > > > + description:
> > > > > + Indicates the PHY as a handler of USB Type-C orientation changes
> > > > > +
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - reg-names
> > > > > + - "#phy-cells"
> > > > > + - clocks
> > > > > + - resets
> > > > > + - power-domains
> > > > > + - orientation-switch
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + soc {
> > > > > + #address-cells = <2>;
> > > > > + #size-cells = <2>;
> > > > > +
> > > > > + usb_phy: usb_phy@c410000 {
> > > > > + compatible = "google,gs5-usb-phy";
> > > > > + reg = <0 0x0c450014 0 0xc>,
> > > > > + <0 0x0c637000 0 0xa0>,
> > > >
> > > > You probably miss DP support and this does not belong here.
> > >
> > > This register space isn't solely for DP operation, a significant portion
> > > manages the custom combo PHY. Consequently, this space is essential
> > > even for USB-only operation. We can expect more registers in the space
> > > to be utilized when DP support is added.
> > >
> > > While I acknowledge the current name is confusing, it directly reflects
> > > the hardware documentation. We can either adhere to the hardware
> > > documentation's naming or propose a more descriptive alternative.
> > > What's your preference?
> > >
> > > >
> > > > > + <0 0x0c45002c 0 0x4>;
> > > >
> > > > That's not a separate address space. I really, really doubt that
> > > > hardware engineers came with address spaces of one word long.
> > >
> > > I initially created this space to access the usb2only mode register,
> > > which must be programmed when the controller operates in high-speed
> > > only mode without the USB3 PHY initialized. Upon review, I now
> > > believe the controller driver is the better location for this configuration,
> > > as the register logically belongs there and the controller can tell
> > > whether usb3 phy is going to be initialized.
> > >
> > > That is, I'm removing this register space in the next patch.
> >
> > You are missing the point. What exists from 0x0c450020-2c and
> > 0x0c450000-0x14 for that matter? Hardware blocks don't just start on
> > unaligned boundaries like 0x14 or 0x2c. DT describes the h/w blocks, not
>
> Rob,
>
> Thanks for chiming in. Let me elaborate the register layout here:
> The register space 0x0c450000 - 0x00450043 is supposed to
> be assigned to the USB controller. However, the USB phy has
> to access a small portion of it, i.e. 0x0c450014 - 0x0c450020,
> in order to initialize usb2 phy. This is really unfortunate and
> makes things more complicated than it should've been.
>
> The current patch is addressing it by splitting the register space:
> - USB phy: <0 0x0c450014 0 0xc>
> - USB controller: <0 0x0c450000 0 0x14>, <0 0x0c450020 0 0x23>
>
> > just nodes of what a driver needs. So if the 0x2c register needs to be
> > accessed by the USB driver, that's fine, but the register doesn't go in
> > the USB controller node 'reg'. A property with a phandle to the node
> > defining all the 0x0c450000 registers and an offset (if needed) is
> > typically what we do there. Or you can just find that node by
> > compatible.
>
> Just to make sure we're on the same page, are you suggesting
> making the register space a syscon node [1]? something like this:
>
> usb_cfg_csr: usb_cfg_csr@c450000 {
> compatible = "syscon";
> reg = <0 0x0c450000 0x0 0x43>;
> };
>
> usb@c400000 {
> ...
> usb-cfg-syscon = <&usb_cfg_csr>;
> ...
> };
>
> usb_phy@c637000 {
> ...
> usb-cfg-syscon = <&usb_cfg_csr>;
> ...
> }
>
> [1] Documentation/devicetree/bindings/mfd/syscon.yaml
>
> Thanks,
> Roy Luo
>
Hi Rob,
I'm sending out a new version of the patchset.
Although this specific comment isn't fully resolved yet, I've integrated
enough new content and fixes into this and other patches that I believe
it's ready for another round of review.
I'm happy to continue the discussion on this specific point here or in
the new patchset. Here are the links to the new patches FYI:
- controller https://lore.kernel.org/linux-usb/20251017233459.2409975-1-royluo@google.com
- phy https://lore.kernel.org/linux-phy/20251017235159.2417576-1-royluo@google.com
Thanks,
Roy Luo
> >
> > Rob
© 2016 - 2025 Red Hat, Inc.