Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200824091013.20640-1-matthias.schiffer@ew.tq-group.com>
 <20200824091013.20640-2-matthias.schiffer@ew.tq-group.com>
 <CAOMZO5DSX1pf3xxo=CGvgPmHcjMJoWFx74grVJBckSmjtF-RGg@mail.gmail.com>
 <4b7d57738ce8e2130c4740a0f3f973fbaf60a7cf.camel@ew.tq-group.com>
 <CAOMZO5DYrkEb_G+EYAGrc+qjSsbjRdeBUU3tJUfkU6tjgNm_7g@mail.gmail.com>
 <7a59492e46f34d213b83f7182c7db73954c5a9c7.camel@ew.tq-group.com>
 <CAOMZO5CP=wtJ5ZScyb0NrRMW0FR0FAGVKRFq9JpFcAoZppn_bA@mail.gmail.com>
 <53f5f17735fc2f0ca061a321969bbb131e55efff.camel@ew.tq-group.com>
 <CAOMZO5ADeXEHWiG7Xja1W1GnahV08ZEYSkNsrOzautn2mROCNA@mail.gmail.com>
 <aa0b7ad149a7bd4e681e4ebee12ffaaab2803832.camel@ew.tq-group.com>
 <CAOMZO5B_Jm8SX9N9V5oq+LAa0Yc4CmrEp2n=2t3XUyBCtnGVTA@mail.gmail.com>
 <d433e8a47d721a65903db68c38eb1c337c81e395.camel@ew.tq-group.com>
 <CAOMZO5AfuPXfOmRSXAmyG-bdqGSzvTRm51NuTJ-B2PzKbLy9mw@mail.gmail.com> <9978aff9c90f5e4aa2049a5c65768b9695a910c5.camel@ew.tq-group.com>
In-Reply-To: <9978aff9c90f5e4aa2049a5c65768b9695a910c5.camel@ew.tq-group.com>
From:   Fabio Estevam <festevam@gmail.com>
Date:   Thu, 27 Aug 2020 18:27:07 -0300
Message-ID: <CAOMZO5Dp28MSjQugWCwqfor=eEPvy+EfuoVL0y_oirw=G600aA@mail.gmail.com>
Subject: Re: [PATCH 2/2] ARM: dts: imx6qdl: tqma6: minor fixes
To:     Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc:     Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        NXP Linux Team <linux-imx@nxp.com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Matthias,

(Your mailer is messing the threading.)

On Thu, Aug 27, 2020 at 4:31 AM Matthias Schiffer
<matthias.schiffer@ew.tq-group.com> wrote:

> Ah, I see.
>
> Nevertheless, hardware that uses the native chipselects of newer chips
> exists (for example our TQ-Systems starterkit mainboards, the DTS of
> which we're currently preparing for mainline submission). Shouldn't
> num-cs be set for boards (or SoM DTSI) where not all CS pins of the SoC
> are usable?
>
> In any case, my original question was about the intended logic for
> num_chipselects for SPI drivers. My proposal was:
>
> - If num-cs is set, use that
> - If num-cs is unset, use the number of cs-gpios
> - If num-cs is unset and no cs-gpios are defined, use a driver-provided
> default
>
> How do other SPI controller drivers deal with this?

I think it would be better to discuss this in the spi mailing list
with Mark Brown and the dt maintainer, Rob Herring.