[PATCH v14 3/8] dt-bindings: i3c: Add NXP P3H2x4x i3c-hub support

sashiko-bot at kernel.org sashiko-bot at kernel.org
Tue Jul 14 03:30:01 PDT 2026


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 at 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 at nxp.com>
> +  - Vikash Bansal <vikash.bansal at nxp.com>
> +  - Lakshay Piplani <lakshay.piplani at 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



More information about the linux-i3c mailing list