[PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[Chi-Wen Weng]

From: Chi-Wen Weng <cwweng@nuvoton.com>

The generic SPI controller binding allows GPIO-based chip selects, but
the MA35D1 QSPI driver currently supports only the controller's native
chip selects.

Disallow the cs-gpios property so that the binding matches the
functionality provided by the driver.

Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
---
 Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
index 377ccf4fb224..40965ec5163b 100644
--- 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
+
 required:
   - compatible
   - reg
-- 
2.25.1

Re: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[sashiko-bot]

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

Re: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[Chi-Wen Weng]

sashiko-bot@kernel.org 於 2026/8/3 上午 10:48 寫道:
> 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

Hi,

Thanks for pointing this out.

I agree that the binding should describe valid hardware and board wiring 
rather than the current driver limitation.

I will send a v2 that keeps cs-gpios supported by the binding and 
instead enables GPIO descriptor-based chip-select handling in the MA35D1 
QSPI driver. I will also keep active-high chip selects restricted to 
GPIO-based chip selects, since the controller's native chip selects 
currently support active-low operation only.

Best regards,
Chi-Wen

Re: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[Chi-Wen Weng]

sashiko-bot@kernel.org 於 2026/8/3 上午 10:48 寫道:
> 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

Hi,

Thanks for pointing this out.

I agree that the binding should describe valid hardware and board wiring 
rather than the current driver limitation.

I will send a v2 that keeps cs-gpios supported by the binding and 
instead enables GPIO descriptor-based chip-select handling in the MA35D1 
QSPI driver. I will also keep active-high chip selects restricted to 
GPIO-based chip selects, since the controller's native chip selects 
currently support active-low operation only.

Best regards,
Chi-Wen

Re: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Mon, Aug 03, 2026 at 10:40:48AM +0800, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
> 
> The generic SPI controller binding allows GPIO-based chip selects, but
> the MA35D1 QSPI driver currently supports only the controller's native
> chip selects.

Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

[Mark Brown]

On Mon, 03 Aug 2026 10:40:48 +0800, Chi-Wen Weng wrote:
> dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3

Thanks!

[1/1] dt-bindings: spi: nuvoton,ma35d1-qspi: Disallow GPIO chip selects
      https://git.kernel.org/broonie/misc/c/98e69afa6d57

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark