Netdev List
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: markus.stockhausen@gmx.de
Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org,
	chris.packham@alliedtelesis.co.nz, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v4 1/5] dt-bindings: net: realtek,rtl9301-mdio: restrict MDIO buses by family
Date: Wed, 16 Sep 2026 13:35:10 +0000	[thread overview]
Message-ID: <178956571096.22033.1324157422276350284@kernel.org> (raw)
In-Reply-To: <20260912130451.3757276-2-markus.stockhausen@gmx.de>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 0

- [Medium] Incomplete constraint: the new per-family `allOf`/`if-then`
  blocks in…

--

dt-bindings: net: realtek,rtl9301-mdio: restrict MDIO buses by family

This adds two per-family conditional blocks to the Realtek Otto MDIO
controller binding so that mdio-bus child node names are limited to the
number of buses each family has: one for RTL838x, two for RTL839x and
four for RTL930x/RTL931x.

> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
> index 67e0b23a8470e..7f5b4897487b2 100644
> --- a/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
> @@ -67,6 +67,30 @@ patternProperties:
>  
>      unevaluatedProperties: false
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - realtek,rtl8380-mdio
> +              - realtek,rtl8381-mdio
> +              - realtek,rtl8382-mdio
> +    then:
> +      patternProperties:
> +        '^mdio-bus@[1-3]$': false
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - realtek,rtl8391-mdio
> +              - realtek,rtl8392-mdio
> +              - realtek,rtl8393-mdio
> +    then:
> +      patternProperties:
> +        '^mdio-bus@[2-3]$': false

[Severity: Medium]
These two conditionals only reject child node names, but the bus index the
driver consumes is the child's reg value.  Should the same conditionals also
bound reg?

The mdio-bus subschema keeps reg unconstrained apart from the item count,
for every compatible:

  patternProperties:
    '^mdio-bus@[0-3]$':
      $ref: mdio.yaml#

      properties:
        reg:
          maxItems: 1

      required:
        - reg

So this still validates cleanly against the RTL838x branch:

  mdio-controller@ca00 {
    compatible = "realtek,rtl8380-mdio";
    ...
    mdio-bus@0 {
      reg = <3>;
      ...
    };
  };

otto_emdio_probe_one() in drivers/net/mdio/mdio-realtek-rtl9300.c takes the
index from reg and never looks at the unit address:

  err = fwnode_property_read_u32(node, "reg", &mdio_bus);
  if (err)
          return dev_err_probe(dev, err, "undefined smi bus number\n");

  if (mdio_bus >= priv->info->num_buses)
          return dev_err_probe(dev, -EINVAL,
                               "illegal (dangling) smi bus number %d\n", mdio_bus);

and otto_emdio_map_ports() repeats the same check.

dtc does not close the gap either.  check_unit_address_vs_reg() in
scripts/dtc/checks.c only checks that a unit address exists when reg is
present:

  if (prop) {
          if (!unitname[0])
                  FAIL(c, dti, node, "node has a reg or ranges property, but no unit name");
  } else {
          if (unitname[0])
                  FAIL(c, dti, node, "node has a unit name, but no reg or ranges property");
  }

Numeric unit-address-vs-reg equality is only enforced for simple-bus, i2c,
spi and pci children, and an mdio-controller node is none of those.

The commit message says the current binding is "allowing non-existent buses
to be described for RTL838x and RTL839x devices".  With only the node names
restricted, a non-existent bus can still be described through reg and is
caught only at probe time.  Would adding a per-family maximum on the child
reg inside these conditionals match what the message describes?
Documentation/devicetree/bindings/net/marvell,pp2.yaml has the same shape
with properties: reg: maximum: inside a per-compatible conditional.

Note this is still the case at the end of the series (7c4e9351a929), where
the mdio-bus subschema declares only reg: maxItems: 1.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260912130451.3757276-1-markus.stockhausen%40gmx.de

  reply	other threads:[~2026-09-16 13:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12 13:04 [PATCH net-next v4 0/5] net: mdio: realtek-rtl9300: add bus frequency handling Markus Stockhausen
2026-09-12 13:04 ` [PATCH net-next v4 1/5] dt-bindings: net: realtek,rtl9301-mdio: restrict MDIO buses by family Markus Stockhausen
2026-09-16 13:35   ` netdev-bot+sashiko [this message]
2026-09-24 14:46     ` Rob Herring
2026-09-12 13:04 ` [PATCH net-next v4 2/5] dt-bindings: net: realtek,rtl9301-mdio: add clock-frequency Markus Stockhausen
2026-09-16 13:35   ` netdev-bot+sashiko
2026-09-24 14:43     ` Rob Herring
2026-09-12 13:04 ` [PATCH net-next v4 3/5] net: mdio: realtek-rtl9300: convert "fwnode" left-overs to "of" Markus Stockhausen
2026-09-14 16:30   ` Andrew Lunn
2026-09-12 13:04 ` [PATCH net-next v4 4/5] net: mdio: realtek-rtl9300: reject duplicate MDIO bus IDs Markus Stockhausen
2026-09-14 16:31   ` Andrew Lunn
2026-09-14 16:44   ` Andrew Lunn
2026-09-16 13:35   ` netdev-bot+sashiko
2026-09-12 13:04 ` [PATCH net-next v4 5/5] net: mdio: realtek-rtl9300: support non-default clock frequencies Markus Stockhausen
2026-09-14 16:47   ` Andrew Lunn
2026-09-16 13:35   ` netdev-bot+sashiko

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=178956571096.22033.1324157422276350284@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=markus.stockhausen@gmx.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    /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