Re: [PATCH net-next v2 2/2] dt-bindings: net: microchip,ksz: document microchip,rmii-clk-internal

[Vladimir Oltean]

On Tue, Oct 17, 2023 at 08:48:27AM +0100, Conor Dooley wrote:
> On Tue, Oct 17, 2023 at 09:35:48AM +0200, Ante Knezic wrote:
> > > > +  microchip,rmii-clk-internal:
> > > > +    $ref: /schemas/types.yaml#/definitions/flag
> > > > +    description:
> > > > +      Set if the RMII reference clock is provided internally. Otherwise
> > > > +      reference clock should be provided externally.
> > > > +
> > > > +if:
> > > > +  not:
> > > > +    properties:
> > > > +      compatible:
> > > > +        enum:
> > > > +          - microchip,ksz8863
> > > > +          - microchip,ksz8873
> > > > +then:
> > > > +  not:
> > > > +    required:
> > > > +      - microchip,rmii-clk-internal
> 
> I think this bit can become the slightly simpler
> 	then:
> 	  properties:
> 	     microchip,rmii-clk-internal: false

This looks better. I don't understand how the original formulation worked
("not: required:" when the property was never "required" in the first
place - does that do anything?), but I understand how this one does.

> > > I think that what you want to express is that microchip,rmii-clk-internal
> > > is only defined for microchip,ksz8863 and microchip,ksz8873.
> > > Can't you describe that as "if: properties: compatible: (...) then:
> > > properties: microchip,rmii-clk-internal"?
> > 
> > If I understood you correctly you are refering to a solution like
> > if:
> >   properties:
> >     compatible:
> >       enum:
> >         - microchip,ksz8863
> >         - microchip,ksz8873
> > then:
> >   properties:
> >     microchip,rmii-clk-internal:
> >       $ref: /schemas/types.yaml#/definitions/flag
> >       description:
> >         Set if the RMII reference clock is provided internally. Otherwise
> >         reference clock should be provided externally.
> > 
> > This was already suggested in v1, but was not a satisfactory solution
> > according to Mr. Conor Dooley:
> 
> Yeah, we prefer not to have the property definitions inside the
> conditionals, but rather constrain or allow/disallow them there.
> 
> Cheers,
> Conor.

Ok, now you know I didn't open the discussion on v1 :)