> >>> +description:
> >>> +  The NXP I/O connector represents a physically present I/O
> >>> +connector on the
> >>> +  base board. It acts as a nexus that exposes a constrained set of
> >>> +I/O
> >>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
> >>> +fixed
> >>> +  electrical wiring. All actual hardware providers reside on the base
> board.
> >>> +  The connector node only defines index-based mappings to those
> >> providers.
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    const: fsl,io-connector
> >>
> >> Everything is IO. Everything is connector, so your compatible does
> >> not match requirements from writing bindings.
> >>
> >
> > Yes, this compatible is too generic. I will rename the compatible to
> > fsl,aud-io-connector.
> 
> aud is not much better. Which boards have it? What's the pinout? What's
> standard? Is it described anywhere? If so, provide reference to spec/docs.
>

This is not an industry standard electrical interface. This connector
is present on i.MX95-19x19-EVK and i.MX952-EVK. For example, the
"i.MX 95 19mm x 19mm Evaluation Kit" homepage[1] publicly documents an
audio board connection through which IMX-AUD-IO card is connected. The
detailed user manual (UM12022) is listed as official documentation[2],
but it is behind an NXP login, so it is not suitable as a public
reference for upstream. Therefore I list it here to illustrate it's
mechanism:

+-----------------------------+                      
|        Base Board           |                      
|   +-----+      +---------+  |           +---------+
|   | SPI +------+         |  |           |         |
|   +-----+      |         |  | GPIO MAP  |         |
|                |         +--|-----------+         |
|   +-----+      |         |  |           |         |
|   | I2C +------+         |  |           |         |
|   +-----+      |         |  | CLOCK MAP |  AUD-IO |
|                |connector+--|-----------+   CARD  |
|   +-----+      |         |  |           |         |
|   | I2S +------+         |  |           |         |
|   +-----+      |         |  |           |         |
|                |         |  | INT MAP   |         |
|   +-----+      |         +--|-----------+         |
|   | I/O +------+         |  |           |         |
|   +-----+      +---------+  |           +---------+
+-----------------------------+                      

[1]https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19
[2]https://docs.nxp.com/bundle/UM12022/page/topics/pcie_interface1.html

> >
> >>> +
> >>> +  gpio-controller: true
> >>> +
> >>> +  '#gpio-cells':
> >>> +    const: 2
> >>> +
> >>> +  gpio-map:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> >>
> >> You do not need to redefine the types. You need constraints, though.
> >>
> >
> > OK. I will add proper constraints.
> >
> >>> +
> >>> +  gpio-map-mask:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>> +
> >>> +  gpio-map-pass-thru:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>> +
> >>> +  '#clock-cells':
> >>> +    const: 1
> >>> +
> >>> +  clock-map:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> >>> +
> >>> +  clock-map-mask:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>> +
> >>> +  clock-map-pass-thru:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>
> >> I do not see these defined anywhere. I also checked cover letter for
> >> references for pulls to dtschema.
> >>
> >
> > Nexus nodes are already in the device-tree specification：
> > https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
> > For reference, current kernel has supported it:
> > * Nexus OF support:
> > commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists
> > through a nexus node")
> > * GPIO adoption:
> > commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
> > * PWM adoption:
> > commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
> > Clock adoption is ongoing:
> > https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/
>
> DT spec only mentions nexuses, but it is only a spec. Each property from
> the spec must be defined in dtschema or kernel bindings.
> 
> I do not see any dependency mentioned in the cover letter, so how do you
> think we can figure out where is this definition of clock nexus?
> 
> 

I initially tried to add support for clock nexus dt bindings in patch 1,
but I noticed there is already an ongoing series doing the same thing.
([PATCH 10/16] clk: Add support for clock nexus dt bindings). Since that
work is in progress, I think it's better not duplicate it here.

I think we can add a dedicated binding defining the clock nexus
properties(#clock-cells, clock-map, clock-map-mask, clock-map-pass-thru),
in reference of existing pwm-nexus-node.yaml.

In the next revision I will also update the cover letter to explicitly
mention that clock nexus support is ongoing.

> Best regards,
> Krzysztof

Regards, 
Chancel Liu