Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lakshay Piplani" <lakshay.piplani@nxp.com>
Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v14 3/8] dt-bindings: i3c: Add NXP P3H2x4x i3c-hub support
Date: Tue, 14 Jul 2026 10:30:01 +0000	[thread overview]
Message-ID: <20260714103002.C10321F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714092053.2461482-4-lakshay.piplani@nxp.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The binding documents GPIO provider capabilities for the target ports but omits the corresponding required standard properties (`gpio-controller`, `#gpio-cells`) from the schema.
- [Medium] The schema artificially restricts the compatible string to a single part number (`nxp,p3h2840`), failing to support the full hardware family declared in the commit message.
- [Low] The `maximum: 7` constraint is incorrectly applied directly to the `reg` property for child nodes, rendering it ineffective.
--

--- Patch [3]: [PATCH v14 3/8] dt-bindings: i3c: Add NXP P3H2x4x i3c-hub support ---
commit de643e91ed7cd5797dc3f49d8564e4fab44c0789
Author: Aman Kumar Pandey <aman.kumarpandey@nxp.com>

dt-bindings: i3c: Add NXP P3H2x4x i3c-hub support

Add bindings for the NXP P3H2x4x (P3H2440/P3H2441/P3H2840/P3H2841)
multiport I3C hub family. These devices connect to a host via
I3C/I2C/SMBus and allow communication with multiple downstream
peripherals.

> diff --git a/Documentation/devicetree/bindings/i3c/nxp,p3h2840.yaml b/Documentation/devicetree/bindings/i3c/nxp,p3h2840.yaml
> new file mode 100644
> index 0000000000000..f7f0752de5333
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/nxp,p3h2840.yaml
> @@ -0,0 +1,291 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2025 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i3c/nxp,p3h2840.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP P3H2X4X I3C HUB
> +
> +maintainers:
> +  - Aman Kumar Pandey <aman.kumarpandey@nxp.com>
> +  - Vikash Bansal <vikash.bansal@nxp.com>
> +  - Lakshay Piplani <lakshay.piplani@nxp.com>
> +
> +description: |
> +  P3H2x4x (P3H2440/P3H2441/P3H2840/P3H2841) is a family of multiport I3C
> +  hub devices that connect to:-
> +  1. A host CPU via I3C/I2C/SMBus bus on upstream side and connect to multiple
> +     peripheral devices on the downstream  side.
> +  2. Have two Controller Ports which can support either
> +     I2C/SMBus or I3C buses and connect to a CPU, BMC or SOC.
> +  3. P3H2840/ P3H2841 are 8 port I3C hub with eight I3C/I2C Target Port.
> +  4. P3H2440/ P3H2441 are 4 port I3C hub with four I3C/I2C Target Port.
> +     Target ports can be configured as I2C/SMBus, I3C or GPIO and connect to
> +     peripherals.

[Severity: Medium]
The description notes that target ports can be configured as GPIO providers,
but the schema does not seem to include the corresponding required standard
properties. Should gpio-controller and #gpio-cells be added to the schema
to support this capability and avoid incomplete device trees passing validation?

> +
> +properties:
> +  compatible:
> +    const: nxp,p3h2840

[Severity: Medium]
The commit message indicates this binding supports the broader P3H2x4x family
(P3H2440, P3H2441, P3H2840, P3H2841), but this strictly restricts the
compatible string to a single part number. Should this be an enum allowing
the other family members, or use an enum alongside a fallback?

[ ... ]
> +patternProperties:
> +  "^i3c@[0-7]$":
> +    type: object
> +    $ref: /schemas/i3c/i3c.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        description:
> +          The I3C HUB Target Port number.
> +        maximum: 7

[Severity: Low]
Is this maximum: 7 constraint effective here? The reg property structurally
evaluates as an array, whereas the maximum keyword only applies to numeric
scalar types in JSON schema validation. Does this limit need to be structured
differently (for example, applying it to items) to be evaluated?

[ ... ]
> +  "^(i2c|smbus)@[0-7]$":
> +    type: object
> +    $ref: /schemas/i2c/i2c-controller.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        description:
> +          The I3C HUB Target Port number.
> +        maximum: 7

[Severity: Low]
Similarly for the i2c/smbus nodes, is applying maximum: 7 directly to the
reg property array valid for JSON schema validation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714092053.2461482-1-lakshay.piplani@nxp.com?part=3

  reply	other threads:[~2026-07-14 10:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14  9:20 [PATCH v14 0/8] Add support for NXP P3H2x4x I3C hub driver Lakshay Piplani
2026-07-14  9:20 ` [PATCH v14 1/8] i3c: master: Add APIs for I3C hub support Lakshay Piplani
2026-07-14 10:03   ` sashiko-bot
2026-07-14 19:04     ` Frank Li
2026-07-14  9:20 ` [PATCH v14 2/8] i3c: master: Fix IBI request and free cleanup paths Lakshay Piplani
2026-07-14 10:20   ` sashiko-bot
2026-07-14 19:10     ` Frank Li
2026-07-14  9:20 ` [PATCH v14 3/8] dt-bindings: i3c: Add NXP P3H2x4x i3c-hub support Lakshay Piplani
2026-07-14 10:30   ` sashiko-bot [this message]
2026-07-14  9:20 ` [PATCH v14 4/8] mfd: p3h2x4x: Add driver for NXP P3H2x4x i3c hub and on-die regulator Lakshay Piplani
2026-07-14 10:49   ` sashiko-bot
2026-07-14  9:20 ` [PATCH v14 5/8] regulator: p3h2x4x: Add driver for on-die regulators in NXP P3H2x4x i3c hub Lakshay Piplani
2026-07-14 10:57   ` sashiko-bot
2026-07-14  9:20 ` [PATCH v14 6/8] i3c: hub: Add support for the I3C interface in the I3C hub Lakshay Piplani
2026-07-14 11:14   ` sashiko-bot
2026-07-14  9:20 ` [PATCH v14 7/8] i3c: hub: p3h2x4x: Add support for NXP P3H2x4x I3C hub functionality Lakshay Piplani
2026-07-14 11:31   ` sashiko-bot
2026-07-14  9:20 ` [PATCH v14 8/8] i3c: hub: p3h2x4x: Add SMBus slave mode support Lakshay Piplani
2026-07-14 11:56   ` 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=20260714103002.C10321F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lakshay.piplani@nxp.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox