All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, linux-sunxi@lists.linux.dev,
	linux-amlogic@lists.infradead.org, imx@lists.linux.dev,
	robh@kernel.org, conor+dt@kernel.org, Frank.Li@kernel.org,
	neil.armstrong@linaro.org, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH net-next v16 2/7] dt-bindings: net: qcom: document the ethqos device for SCMI-based systems
Date: Thu, 15 Oct 2026 12:40:57 +0000	[thread overview]
Message-ID: <sashiko-outbox-172832@kernel.org> (raw)
In-Reply-To: <20261014-qcom-sa8255p-emac-v16-2-0266c2ead980@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: net: missed power-domains constraint in ultrarisc,dp1000-gmac.yaml
--

commit eaf763b0d0d309757c6cf7f9fe067155eb99eb11
Author: Bartosz Golaszewski <brgl@kernel.org>

dt-bindings: net: qcom: document the ethqos device for SCMI-based systems

This commit describes the firmware-managed variant of the QCom DesignWare MAC
in a separate file. It updates the top-level snps,dwmac.yaml to allow up to
two power domains and restricts existing referencing bindings to a maximum of
one power domain.

> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 2218a492817fd..2c4842404bf67 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml

[ ... ]

> @@ -187,7 +188,8 @@ properties:
>            - enum: [ahb, stmmaceth-ocp]
>  
>    power-domains:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
>  
>    mac-mode:
>      $ref: ethernet-controller.yaml#/properties/phy-connection-type

[Severity: Low]
Was Documentation/devicetree/bindings/net/ultrarisc,dp1000-gmac.yaml missed in
the updates to other bindings?

The commit message states the intent to update existing bindings referencing
snps,dwmac.yaml to limit their maxItems for power-domains to 1. However,
ultrarisc,dp1000-gmac.yaml references snps,dwmac.yaml under its allOf node:

Documentation/devicetree/bindings/net/ultrarisc,dp1000-gmac.yaml:
allOf:
  - $ref: snps,dwmac.yaml#

Because the top-level snps,dwmac.yaml was relaxed to allow 2 power domains
here, and ultrarisc,dp1000-gmac.yaml lacks a local override, does it implicitly
inherit the newly relaxed limit of 2?

Could this cause a schema validation regression where device trees for the
hardware could incorrectly specify up to two power domains without failing
validation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-qcom-sa8255p-emac-v16-0-0266c2ead980@oss.qualcomm.com?part=2

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, linux-sunxi@lists.linux.dev,
	linux-amlogic@lists.infradead.org, imx@lists.linux.dev,
	robh@kernel.org, conor+dt@kernel.org, Frank.Li@kernel.org,
	neil.armstrong@linaro.org, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH net-next v16 2/7] dt-bindings: net: qcom: document the ethqos device for SCMI-based systems
Date: Thu, 15 Oct 2026 12:40:57 +0000	[thread overview]
Message-ID: <sashiko-outbox-172832@kernel.org> (raw)
In-Reply-To: <20261014-qcom-sa8255p-emac-v16-2-0266c2ead980@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: net: missed power-domains constraint in ultrarisc,dp1000-gmac.yaml
--

commit eaf763b0d0d309757c6cf7f9fe067155eb99eb11
Author: Bartosz Golaszewski <brgl@kernel.org>

dt-bindings: net: qcom: document the ethqos device for SCMI-based systems

This commit describes the firmware-managed variant of the QCom DesignWare MAC
in a separate file. It updates the top-level snps,dwmac.yaml to allow up to
two power domains and restricts existing referencing bindings to a maximum of
one power domain.

> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 2218a492817fd..2c4842404bf67 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml

[ ... ]

> @@ -187,7 +188,8 @@ properties:
>            - enum: [ahb, stmmaceth-ocp]
>  
>    power-domains:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
>  
>    mac-mode:
>      $ref: ethernet-controller.yaml#/properties/phy-connection-type

[Severity: Low]
Was Documentation/devicetree/bindings/net/ultrarisc,dp1000-gmac.yaml missed in
the updates to other bindings?

The commit message states the intent to update existing bindings referencing
snps,dwmac.yaml to limit their maxItems for power-domains to 1. However,
ultrarisc,dp1000-gmac.yaml references snps,dwmac.yaml under its allOf node:

Documentation/devicetree/bindings/net/ultrarisc,dp1000-gmac.yaml:
allOf:
  - $ref: snps,dwmac.yaml#

Because the top-level snps,dwmac.yaml was relaxed to allow 2 power domains
here, and ultrarisc,dp1000-gmac.yaml lacks a local override, does it implicitly
inherit the newly relaxed limit of 2?

Could this cause a schema validation regression where device trees for the
hardware could incorrectly specify up to two power domains without failing
validation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-qcom-sa8255p-emac-v16-0-0266c2ead980@oss.qualcomm.com?part=2

  reply	other threads:[~2026-10-15 12:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 12:36 [PATCH net-next v16 0/7] net: stmmac: qcom-ethqos: add support for SCMI power domains Bartosz Golaszewski
2026-10-14 12:36 ` Bartosz Golaszewski
2026-10-14 12:36 ` Bartosz Golaszewski
2026-10-14 12:36 ` Bartosz Golaszewski
2026-10-14 12:36 ` [PATCH net-next v16 1/7] net: stmmac: dwmac4: don't program the 1us tick counter without a CSR clock Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36 ` [PATCH net-next v16 2/7] dt-bindings: net: qcom: document the ethqos device for SCMI-based systems Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-15 12:40   ` sashiko-bot [this message]
2026-10-15 12:40     ` sashiko-bot
2026-10-14 12:36 ` [PATCH net-next v16 3/7] net: stmmac: qcom-ethqos: set serdes mode before powerup Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36 ` [PATCH net-next v16 4/7] net: stmmac: qcom-ethqos: update phy_mode to the resolved interface in mac_finish() Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36 ` [PATCH net-next v16 5/7] net: stmmac: qcom-ethqos: reuse the address of ethqos_emac_driver_data Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36 ` [PATCH net-next v16 6/7] net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36 ` [PATCH net-next v16 7/7] net: stmmac: qcom-ethqos: add support for sa8255p Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski
2026-10-14 12:36   ` Bartosz Golaszewski

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=sashiko-outbox-172832@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.