[PATCH phy-next 01/13] dt-bindings: phy: lynx-10g: initial document

[Vladimir Oltean]

On Thu, May 28, 2026 at 08:45:08PM +0300, Vladimir Oltean wrote:
> On Thu, May 28, 2026 at 05:40:44PM +0000, sashiko-bot at kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Low] Invalid JSON Schema syntax for the `reg` property constraint.
> > --
> > 
> > commit e219405276839837989c30627d109ff39c15e361
> > Author: Vladimir Oltean <vladimir.oltean at nxp.com>
> > 
> > dt-bindings: phy: lynx-10g: initial document
> > 
> > This commit adds a new device tree binding schema for the 10G Lynx SerDes.
> > It defines the register map constraints and allows flexibility for the
> > #phy-cells property.
> > 
> > > diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml
> > > new file mode 100644
> > > index 0000000000000..993f076bba4e6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml
> > [ ... ]
> > > patternProperties:
> > >   "^phy@[0-7]$":
> > >     type: object
> > >     description: SerDes lane (single RX/TX differential pair)
> > > 
> > >     properties:
> > >       reg:
> > >         minimum: 0
> > >         maximum: 7
> > 
> > [Severity: Low]
> > Will this cause a meta-schema validation error during make dt_binding_check?
> > 
> > The reg property is parsed as an array type by dt-schema. Applying minimum
> > and maximum directly to an array property is invalid in JSON Schema, as those
> > keywords are only applicable to numeric types.
> > 
> > Should these constraints be wrapped inside an items list?
> > 
> > [ ... ]
> > > allOf:
> > >   - if:
> > >       properties:
> > >         compatible:
> > >           contains:
> > >             enum:
> > >               - fsl,ls1028a-serdes
> > >               - fsl,ls1046a-serdes1
> > >               - fsl,ls1046a-serdes2
> > >               - fsl,ls1088a-serdes1
> > >               - fsl,ls1088a-serdes2
> > >     then:
> > >       patternProperties:
> > >         "^phy@[0-7]$":
> > >           properties:
> > >             reg:
> > >               minimum: 0
> > >               maximum: 3
> > 
> > [Severity: Low]
> > Could the same meta-schema validation issue occur here? 
> > 
> > Since reg is an array, perhaps this constraint would be better enforced by
> > rejecting invalid unit addresses in the then clause entirely, for example,
> > by setting "^phy@[4-7]$": false?
> > 
> > -- 
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260528172404.733196-1-vladimir.oltean@nxp.com?part=1
> 
> We have the same pattern in fsl,lynx-28g.yaml and it didn't cause schema
> validation failures there.

Yes, so the dt_binding_check test passed fine:
https://patchwork.kernel.org/project/linux-phy/patch/20260528172404.733196-2-vladimir.oltean@nxp.com/

I will not be making any change to this patch in response to this LLM
feedback, just humans.