Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 25 Nov 2022 16:48:23 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Jonathan =?iso-8859-1?Q?Neusch=E4fer?= <j.neuschaefer@gmx.net>
Cc:     linux-spi@vger.kernel.org, openbmc@lists.ozlabs.org,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] spi: wpcm-fiu: Add driver for Nuvoton WPCM450
 Flash Interface Unit (FIU)
Message-ID: <Y4Dx13KQHqyBLak3@sirena.org.uk>
References: <20221124191400.287918-1-j.neuschaefer@gmx.net>
 <20221124191400.287918-3-j.neuschaefer@gmx.net>
 <Y4C9druicCm0m3wi@sirena.org.uk>
 <Y4DuW6Rai0urvrEI@probook>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="EcQuk4Qg6NViYNQL"
Content-Disposition: inline
In-Reply-To: <Y4DuW6Rai0urvrEI@probook>
Precedence: bulk


--EcQuk4Qg6NViYNQL
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 25, 2022 at 05:33:31PM +0100, Jonathan Neusch=E4fer wrote:

> As to connecting non-memory chips: There is also a second, completely
> different SPI controller in this SoC, which is used on some boards (in
> factory configuration) to drive a little status LCD. I think it would be
> easiest to use that one for custom hardware extensions.

That's never stopped hardware engineers.  Perhaps it's simpler for
pinmuxing, layout or other reasons in a given design.

> > If the driver were implementing regular SPI operations and advertising
> > a maximum transfer length this should just work without having to jump
> > through hoops.  The core can split transfers up into sections that fit
> > within the controller limits transparently.

> As far as I'm aware, the controller is not capable of performing a pure
> read transfer, because the command byte (a byte that is written, in
> half-duplex) is always included at the start. I think this limitation
> would break your idea.

> IOW, the hoops aren't nice, but I think they're necessary.

Ah, I see.  That is very limiting.  I'm very surprised that the
6 byte thing works at all TBH.

--EcQuk4Qg6NViYNQL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOA8dYACgkQJNaLcl1U
h9BtJQf9GPbxMYPOrlz3SZgjNLNWe4/gqjuP6n4MLBYU0xX6EA0jljP6ns0O0O1e
hctY+Xg08vYmz9Ty3Ogc6lv1dPXwGB+AxRktoxkZuhp0uiPU5RzTyI7Ln80+DIKA
+KUtP0XO/yjXDcMTS9phUaDmwwKaneKrbYw02G04iYWsJr5Kmp+tJiRYQEBlgdsa
C0bRvfs/rGZHh6PtlamxACJGz8w25EfHbiD/zYpa5csHVQBkSr2qqpMUNKkABBqE
9UNq+InmthqHdHUnjyLVYuy2NcID2EDyo2/rCvi9I6hQceyYchvZFimwp7MciMHy
LkU87STOjXlPjsAaORZDQifKRiG22Q==
=YB2z
-----END PGP SIGNATURE-----

--EcQuk4Qg6NViYNQL--