Linux-MIPS Archive mirror
 help / color / mirror / Atom feed
From: Caleb James DeLisle <cjd@cjdns.fr>
To: Rob Herring <robh@kernel.org>
Cc: linux-mips@vger.kernel.org, vkoul@kernel.org,
	neil.armstrong@linaro.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: phy: econet: Document EN751221 USB PHY
Date: Tue, 2 Jun 2026 14:40:01 +0200	[thread overview]
Message-ID: <373aaeff-ca95-4e45-8e1a-ce7e79e91f42@cjdns.fr> (raw)
In-Reply-To: <20260601225805.GA129257-robh@kernel.org>


On 02/06/2026 00:58, Rob Herring wrote:
> On Mon, May 18, 2026 at 02:13:42PM +0000, Caleb James DeLisle wrote:
>> Document the USB PHY devices which appear in EcoNet EN751221, EN751627,
>> and EN7528 based SoCs.
>>
>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
>> ---
>>   .../bindings/phy/econet,en751221-usb-phy.yaml | 128 ++++++++++++++++++
>>   MAINTAINERS                                   |   6 +
>>   2 files changed, 134 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/phy/econet,en751221-usb-phy.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/phy/econet,en751221-usb-phy.yaml b/Documentation/devicetree/bindings/phy/econet,en751221-usb-phy.yaml
>> new file mode 100644
>> index 000000000000..a44f59601747
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/econet,en751221-usb-phy.yaml
>> @@ -0,0 +1,128 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +# Copyright (C) 2024 EcoNet
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/econet,en751221-usb-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: EcoNet EN751221 USB PHY
>> +
>> +maintainers:
>> +  - Caleb James DeLisle <cjd@cjdns.fr>
>> +
>> +description: |
> Don't need '|' unless there is formatting to preserve.
>
>> +  USB PHY controller found on EcoNet EN751221 SoCs as well as on EN751627 and
>> +  EN7528. These devices generally have two ports, one of which is a USB 3.0,
>> +  and the other is USB 2.0. The USB 3.0 port is driven by one of two PHY
>> +  blocks, depending on whether the connected device has negotiated USB 3.0 or
>> +  2.0. These PHYs are also used on other EcoNet silicon in varying
>> +  configurations, such as only port 0 (the USB 3.0 port), or only port 1 (the
>> +  USB 2.0 port).
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - econet,en751221-usb-phy
>> +      - econet,en751627-usb-phy
>> +      - econet,en7528-usb-phy
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#address-cells": true
>> +  "#size-cells": true
>> +  ranges: true
>> +
>> +  clocks:
>> +    maxItems: 1
>> +    description: |
>> +      Crystal oscillator clock source. EcoNet devices run at either 20Mhz or
>> +      25Mhz. 25Mhz devices require additional tuning in the USB 3.0 PHY.
>> +
>> +  clock-names:
>> +    items:
>> +      - const: xtal
>> +
>> +patternProperties:
>> +  "^usb-phy@[0-9a-f]+$":
>> +    type: object
>> +    description: USB 2.0 or 3.0 PHY sub-node.
>> +
>> +    properties:
>> +      compatible:
>> +        enum:
>> +          - econet,usb2-phy
>> +          - econet,usb3-phy
>> +
>> +      reg:
>> +        maxItems: 1
>> +
>> +      resets:
>> +        maxItems: 1
>> +
>> +      econet,usb-port-id:
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        enum: [0, 1]
>> +        description: |
>> +          Physical port number. Since USB 3.0 requires a second PHY for the 2.0
>> +          fallback, multiple PHYs can map to the same physical port.
> What is special about this platform needing this property.

For measuring the frequency to set the slew rate, we need to know which 
port we're working with. Also the hardware revision has to be set 
differently on port 1 than port 0.

> Lots of
> platforms have 2 phys for USB 2.0 and 3.0 yet don't need a property
> like this.
I copied the idea from google,extcon-usbc-cros-ec which uses 
google,usb-port-id.
> Can't you figure out which phys are the same USB port by the
> USB controller 'phys' property which would define that?

Unfortunately the Mediatek driver handles all of the ports and only uses 
one DT node. I suppose I could encode the information in the compatible 
of the subnode, something like:


usb-phy@1fa80000 {
       compatible = "econet,en751221-usb-phy";

       ...

       usb-phy@1fa80800 {
           compatible = "econet,usb2-port0-phy";
           ...
       };
       ...
};

I'm not really sure which way is more correct. If you have an opinion on this, let me know.

Thanks,
Caleb

>
> Rob
>

  reply	other threads:[~2026-06-02 12:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 14:13 [PATCH 0/2] Add support for EcoNet USB PHY Caleb James DeLisle
2026-05-18 14:13 ` [PATCH 1/2] dt-bindings: phy: econet: Document EN751221 " Caleb James DeLisle
2026-06-01 22:58   ` Rob Herring
2026-06-02 12:40     ` Caleb James DeLisle [this message]
2026-05-18 14:13 ` [PATCH 2/2] phy: econet: Add EcoNet " Caleb James DeLisle

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=373aaeff-ca95-4e45-8e1a-ce7e79e91f42@cjdns.fr \
    --to=cjd@cjdns.fr \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@kernel.org \
    --cc=vkoul@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 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).