lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 10 Oct 2022 11:47:09 -0700
From:   Colin Foster <>
To:     Vladimir Oltean <>
Cc:     Krzysztof Kozlowski <>,,,,,
        Russell King <>,
        Linus Walleij <>,,
        Alexandre Belloni <>,
        Claudiu Manoil <>,
        Lee Jones <>,
        Krzysztof Kozlowski <>,
        Rob Herring <>,
        Paolo Abeni <>,
        Jakub Kicinski <>,
        Eric Dumazet <>,
        "David S. Miller" <>,
        Florian Fainelli <>,
        Vivien Didelot <>,
        Andrew Lunn <>
Subject: Re: [PATCH v3 net-next 12/14] dt-bindings: net: dsa: ocelot: add
 ocelot-ext documentation

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

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.

Powered by blists - more mailing lists