All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Minda Chen" <minda.chen@starfivetech.com>
Cc: krzk+dt@kernel.org, robh@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/3] scsi: ufs: dt-bindings: starfive: Add UFS Host Controller for JHB100 soc
Date: Sat, 09 May 2026 06:38:23 +0000	[thread overview]
Message-ID: <20260509063824.4BBCEC2BCB2@smtp.kernel.org> (raw)
In-Reply-To: <20260509062759.125472-2-minda.chen@starfivetech.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Missing `clock-names` in the `required` list.
- [Low] Unconstrained `starfive,syscon` property allows invalid array lengths and arguments.
- [Low] The example section uses the deprecated `freq-table-hz` property.
--

commit dcb3253ccedb17e87bb1f204ca98535c01e219f6
Author: Minda Chen <minda.chen@starfivetech.com>

scsi: ufs: dt-bindings: starfive: Add UFS Host Controller for JHB100 soc

This commit adds the devicetree binding documentation for the StarFive JHB100
SoC UFS Host Controller, based on the Synopsys DesignWare IP.

> diff --git a/Documentation/devicetree/bindings/ufs/starfive,jhb100-ufs.yaml b/Documentation/devicetree/bindings/ufs/starfive,jhb100-ufs.yaml
> new file mode 100644
> index 0000000000000..4773f1c2670f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/starfive,jhb100-ufs.yaml
[ ... ]
> +  starfive,syscon:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description:
> +      The phandle to System Register Controller syscon node.

The starfive,syscon property is defined as a phandle-array, but should this
include an items or maxItems constraint? Since the example uses a bare
phandle, would it be better typed as just
/schemas/types.yaml#/definitions/phandle to prevent passing arrays of
arbitrary lengths during schema validation?

> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - resets
> +  - reset-names
> +  - interrupts
> +  - starfive,syscon

Is there a missing entry for clock-names in this list? The binding
mandates the clocks property and defines 'ref_clk' and 'ufs', so omitting
clock-names here allows device trees to define clocks without names and
still pass validation, potentially failing during driver lookup.

[ ... ]
> +examples:
> +  - |
> +    ufs@11b10000 {
> +        compatible = "starfive,jhb100-ufs";
> +        reg = <0x11b10000 0x20000>;
> +        interrupts = <105>;
> +        clocks = <&syscrg 4>,
> +                 <&syscrg 5>;
> +        clock-names = "ref_clk", "ufs";
> +        freq-table-hz = <26000000 26000000>,
> +                        <100000000 100000000>;

This isn't a bug, but does this example need to use freq-table-hz? The
common schema ufs-common.yaml included via $ref marks this property as
deprecated in favor of operating-points-v2. Using it in a new example
might encourage copying deprecated patterns into downstream device trees.

> +        resets = <&syscrg 10>,
> +                 <&syscrg 7>;
> +        reset-names = "main", "phy";
> +        starfive,syscon = <&syscon>;
> +    };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260509062759.125472-1-minda.chen@starfivetech.com?part=1

  reply	other threads:[~2026-05-09  6:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-09  6:27 [PATCH v2 0/3] Add StarFive JHB100 soc UFS platform driver Minda Chen
2026-05-09  6:27 ` [PATCH v2 1/3] scsi: ufs: dt-bindings: starfive: Add UFS Host Controller for JHB100 soc Minda Chen
2026-05-09  6:38   ` sashiko-bot [this message]
2026-05-09  6:27 ` [PATCH v2 2/3] scsi: ufs: dwc: Rename amd-versal2 read/write PHY API and move to dwc common file Minda Chen
2026-05-09  6:43   ` sashiko-bot
2026-05-09  6:27 ` [PATCH v2 3/3] scsi: ufs: starfive: Add UFS support for StarFive JHB100 SoC Minda Chen
2026-05-09  7:07   ` sashiko-bot

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=20260509063824.4BBCEC2BCB2@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=minda.chen@starfivetech.com \
    --cc=robh@kernel.org \
    --cc=sashiko@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.