From: Krzysztof Kozlowski <krzk@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
zyw@rock-chips.com, kever.yang@rock-chips.com,
frank.wang@rock-chips.com, william.wu@rock-chips.com,
wulf@rock-chips.com, linux-rockchip@lists.infradead.org,
Conor Dooley <conor+dt@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Rob Herring <robh@kernel.org>, Vinod Koul <vkoul@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org
Subject: Re: [RFC PATCH v1 2/6] dt-bindings: phy: rockchip: add rk3328 usb3 phy
Date: Sat, 18 Jan 2025 10:06:21 +0100 [thread overview]
Message-ID: <6ed39130-4f77-490d-ab28-8b65cb685147@kernel.org> (raw)
In-Reply-To: <CAMdYzYoB-wFGcmDNYrOMKTb0XSseBd7btLarKBB5+TUB-11KjA@mail.gmail.com>
On 16/01/2025 14:32, Peter Geis wrote:
>>
>>
>>> + additionalProperties: false
>>> +
>>> + properties:
>>> + compatible:
>>> + enum:
>>> + - rockchip,rk3328-usb3phy-utmi
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + "#phy-cells":
>>> + const: 0
>>
>> Does not look correct. Your parent device is the phy, not child. Why do
>> you create children per each type of phy?
>
> Because that's how it's done elsewhere in Rockchip's phys [1]. How
> should it be done?
The phys have separate supplies and IO addresses? Then it is reasonable
to keep them separate and as children. But then more questions appear:
why resets - which are also per utmi or port - are in top-level node?
This should be represented in coherent way: either you define the
properties/nodes per PHY or just everything in one/entire PHY
controller. Not mixed.
Same concerns about clocks in top-level.
It also might be that everything is a bit mixed, so you have entire phy
controller handling common resources and still separate phy for USB2 and
USB3 as children, but that should be conscious choice coming from actual
hardware. You have entire "description:" in binding to explain the
hardware and any questions I asked now.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-01-18 9:06 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 1:26 [RFC PATCH v1 0/6] rockchip: add a functional usb3 phy driver for rk3328 Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 1/6] clk: rockchip: fix wrong clk_ref_usb3otg parent " Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 2/6] dt-bindings: phy: rockchip: add rk3328 usb3 phy Peter Geis
2025-01-16 13:08 ` Krzysztof Kozlowski
2025-01-16 13:32 ` Peter Geis
2025-01-16 13:59 ` Peter Geis
2025-01-18 9:06 ` Krzysztof Kozlowski [this message]
2025-01-15 1:26 ` [RFC PATCH v1 3/6] phy: rockchip: add driver for " Peter Geis
2025-01-15 11:24 ` Piotr Oniszczuk
2025-01-16 14:09 ` Peter Geis
2025-01-16 12:59 ` Krzysztof Kozlowski
2025-01-16 13:14 ` Peter Geis
2025-01-16 15:26 ` Diederik de Haas
2025-01-16 15:57 ` Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 4/6] arm64: dts: rockchip: add rk3328 usb3 phy node Peter Geis
2025-01-16 13:01 ` Krzysztof Kozlowski
2025-01-16 16:53 ` Diederik de Haas
2025-01-17 4:10 ` Dragan Simic
2025-01-18 8:46 ` Krzysztof Kozlowski
2025-01-18 9:25 ` Dragan Simic
2025-01-18 9:31 ` Krzysztof Kozlowski
2025-01-18 9:43 ` Dragan Simic
2025-01-18 9:52 ` Krzysztof Kozlowski
2025-01-18 10:10 ` Dragan Simic
2025-01-18 10:29 ` Krzysztof Kozlowski
2025-01-18 10:45 ` Dragan Simic
2025-01-18 14:22 ` Peter Geis
2025-01-18 8:41 ` Krzysztof Kozlowski
2025-01-18 9:19 ` Krzysztof Kozlowski
2025-01-18 9:34 ` Dragan Simic
2025-01-18 15:55 ` Diederik de Haas
2025-01-15 1:26 ` [RFC PATCH v1 5/6] arm64: dts: rockchip: enable the usb3 phy on rk3328-roc boards Peter Geis
2025-01-15 1:26 ` [RFC PATCH v1 6/6] arm64: dts: rockchip: enable the usb3 phy on remaining rk3328 boards Peter Geis
2025-01-15 11:22 ` [RFC PATCH v1 0/6] rockchip: add a functional usb3 phy driver for rk3328 Piotr Oniszczuk
2025-01-15 12:25 ` Peter Geis
2025-01-15 12:35 ` Piotr Oniszczuk
2025-01-15 13:15 ` Peter Geis
2025-01-15 13:25 ` Piotr Oniszczuk
2025-01-16 14:02 ` Peter Geis
2025-01-16 14:35 ` Piotr Oniszczuk
2025-01-16 16:00 ` Peter Geis
2025-01-18 9:08 ` Krzysztof Kozlowski
2025-01-18 14:35 ` Peter Geis
2025-02-26 19:49 ` (subset) " Heiko Stuebner
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=6ed39130-4f77-490d-ab28-8b65cb685147@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frank.wang@rock-chips.com \
--cc=heiko@sntech.de \
--cc=kever.yang@rock-chips.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=pgwipeout@gmail.com \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
--cc=william.wu@rock-chips.com \
--cc=wulf@rock-chips.com \
--cc=zyw@rock-chips.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