From: sashiko-bot@kernel.org
To: "Chi-Wen Weng" <cwweng.linux@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects
Date: Mon, 03 Aug 2026 02:48:12 +0000 [thread overview]
Message-ID: <20260803024812.9FBDD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803024048.1641756-1-cwweng.linux@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit disallows the `cs-gpios` property in the DT binding based solely on a current Linux driver limitation, violating the core Device Tree principle that bindings describe hardware, not software capabilities.
--
--- Patch [1]: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects ---
commit 3aecb6991adf3696410ad69c99107c7d732fd078
Author: Chi-Wen Weng <cwweng@nuvoton.com>
dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects
This commit updates the nuvoton,ma35d1-qspi binding to explicitly disallow
the cs-gpios property. The change is made because the current driver only
supports native chip selects, preventing the use of GPIO-based chip selects.
> diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> --- a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> +++ b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> @@ -33,6 +33,8 @@ properties:
> maximum: 2
> default: 2
>
> + cs-gpios: false
> +
[Severity: Medium]
Does this restriction violate the device tree principle that bindings should
describe hardware rather than software capabilities?
By explicitly disallowing cs-gpios in the properties block based on a current
Linux driver limitation, board designers who route a standard GPIO to a SPI
peripheral's chip select pin will be incorrectly prevented from describing
their actual physical board wiring. When running make dtbs_check on a board
device tree that uses cs-gpios for this controller, the schema will reject it.
Should the hardware schema allow standard hardware properties like cs-gpios
even if the current software driver lacks support for them?
> required:
> - compatible
> - reg
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803024048.1641756-1-cwweng.linux@gmail.com?part=1
next prev parent reply other threads:[~2026-08-03 2:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 2:40 [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects Chi-Wen Weng
2026-08-03 2:48 ` sashiko-bot [this message]
2026-08-03 6:01 ` Chi-Wen Weng
2026-08-03 6:26 ` Chi-Wen Weng
2026-08-03 13:26 ` Mark Brown
2026-08-03 13:35 ` Mark Brown
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=20260803024812.9FBDD1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cwweng.linux@gmail.com \
--cc=devicetree@vger.kernel.org \
--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 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.