[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <572407e8-bac7-4277-bfbd-ed42327b0ff4@kernel.org>
Date: Tue, 30 Dec 2025 15:00:26 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jiayu Du <jiayu.riscv@...c.iscas.ac.cn>
Cc: conor@...nel.org, vkoul@...nel.org, gregkh@...uxfoundation.org,
pjw@...nel.org, palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
neil.armstrong@...aro.org, krzk+dt@...nel.org,
linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
linux-usb@...r.kernel.org
Subject: Re: [PATCH 2/5] dt-bindings: soc: canaan: Add top syscon for Canaan
K230 SoC
On 30/12/2025 14:14, Jiayu Du wrote:
> On Tue, Dec 30, 2025 at 08:39:19AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Dec 30, 2025 at 10:37:21AM +0800, Jiayu Du wrote:
>>> The Canaan K230 SoC top system controller provides register access
>>> to configure related modules. It includes a USB2 PHY and eMMC/SDIO PHY.
>>>
>>> Signed-off-by: Jiayu Du <jiayu.riscv@...c.iscas.ac.cn>
> ...
>>> +
>>> + "#size-cells":
>>> + const: 1
>>> +
>>> + usb-phy@70:
>>> + $ref: schemas/phy/canaan,k230-usb-phy.yaml#
>>
>> So that's why you did not have example there? But where did you explain
>> merging strategy/constraints/dependencies? How maintainers can now they
>> can apply this or not?
>
> Sorry, I will update in v2.
>
>>
>>
>>> + unevaluatedProperties: false
>>> +
>>> + usb-phy@90:
>>> + $ref: schemas/phy/canaan,k230-usb-phy.yaml#
>>> + unevaluatedProperties: false
>>
>> Anyway, these are not really real children. Defining child per phy,
>> where each such phy is just few registers, is way too granular. Instead
>> define one phy with phy-cells=2.
Just a note: phy-cells=1, I made mistake before.
>>
>> You also MUST make this device - hisys - binding complete. If you do
>> not, then my review is: fold the children here, because you do not have
>> any other resources for the parent.
>
> This hisys memory area not only includes the usbphy registers,
> but also contains the registers of sd/mmc phy. Therefore, the
> hisys node is necessary and cannot be folded.
Can be. There is absolutely nothing stopping it.
Anyway, define all nodes.
>
>
> If what I said above is accepted by you, do I still need to
> merge the two usb phy nodes by defining one phy with phy-cells=2?
You should read your datasheet, not exactly rely on me guessing. In
current form of the binding, you must fold the child into the parent.
Best regards,
Krzysztof
Powered by blists - more mailing lists