From:   Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To:     Rob Herring <robh+dt@kernel.org>, Heiko Stuebner <heiko@sntech.de>,
        Johan Jonker <jbx6244@gmail.com>
Cc:     devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] arm64: dts: rockchip: Add spi1 pins on Quartz64 A
Date:   Sat, 27 Nov 2021 16:40:26 +0100
Message-ID: <3750380.Q3bl6Pheio@archbook>
In-Reply-To: <acbd0e0a-b194-7b17-148d-49fdd348077e@gmail.com>
References: <20211127141910.12649-1-frattaroli.nicolas@gmail.com> <20211127141910.12649-4-frattaroli.nicolas@gmail.com> <acbd0e0a-b194-7b17-148d-49fdd348077e@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Samstag, 27. November 2021 16:29:33 CET Johan Jonker wrote:
> 
> On 11/27/21 3:19 PM, Nicolas Frattaroli wrote:
> > The Quartz64 Model A has the SPI pins broken out on its pin
> > header. The actual pins being used though are not the m0
> > variant, but the m1 variant, which also lacks the cs1 pin.
> > 
> > This commit overrides pinctrl-0 accordingly for this board.
> > 
> > spi1 is intentionally left disabled, as anyone wishing to add
> > SPI devices needs to edit the dts anyway, and the pins are more
> > useful as GPIOs for the rest of the users.
> > 
> > Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
> > ---
> >  arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
> > index 4d4b2a301b1a..166399b7f13f 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
> > @@ -509,6 +509,11 @@ &spdif {
> >  	status = "okay";
> >  };
> >  
> > +&spi1 {
> 
> > +	pinctrl-names = "default";
> 
> With the removal off pinctrl-1 the pinctrl-names property is already
> correctly defined.
> 

If it ever gets re-added in the future, it no longer is, so it's better
to be explicit right now than to risk one board breaking in the future
when the SoC's definition changes.

Regards,
Nicolas Frattaroli