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: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ