[PATCH 2/5] dt-bindings: soc: canaan: Add top syscon for Canaan K230 SoC

Krzysztof Kozlowski krzk at kernel.org
Tue Dec 30 06:00:26 PST 2025


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 at isrc.iscas.ac.cn>
> ...
>>> +
>>> +  "#size-cells":
>>> +    const: 1
>>> +
>>> +  usb-phy at 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 at 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



More information about the linux-riscv mailing list