Message ID | 20230926210818.197356-2-fabrizio.castro.jz@renesas.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp2264380vqu; Tue, 26 Sep 2023 16:45:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHH5Swqsjbkuznfp765xNsezROW1+Q8kpOVSrf1Lioqwl8ejAbuL25VDWlbfryLsPrvpESV X-Received: by 2002:a05:6870:8325:b0:1d0:c320:b65e with SMTP id p37-20020a056870832500b001d0c320b65emr585803oae.23.1695771919677; Tue, 26 Sep 2023 16:45:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695771919; cv=none; d=google.com; s=arc-20160816; b=lrgUy1vZkhqQdcU3QwMBaw4wnyGUANVkzi8rP1PAgu7rH6vRIF0vT3GptwuKriVYpv WjqlplrD7l9vVk4gEGJKceb2AXD18IeFXWCorGUGCLlBOpX8yg9OqWay9TG0aAfQh6DD 3vHcdr7kHvrTi00sA/YVn9JsO/by8zNEK18gSXlvm4oqYN4lbZWH1ILEByg6doLgJ8BP Xrg3aJ97okBtZC/G6OucbrH9keGGDjDXnJrejhBM5x+MCOHRPiFWClMp0ATLXkCJIV2F Q/VP23OGfQF7ecABGftvAIVVWPXQdgYmJWQlCDe8Lysbvyoev/P0Nfk2ZOFaWZEuCjc/ R2QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=gH35+7pr/iEFDHeAMdsYzMpRjkiBm0eHQ12w7Bst0AQ=; fh=RCG5UTJZL4x7EFXQRWT8toPnZJDmRxABMjXK1Kmzugw=; b=L5pIDsieHDeZrQoBXxBJD+4hTWfQjHwTqpcgAFy2lqJv9nGzhOB5xcGHNm78qbtb6/ h/0Q8VZK/RbYLTo6e7o13QoY1UzY/2FPgwYuO+CvOVEc4WejJtYkmLNs9yeXxymLFzHd L5UJsw4WXQ3Ms++3NTo1X1nSB2v3bYJoxE7oaN1cT5qilsgXZRjO0d0iZYWO1C8DQfvM ezvLVfwWR7MkbkraVZVCkjbbGDo0yDFUxjmvWDR/+fVktsxOgxQeqYU5qwQDY7Zw6roP 1LN0/q7ZqaeIc1ul3nj6nhjOlAsMhvr22RhHBlyBQEvk0omgogf0WgxzSmAjrVNrmYs4 LZFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=renesas.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id bs125-20020a632883000000b00564929df8besi12686714pgb.568.2023.09.26.16.45.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 16:45:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=renesas.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 277C081B93CA; Tue, 26 Sep 2023 16:44:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233853AbjIZXn7 (ORCPT <rfc822;pwkd43@gmail.com> + 28 others); Tue, 26 Sep 2023 19:43:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229602AbjIZXlz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 26 Sep 2023 19:41:55 -0400 Received: from relmlie5.idc.renesas.com (relmlor1.renesas.com [210.160.252.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 88B1E76AE; Tue, 26 Sep 2023 15:57:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="6.03,178,1694703600"; d="scan'208";a="177325632" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie5.idc.renesas.com with ESMTP; 27 Sep 2023 06:08:31 +0900 Received: from mulinux.home (unknown [10.226.92.200]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id DFF8E40B91B6; Wed, 27 Sep 2023 06:08:26 +0900 (JST) From: Fabrizio Castro <fabrizio.castro.jz@renesas.com> To: Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Geert Uytterhoeven <geert+renesas@glider.be> Cc: Fabrizio Castro <fabrizio.castro.jz@renesas.com>, Magnus Damm <magnus.damm@gmail.com>, linux-spi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Chris Paterson <Chris.Paterson2@renesas.com>, Biju Das <biju.das@bp.renesas.com>, Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Subject: [PATCH 1/2] spi: renesas,rzv2m-csi: Add SPI Slave related properties Date: Tue, 26 Sep 2023 22:08:17 +0100 Message-Id: <20230926210818.197356-2-fabrizio.castro.jz@renesas.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230926210818.197356-1-fabrizio.castro.jz@renesas.com> References: <20230926210818.197356-1-fabrizio.castro.jz@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 26 Sep 2023 16:44:07 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778145736635611830 X-GMAIL-MSGID: 1778145736635611830 |
Series |
Add RZ/V2M CSI slave support
|
|
Commit Message
Fabrizio Castro
Sept. 26, 2023, 9:08 p.m. UTC
The CSI IP found inside the Renesas RZ/V2M SoC can also work
in SPI slave mode.
When working in slave mode, the IP can make use of the SS
(Slave Select) pin, with "low" as default active level.
The active level of SS can be changed to "high" upon configuration.
This patch adds two new properties, one to make use of the
SS pin when in slave mode, and one to make the SS pin active high.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
.../bindings/spi/renesas,rzv2m-csi.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Comments
Hi Fabrizio, On Tue, Sep 26, 2023 at 11:08 PM Fabrizio Castro <fabrizio.castro.jz@renesas.com> wrote: > The CSI IP found inside the Renesas RZ/V2M SoC can also work > in SPI slave mode. > When working in slave mode, the IP can make use of the SS > (Slave Select) pin, with "low" as default active level. > The active level of SS can be changed to "high" upon configuration. > This patch adds two new properties, one to make use of the > SS pin when in slave mode, and one to make the SS pin active high. > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Thanks for your patch! > --- a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml > +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml > @@ -39,6 +39,17 @@ properties: > power-domains: > maxItems: 1 > > + renesas,csi-ss: > + type: boolean > + description: > + Use CSI Slave Selection (SS) pin to enable transmission and reception when > + in slave mode. Can't this be done in a more generic way? I had expected that the existing SPI_NO_CS flag can be set using a property in the "slave" subnode, but apparently there is no "spi-no-cs" property defined yet. > + > + renesas,csi-ss-high: > + type: boolean > + description: > + The SS pin is active high (by default the SS pin is active low). Can't you use the "spi-cs-high" property in the "slave" subnode instead? > + > required: > - compatible > - reg Gr{oetje,eeting}s, Geert
On Tue, Sep 26, 2023 at 10:08:17PM +0100, Fabrizio Castro wrote: > The CSI IP found inside the Renesas RZ/V2M SoC can also work > in SPI slave mode. > When working in slave mode, the IP can make use of the SS > (Slave Select) pin, with "low" as default active level. > The active level of SS can be changed to "high" upon configuration. > This patch adds two new properties, one to make use of the > SS pin when in slave mode, and one to make the SS pin active high. Please avoid the use of outdated terminology like this, prefer "device mode" or similar. > + renesas,csi-ss: > + type: boolean > + description: > + Use CSI Slave Selection (SS) pin to enable transmission and reception when > + in slave mode. When would this ever not be true when in device mode?
On Wed, Sep 27, 2023 at 09:59:05AM +0200, Geert Uytterhoeven wrote: > On Tue, Sep 26, 2023 at 11:08 PM Fabrizio Castro > > + type: boolean > > + description: > > + Use CSI Slave Selection (SS) pin to enable transmission and reception when > > + in slave mode. > Can't this be done in a more generic way? I had expected that the > existing SPI_NO_CS flag can be set using a property in the "slave" subnode, > but apparently there is no "spi-no-cs" property defined yet. The description is clearly saying there is a chip select, _NO_CS seems entirely inappropriate. It's not specified in the device tree because when there's no chip select for a device it's a fundamental property of how the device is controlled and we don't need any information beyond the compatible.
Hi Mark, On Wed, Sep 27, 2023 at 11:00 AM Mark Brown <broonie@kernel.org> wrote: > On Wed, Sep 27, 2023 at 09:59:05AM +0200, Geert Uytterhoeven wrote: > > On Tue, Sep 26, 2023 at 11:08 PM Fabrizio Castro > > > + type: boolean > > > + description: > > > + Use CSI Slave Selection (SS) pin to enable transmission and reception when > > > + in slave mode. > > > Can't this be done in a more generic way? I had expected that the > > existing SPI_NO_CS flag can be set using a property in the "slave" subnode, > > but apparently there is no "spi-no-cs" property defined yet. > > The description is clearly saying there is a chip select, _NO_CS seems > entirely inappropriate. It's not specified in the device tree because > when there's no chip select for a device it's a fundamental property of > how the device is controlled and we don't need any information beyond > the compatible. In host mode, it indeed doesn't matter, as you can have only a single device connected with SPI_NO_CS. In device mode, the device needs to know if it must monitor the chip select line or not. In hindsight, I should have kept the question I had written initially, but deleted after having read the documentation for the corresponding RZ/V2M register bits: What does it mean if this is false? That there is no chip select? So "spi-no-cs" would be the inverse of "renesas,csi-ss". Gr{oetje,eeting}s, Geert
On Wed, Sep 27, 2023 at 11:10:58AM +0200, Geert Uytterhoeven wrote: > On Wed, Sep 27, 2023 at 11:00 AM Mark Brown <broonie@kernel.org> wrote: > > The description is clearly saying there is a chip select, _NO_CS seems > > entirely inappropriate. It's not specified in the device tree because > > when there's no chip select for a device it's a fundamental property of > > how the device is controlled and we don't need any information beyond > > the compatible. > In host mode, it indeed doesn't matter, as you can have only a single > device connected with SPI_NO_CS. > In device mode, the device needs to know if it must monitor the chip > select line or not. > In hindsight, I should have kept the question I had written initially, > but deleted after having read the documentation for the corresponding > RZ/V2M register bits: > What does it mean if this is false? That there is no chip select? > So "spi-no-cs" would be the inverse of "renesas,csi-ss". I see. Is there any control over what the chip select is when there is one, in which case we could just look to see if there's one specified? I'm a bit nervous about a generic property that maps onto _NO_CS since it's likely that people will start using that in device bindings when they shouldn't.
Hi Geert, Thanks for your reply! > From: Geert Uytterhoeven <geert@linux-m68k.org> > Subject: Re: [PATCH 1/2] spi: renesas,rzv2m-csi: Add SPI Slave related > properties > > Hi Fabrizio, > > On Tue, Sep 26, 2023 at 11:08 PM Fabrizio Castro > <fabrizio.castro.jz@renesas.com> wrote: > > The CSI IP found inside the Renesas RZ/V2M SoC can also work > > in SPI slave mode. > > When working in slave mode, the IP can make use of the SS > > (Slave Select) pin, with "low" as default active level. > > The active level of SS can be changed to "high" upon configuration. > > This patch adds two new properties, one to make use of the > > SS pin when in slave mode, and one to make the SS pin active high. > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> > > Thanks for your patch! > > > --- a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml > > +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml > > @@ -39,6 +39,17 @@ properties: > > power-domains: > > maxItems: 1 > > > > + renesas,csi-ss: > > + type: boolean > > + description: > > + Use CSI Slave Selection (SS) pin to enable transmission and > reception when > > + in slave mode. > > Can't this be done in a more generic way? I had expected that the > existing SPI_NO_CS flag can be set using a property in the "slave" > subnode, > but apparently there is no "spi-no-cs" property defined yet. I couldn't find a generic way to address that in a generic way. > > > + > > + renesas,csi-ss-high: > > + type: boolean > > + description: > > + The SS pin is active high (by default the SS pin is active > low). > > Can't you use the "spi-cs-high" property in the "slave" subnode > instead? I could. I didn't go for it for the first version of this series after reading the automatic handling of SPI_CS_HIGH (which for example doesn't get automatically added to the mode for targets using a GPIO as CS). Even though nothing prevents you from explicitly adding SPI_CS_HIGH to the mode and using "spi-cs-high" in the device tree, I thought that could be confusing, but maybe it's not? Thanks, Fab > > > + > > required: > > - compatible > > - reg > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > geert@linux-m68k.org > > In personal conversations with technical people, I call myself a > hacker. But > when I'm talking to journalists I just say "programmer" or something > like that. > -- Linus Torvalds
Hi Mark, Thanks for your reply! > From: Mark Brown <broonie@kernel.org> > Subject: Re: [PATCH 1/2] spi: renesas,rzv2m-csi: Add SPI Slave related > properties > > On Tue, Sep 26, 2023 at 10:08:17PM +0100, Fabrizio Castro wrote: > > The CSI IP found inside the Renesas RZ/V2M SoC can also work > > in SPI slave mode. > > When working in slave mode, the IP can make use of the SS > > (Slave Select) pin, with "low" as default active level. > > The active level of SS can be changed to "high" upon configuration. > > This patch adds two new properties, one to make use of the > > SS pin when in slave mode, and one to make the SS pin active high. > > Please avoid the use of outdated terminology like this, prefer "device > mode" or similar. Okay, I'll resend with a more modern terminology ("host" and "target"). > > > + renesas,csi-ss: > > + type: boolean > > + description: > > + Use CSI Slave Selection (SS) pin to enable transmission and > reception when > > + in slave mode. > > When would this ever not be true when in device mode? This IP can do without the SS pin to start operations. In fact, the SS pin is disabled by default (I know...), it needs to be explicitly enabled, and when enabled the pin is active low by default. Cheers, Fab
Hi Geert, Thanks for your reply! > From: Geert Uytterhoeven <geert@linux-m68k.org> > Subject: Re: [PATCH 1/2] spi: renesas,rzv2m-csi: Add SPI Slave related > properties > > Hi Mark, > > On Wed, Sep 27, 2023 at 11:00 AM Mark Brown <broonie@kernel.org> wrote: > > On Wed, Sep 27, 2023 at 09:59:05AM +0200, Geert Uytterhoeven wrote: > > > On Tue, Sep 26, 2023 at 11:08 PM Fabrizio Castro > > > > + type: boolean > > > > + description: > > > > + Use CSI Slave Selection (SS) pin to enable transmission > and reception when > > > > + in slave mode. > > > > > Can't this be done in a more generic way? I had expected that the > > > existing SPI_NO_CS flag can be set using a property in the "slave" > subnode, > > > but apparently there is no "spi-no-cs" property defined yet. > > > > The description is clearly saying there is a chip select, _NO_CS > seems > > entirely inappropriate. It's not specified in the device tree > because > > when there's no chip select for a device it's a fundamental property > of > > how the device is controlled and we don't need any information > beyond > > the compatible. > > In host mode, it indeed doesn't matter, as you can have only a single > device connected with SPI_NO_CS. > In device mode, the device needs to know if it must monitor the chip > select line or not. > > In hindsight, I should have kept the question I had written initially, > but deleted after having read the documentation for the corresponding > RZ/V2M register bits: > > What does it mean if this is false? That there is no chip select? Yes, that's what it means. The IP would just use the clock line to shift data in and out. Clearly, that could lead to "misunderstandings" as changing the active level of the clock line on the host side may lead to extra clock cycles interpreted by the slave. > > So "spi-no-cs" would be the inverse of "renesas,csi-ss". Yes, exactly. Cheers, Fab > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > geert@linux-m68k.org > > In personal conversations with technical people, I call myself a > hacker. But > when I'm talking to journalists I just say "programmer" or something > like that. > -- Linus Torvalds
Hi Mark, On Wed, Sep 27, 2023 at 11:21 AM Mark Brown <broonie@kernel.org> wrote: > On Wed, Sep 27, 2023 at 11:10:58AM +0200, Geert Uytterhoeven wrote: > > On Wed, Sep 27, 2023 at 11:00 AM Mark Brown <broonie@kernel.org> wrote: > > > > The description is clearly saying there is a chip select, _NO_CS seems > > > entirely inappropriate. It's not specified in the device tree because > > > when there's no chip select for a device it's a fundamental property of > > > how the device is controlled and we don't need any information beyond > > > the compatible. > > > In host mode, it indeed doesn't matter, as you can have only a single > > device connected with SPI_NO_CS. > > In device mode, the device needs to know if it must monitor the chip > > select line or not. > > > In hindsight, I should have kept the question I had written initially, > > but deleted after having read the documentation for the corresponding > > RZ/V2M register bits: > > > What does it mean if this is false? That there is no chip select? > > > So "spi-no-cs" would be the inverse of "renesas,csi-ss". > > I see. Is there any control over what the chip select is when there is > one, in which case we could just look to see if there's one specified? On RZ/V2M there isn't, as there is only a single hardware chip select. On MSIOF, there are 3 hardware chip selects, but apparently only the primary one can be used in target mode. I have to admit I never thought about this before (commit cf9e4784f3bde3e4 ("spi: sh-msiof: Add slave mode support") also predates commit 9cce882bedd2768d ("spi: sh-msiof: Extend support to 3 native chip selects")). Hence the SPI target DT bindings use a single "slave" subnode, without a unit address, thus assuming no explicit (or a default) chip select configuration. Gr{oetje,eeting}s, Geert
On Wed, Sep 27, 2023 at 11:44:17AM +0200, Geert Uytterhoeven wrote: > On Wed, Sep 27, 2023 at 11:21 AM Mark Brown <broonie@kernel.org> wrote: > > I see. Is there any control over what the chip select is when there is > > one, in which case we could just look to see if there's one specified? > On RZ/V2M there isn't, as there is only a single hardware chip select. > On MSIOF, there are 3 hardware chip selects, but apparently only the > primary one can be used in target mode. OK, it sounds like we do need a property then. Like I say I'd rather not have one that just works for _NO_CS in order to avoid confusion for people writing SPI device drivers, either something in the generic target binding or a device specific one.
Hi Mark, Thanks for your reply! > From: Mark Brown <broonie@kernel.org> > Subject: Re: [PATCH 1/2] spi: renesas,rzv2m-csi: Add SPI Slave related > properties > > On Wed, Sep 27, 2023 at 11:44:17AM +0200, Geert Uytterhoeven wrote: > > On Wed, Sep 27, 2023 at 11:21 AM Mark Brown <broonie@kernel.org> > wrote: > > > > I see. Is there any control over what the chip select is when > there is > > > one, in which case we could just look to see if there's one > specified? > > > On RZ/V2M there isn't, as there is only a single hardware chip > select. > > > On MSIOF, there are 3 hardware chip selects, but apparently only the > > primary one can be used in target mode. > > OK, it sounds like we do need a property then. Like I say I'd rather > not have one that just works for _NO_CS in order to avoid confusion > for > people writing SPI device drivers, either something in the generic > target binding or a device specific one. Shall I invert the logic then? What I mean is I could drop property "renesas,csi-ss" and add property "renesas,csi-no-ss" instead, therefore without "renesas,csi-no-ss" pin SS will be used, with "renesas,csi-no-ss" pin SS won't be used. What do you think? Also, I could drop "renesas,csi-ss-high" and use "spi-cs-high" instead? Geert, any thoughts on the above? Thanks, Fab
On Wed, Sep 27, 2023 at 10:18:57AM +0000, Fabrizio Castro wrote: > > From: Mark Brown <broonie@kernel.org> > > OK, it sounds like we do need a property then. Like I say I'd rather > > not have one that just works for _NO_CS in order to avoid confusion > > for > > people writing SPI device drivers, either something in the generic > > target binding or a device specific one. > Shall I invert the logic then? What I mean is I could drop property > "renesas,csi-ss" and add property "renesas,csi-no-ss" instead, therefore > without "renesas,csi-no-ss" pin SS will be used, with "renesas,csi-no-ss" > pin SS won't be used. > What do you think? That sounds fine for me, I guess we could add a further property if some new IP allows multiple options for the chip select in target mode. > Also, I could drop "renesas,csi-ss-high" and use "spi-cs-high" instead? I think that's OK but I looked less at that bit.
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml index e59183e53690..c3d8ad6525bb 100644 --- a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml @@ -39,6 +39,17 @@ properties: power-domains: maxItems: 1 + renesas,csi-ss: + type: boolean + description: + Use CSI Slave Selection (SS) pin to enable transmission and reception when + in slave mode. + + renesas,csi-ss-high: + type: boolean + description: + The SS pin is active high (by default the SS pin is active low). + required: - compatible - reg @@ -50,6 +61,10 @@ required: - '#address-cells' - '#size-cells' +dependencies: + renesas,csi-ss: [ spi-slave ] + renesas,csi-ss-high: [ 'renesas,csi-ss' ] + unevaluatedProperties: false examples: