linux-kernel - Re: [RFC PATCH v1 2/6] dt-bindings: phy: rockchip: add rk3328 usb3 phy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6ed39130-4f77-490d-ab28-8b65cb685147@kernel.org>
Date: Sat, 18 Jan 2025 10:06:21 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Peter Geis <pgwipeout@...il.com>
Cc: Heiko Stuebner <heiko@...ech.de>, zyw@...k-chips.com,
 kever.yang@...k-chips.com, frank.wang@...k-chips.com,
 william.wu@...k-chips.com, wulf@...k-chips.com,
 linux-rockchip@...ts.infradead.org, Conor Dooley <conor+dt@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 Vinod Koul <vkoul@...nel.org>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-phy@...ts.infradead.org
Subject: Re: [RFC PATCH v1 2/6] dt-bindings: phy: rockchip: add rk3328 usb3
 phy

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