On Mon, Oct 10, 2022 at 08:48:56PM +0300, Vladimir Oltean wrote: > On Mon, Oct 10, 2022 at 09:37:23AM -0400, Krzysztof Kozlowski wrote: > > What stops you from doing that? What do you need from me? > > To end the discussion on a constructive note, I think if I were Colin, > I would do the following, in the following order, according to what was > expressed as a constraint: > > 1. Reword the "driver" word out of mscc,vsc7514-switch.yaml and express > the description in terms of what the switch can do, not what the > driver can do. > > 2. Make qca8k.yaml have "$ref: dsa.yaml#". Remove "$ref: dsa-port.yaml#" > from the same schema. > > 3. Remove "- $ref: dsa-port.yaml#" from mediatek,mt7530.yaml. It doesn't > seem to be needed, since dsa.yaml also has this. We need this because > we want to make sure no one except dsa.yaml references dsa-port.yaml. > > 4. Move the DSA-unspecific portion from dsa.yaml into a new > ethernet-switch.yaml. What remains in dsa.yaml is "dsa,member". > The dsa.yaml schema will have "$ref: ethernet-switch.yaml#" for the > "(ethernet-)switch" node, plus its custom additions. > > 5. Move the DSA-unspecific portion from dsa-port.yaml into a new > ethernet-switch-port.yaml. What remains in dsa-port.yaml is: > * ethernet phandle > * link phandle > * label property > * dsa-tag-protocol property > * the constraint that CPU and DSA ports must have phylink bindings > > 6. The ethernet-switch.yaml will have "$ref: ethernet-switch-port.yaml#" > and "$ref: dsa-port.yaml". The dsa-port.yaml schema will *not* have > "$ref: ethernet-switch-port.yaml#", just its custom additions. > I'm not 100% on this, but I think there will be a problem if: > - dsa.yaml references ethernet-switch.yaml > - ethernet-switch.yaml references ethernet-switch-port.yaml > - dsa.yaml also references dsa-port.yaml > - dsa-port.yaml references ethernet-switch-port.yaml > because ethernet-switch-port.yaml will be referenced twice. Again, > not sure if this is a problem. If it isn't, things can be simpler, > just make dsa-port.yaml reference ethernet-switch-port.yaml, and skip > steps 2 and 3 since dsa-port.yaml containing just the DSA specifics > is no longer problematic. > > 7. Make mscc,vsc7514-switch.yaml have "$ref: ethernet-switch.yaml#" for > the "mscc,vsc7514-switch.yaml" compatible string. This will eliminate > its own definitions for the generic properties: $nodename and > ethernet-ports (~45 lines of code if I'm not mistaken). > > 8. Introduce the "mscc,vsc7512-switch" compatible string as part of > mscc,vsc7514-switch.yaml, but this will have "$ref: dsa.yaml#" (this > will have to be referenced by full path because they are in different > folders) instead of "ethernet-switch.yaml". Doing this will include > the common bindings for a switch, plus the DSA specifics. > > 9. Optional: rework ti,cpsw-switch.yaml, microchip,lan966x-switch.yaml, > microchip,sparx5-switch.yaml to have "$ref: ethernet-switch.yaml#" > which should reduce some duplication in existing schemas. > > 10. Question for future support of VSC7514 in DSA mode: how do we decide > whether to $ref: ethernet-switch.yaml or dsa.yaml? If the parent MFD > node has a compatible string similar to "mscc,vsc7512", then use DSA, > otherwise use generic ethernet-switch? > > Colin, how does this sound? Thank you for laying this path out for me. Hopefully when I go heads-down to implement this there won't be any gotchas. It seems pretty straightforward. Maybe my only question would be where to send these patches. If these can all go through net-next it seems like there'd be no issue when step 8 (add 7512 documentation) comes along with this current patch set. Otherwise this sounds good. I'll switch to getting a patch set of steps 1-7 as you suggest.
