public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Colin Foster <colin.foster@in-advantage.com>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, netdev@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	Linus Walleij <linus.walleij@linaro.org>,
	UNGLinuxDriver@microchip.com,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Lee Jones <lee@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH v3 net-next 12/14] dt-bindings: net: dsa: ocelot: add ocelot-ext documentation
Date: Mon, 10 Oct 2022 20:48:56 +0300	[thread overview]
Message-ID: <20221010174856.nd3n4soxk7zbmcm7@skbuf> (raw)
In-Reply-To: <d27d7740-bf35-b8d4-d68c-bb133513fa19@linaro.org>

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?

  reply	other threads:[~2022-10-10 17:49 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26  0:29 [PATCH v3 net-next 00/14] add support for the the vsc7512 internal copper phys Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 01/14] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 02/14] net: mscc: ocelot: expose regfield definition to be used by other drivers Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 03/14] net: mscc: ocelot: expose stats layout " Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 04/14] net: mscc: ocelot: expose vcap_props structure Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 05/14] net: mscc: ocelot: expose ocelot_reset routine Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 06/14] net: dsa: felix: add configurable device quirks Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 07/14] net: dsa: felix: populate mac_capabilities for all ports Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 08/14] net: dsa: felix: update init_regmap to be string-based Colin Foster
2022-09-27 17:53   ` Vladimir Oltean
2022-09-27 18:43     ` Colin Foster
2022-09-27 18:56       ` Vladimir Oltean
2022-09-26  0:29 ` [PATCH v3 net-next 09/14] pinctrl: ocelot: avoid macro redefinition Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 10/14] mfd: ocelot: prepend resource size macros to be 32-bit Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 11/14] mfd: ocelot: add regmaps for ocelot_ext Colin Foster
2022-09-27 21:04   ` Vladimir Oltean
2022-09-27 23:01     ` Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 12/14] dt-bindings: net: dsa: ocelot: add ocelot-ext documentation Colin Foster
2022-09-27 20:26   ` Vladimir Oltean
2022-09-27 22:20     ` Colin Foster
2022-10-07 22:48       ` Vladimir Oltean
2022-10-08 17:56         ` Colin Foster
2022-09-30 21:15     ` Colin Foster
2022-10-01  0:20       ` Colin Foster
2022-10-03 15:28         ` Vladimir Oltean
2022-10-07 20:44     ` Colin Foster
2022-10-07 22:38       ` Vladimir Oltean
2022-10-04 11:19   ` Krzysztof Kozlowski
2022-10-04 12:15     ` Vladimir Oltean
2022-10-04 14:59       ` Krzysztof Kozlowski
2022-10-04 16:01         ` Vladimir Oltean
2022-10-05  8:09           ` Krzysztof Kozlowski
2022-10-07 23:10             ` Vladimir Oltean
2022-10-09 15:49               ` Krzysztof Kozlowski
2022-10-05  0:08     ` Colin Foster
2022-10-05  8:03       ` Krzysztof Kozlowski
2022-10-05 15:44         ` Colin Foster
2022-10-05 16:09           ` Krzysztof Kozlowski
2022-10-08  0:00             ` Vladimir Oltean
2022-10-09 16:14               ` Krzysztof Kozlowski
2022-10-10 13:07                 ` Vladimir Oltean
2022-10-10 13:37                   ` Krzysztof Kozlowski
2022-10-10 17:48                     ` Vladimir Oltean [this message]
2022-10-10 18:47                       ` Colin Foster
2022-10-10 19:11                         ` Vladimir Oltean
2022-10-11  9:53                         ` Vladimir Oltean
2023-01-18 22:28                       ` Colin Foster
2023-01-19 20:21                         ` Vladimir Oltean
2023-01-20 18:16                           ` Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 13/14] net: dsa: ocelot: add external ocelot switch control Colin Foster
2022-09-27 20:40   ` Vladimir Oltean
2022-09-26  0:29 ` [PATCH v3 net-next 14/14] mfd: " Colin Foster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221010174856.nd3n4soxk7zbmcm7@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=colin.foster@in-advantage.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox