All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Stefan Wahren" <wahrenst@gmx.net>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
	devicetree@vger.kernel.org,
	"Vincent Mailhol" <mailhol@kernel.org>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	conor+dt@kernel.org, linux-can@vger.kernel.org,
	Frank.Li@kernel.org, imx@lists.linux.dev,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	vkoul@kernel.org, olteanv@gmail.com,
	linux-phy@lists.infradead.org, neil.armstrong@linaro.org,
	robh@kernel.org
Subject: Re: [PATCH V3 2/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542
Date: Wed, 02 Sep 2026 13:35:24 +0000	[thread overview]
Message-ID: <20260902133525.E22DE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902132801.22056-3-wahrenst@gmx.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added `microchip,mcp2542` compatible string bypasses schema validation hardware constraints because its fallback conditional block uses a strict `enum` match rather than `contains`.
--

commit c5426cb50d1b23a21e92a69a5197ccb523f72e8b
Author: Stefan Wahren <wahrenst@gmx.net>

dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542
    
The Microchip MCP2542 High-speed CAN transceiver with Sleep mode is a
pin-compatible alternative for the TI TCAN1042.

> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 9f5c37ca6496a..3ed4ce2191201 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -18,6 +18,7 @@ properties:
>        - items:
>            - enum:
>                - microchip,ata6561
> +              - microchip,mcp2542

[Severity: Medium]
Will this newly added compatible string bypass the hardware constraints enforced
later in the schema?

When a device tree defines compatible = "microchip,mcp2542", "ti,tcan1042", the
schema parses it as a string array. However, the allOf conditional block further
down in the file checks for ti,tcan1042 using a strict scalar enum match:

allOf:
  - if:
      properties:
        compatible:
          enum:
            - nxp,tjr1443
            - ti,tcan1042
            - ti,tcan1043
    then:

Since the array fails the strict enum match, the then constraints are skipped,
which allows a microchip,mcp2542 device node with an invalid configuration to
silently pass dt_binding_check.

Should the allOf block be updated to use contains instead of enum, or should
microchip,mcp2542 be explicitly added to the enum list, to ensure these devices
are properly validated?

>                - ti,tcan1051
>            - const: ti,tcan1042
>        - items:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902132801.22056-1-wahrenst@gmx.net?part=2

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Stefan Wahren" <wahrenst@gmx.net>
Cc: "Oliver Hartkopp" <socketcan@hartkopp.net>,
	devicetree@vger.kernel.org,
	"Vincent Mailhol" <mailhol@kernel.org>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	conor+dt@kernel.org, linux-can@vger.kernel.org,
	Frank.Li@kernel.org, imx@lists.linux.dev,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	vkoul@kernel.org, olteanv@gmail.com,
	linux-phy@lists.infradead.org, neil.armstrong@linaro.org,
	robh@kernel.org
Subject: Re: [PATCH V3 2/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542
Date: Wed, 02 Sep 2026 13:35:24 +0000	[thread overview]
Message-ID: <20260902133525.E22DE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902132801.22056-3-wahrenst@gmx.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added `microchip,mcp2542` compatible string bypasses schema validation hardware constraints because its fallback conditional block uses a strict `enum` match rather than `contains`.
--

commit c5426cb50d1b23a21e92a69a5197ccb523f72e8b
Author: Stefan Wahren <wahrenst@gmx.net>

dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542
    
The Microchip MCP2542 High-speed CAN transceiver with Sleep mode is a
pin-compatible alternative for the TI TCAN1042.

> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 9f5c37ca6496a..3ed4ce2191201 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -18,6 +18,7 @@ properties:
>        - items:
>            - enum:
>                - microchip,ata6561
> +              - microchip,mcp2542

[Severity: Medium]
Will this newly added compatible string bypass the hardware constraints enforced
later in the schema?

When a device tree defines compatible = "microchip,mcp2542", "ti,tcan1042", the
schema parses it as a string array. However, the allOf conditional block further
down in the file checks for ti,tcan1042 using a strict scalar enum match:

allOf:
  - if:
      properties:
        compatible:
          enum:
            - nxp,tjr1443
            - ti,tcan1042
            - ti,tcan1043
    then:

Since the array fails the strict enum match, the then constraints are skipped,
which allows a microchip,mcp2542 device node with an invalid configuration to
silently pass dt_binding_check.

Should the allOf block be updated to use contains instead of enum, or should
microchip,mcp2542 be explicitly added to the enum list, to ensure these devices
are properly validated?

>                - ti,tcan1051
>            - const: ti,tcan1042
>        - items:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902132801.22056-1-wahrenst@gmx.net?part=2

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 13:27 [PATCH V3 0/3] arm64: dts: freescale: Add chargebyte Charge Control Y Stefan Wahren
2026-09-02 13:27 ` Stefan Wahren
2026-09-02 13:27 ` [PATCH V3 1/3] dt-bindings: arm: fsl: " Stefan Wahren
2026-09-02 13:27   ` Stefan Wahren
2026-09-02 13:27 ` [PATCH V3 2/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542 Stefan Wahren
2026-09-02 13:27   ` Stefan Wahren
2026-09-02 13:35   ` sashiko-bot [this message]
2026-09-02 13:35     ` sashiko-bot
2026-09-02 13:28 ` [PATCH V3 3/3] arm64: dts: freescale: Add chargebyte Charge Control Y Stefan Wahren
2026-09-02 13:28   ` Stefan Wahren

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=20260902133525.E22DE1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=neil.armstrong@linaro.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=socketcan@hartkopp.net \
    --cc=vkoul@kernel.org \
    --cc=wahrenst@gmx.net \
    /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.