From: sashiko-bot@kernel.org
To: lizhi2@eswincomputing.com
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH net-next v8 2/6] dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant
Date: Thu, 11 Jun 2026 01:32:49 +0000 [thread overview]
Message-ID: <20260611013249.E03641F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260610012907.894-1-lizhi2@eswincomputing.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Using a top-level `oneOf` partition for `compatible`-based constraints breaks schema extensibility and violates dt-schema conditional patterns.
--
commit c1875936c193e91a73baa1d661559e819f16e710
Author: Zhi Li <lizhi2@eswincomputing.com>
dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant
This commit adds a new compatible string for the EIC7700 eth1 MAC variant
to handle RX clock inversion requirements. It introduces specific
tx-internal-delay-ps constraints for each variant using a oneOf block.
> diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> index 4e02fedae5c67..8cb7545c56e87 100644
> --- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
[ ... ]
> allOf:
> - $ref: snps,dwmac.yaml#
>
> +oneOf:
> + - properties:
> + compatible:
> + contains:
> + const: eswin,eic7700-qos-eth
> + tx-internal-delay-ps:
> + minimum: 0
> + maximum: 2540
> + multipleOf: 20
> +
> + - properties:
> + compatible:
> + contains:
> + const: eswin,eic7700-qos-eth-clk-inversion
> + tx-internal-delay-ps:
> + minimum: 2000
> + maximum: 4540
> + multipleOf: 20
[Severity: Medium]
According to the device tree bindings subsystem guidelines, YAML binding
schemas typically use allOf with if-then blocks to apply different
constraints based on the compatible string.
Does placing a oneOf block at the root level create a mutually-exclusive
validation partition that will break schema extensibility?
If a new compatible string is added to the enum in the future, it looks
like it might fail the entire oneOf block by not matching either arm,
causing the whole document to fail validation.
Could this be rewritten using allOf and if-then conditionals?
[ ... ]
> @@ -67,11 +89,6 @@ properties:
> maximum: 2540
> multipleOf: 20
>
> - tx-internal-delay-ps:
> - minimum: 0
> - maximum: 2540
> - multipleOf: 20
> -
> eswin,hsp-sp-csr:
> description:
> HSP CSR is to control and get status of different high-speed peripherals
[Severity: Medium]
Is it intended to remove tx-internal-delay-ps entirely from the main
properties block?
Removing the property from the root properties block is usually considered
a schema anti-pattern. Should the base property definition remain here,
with only the range constraints being overridden in the conditional blocks
above?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610012727.848-1-lizhi2@eswincomputing.com?part=2
next prev parent reply other threads:[~2026-06-11 1:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 1:27 [PATCH net-next v8 0/6] net: stmmac: eic7700: add eth1 variant support and update delay bindings lizhi2
2026-06-10 1:28 ` [PATCH net-next v8 1/6] dt-bindings: ethernet: eswin: relax internal delay model to range-based constraints lizhi2
2026-06-10 1:29 ` [PATCH net-next v8 2/6] dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant lizhi2
2026-06-11 1:32 ` sashiko-bot [this message]
2026-06-10 1:29 ` [PATCH net-next v8 3/6] net: stmmac: eic7700: make RGMII delay properties optional lizhi2
2026-06-10 8:26 ` Maxime Chevallier
2026-06-10 1:31 ` [PATCH net-next v8 4/6] net: stmmac: eic7700: add support for eth1 clock inversion variant lizhi2
2026-06-10 1:32 ` [PATCH net-next v8 5/6] dt-bindings: mfd: syscon: add ESWIN EIC7700 compatible lizhi2
2026-06-10 1:32 ` [PATCH net-next v8 6/6] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller lizhi2
2026-06-11 1:32 ` sashiko-bot
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=20260611013249.E03641F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lizhi2@eswincomputing.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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