From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35549C433E1 for ; Mon, 25 May 2020 13:27:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0F3F52078B for ; Mon, 25 May 2020 13:27:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590413260; bh=YoFRZefk/Go4CvbhR0PvrdsFKUaehxtVPeSJ88VYCkk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=HMi03Rnn2PFR+QIXQ2vvWC6/kqMdk7PXMAl29TIkCtW8Eic5Wh9A4w8jm3XKbFONL 0yBfUt/AzbewoxRSi9KHdkXHx8gJT7dx1Z6abhCGpXvI3qm1ojqPSp/YPjGHEaRhxH aiqQq06ihDk8ffR+IvDHgqnhYXkkzC15PR3aQo70= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390783AbgEYN1j (ORCPT ); Mon, 25 May 2020 09:27:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:44036 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388737AbgEYN1j (ORCPT ); Mon, 25 May 2020 09:27:39 -0400 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CAF7C2070A; Mon, 25 May 2020 13:27:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590413258; bh=YoFRZefk/Go4CvbhR0PvrdsFKUaehxtVPeSJ88VYCkk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KANHk/u+jIlGhMLFQ+yII/qMvYi7vti+H/M4KF9DA5bh0W/kyj1A7fkcBNuu+CXe+ kHuX3qTRNMcmvE37Q3qoi4e27X0JL7JvL0jXdfO8SjSTGZwLPLJdiUNIcIEz1yG/mW mClhznzxcgVpzBIs2Bxz8zb4jH2K1w5V9Zv8Imt4= Date: Mon, 25 May 2020 14:27:35 +0100 From: Mark Brown To: Marc Kleine-Budde Cc: Tim Harvey , open list , linux-can@vger.kernel.org, Wolfgang Grandegger , Timo =?iso-8859-1?B?U2NobPzfbGVy?= , Andy Shevchenko , linux-spi@vger.kernel.org, Jan Glauber , Robert Richter Subject: Re: [PATCH] can: mcp251x: convert to half-duplex SPI Message-ID: <20200525132735.GG4544@sirena.org.uk> References: <0ac77abd-0df5-e437-ea46-f6c77f59b81c@pengutronix.de> <0b351fe3-8fe9-572f-fd85-e2aed22873e3@pengutronix.de> <7b85e098-b9a9-dd14-203f-100cdf2e703e@pengutronix.de> <20200525113106.GB4544@sirena.org.uk> <20200525125743.GF4544@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RDS4xtyBfx+7DiaI" Content-Disposition: inline In-Reply-To: X-Cookie: Help a swallow land at Capistrano. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --RDS4xtyBfx+7DiaI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 25, 2020 at 03:12:05PM +0200, Marc Kleine-Budde wrote: > On 5/25/20 2:57 PM, Mark Brown wrote: > > On Mon, May 25, 2020 at 02:41:31PM +0200, Marc Kleine-Budde wrote: > >> On 5/25/20 1:31 PM, Mark Brown wrote: > >> The core could merge several half duplex transfers (until there's as c= s_change) > >> into a single full duplex transfer. > > Yes, that is what I am suggesting. > Where in the SPI stack do you see such a "merge" function? One point to c= larify > is when and where to allocate and free the memory for the contiguous full= duplex > buffers. My first thought would be about the same point as we're rewriting to handle MUST_TX and MUST_RX in map_msg() which does similar allocations and deallocations to insert dummy data for controllers that need them. > >> I think spi_write_then_read() can be extended to generate one full dup= lex > >> transfer instead on two half duplex ones it does a memcpy() anyways. > > This has the same problem as doing it in any other driver code - it > > causes a needless incompatibility with three wire and single duplex > > devices. =20 > What about the note "portable code should never use this for more than 32= bytes" > in spi_write_then_read()? The CAN driver in question may read more than 3= 2 bytes > of data. I think that comment is actually not valid any more - we used to use a fixed statically allocated buffer in write_then_read() but added the option to fall back onto allocating one dynamically if another user was running or the transfer was too big. --RDS4xtyBfx+7DiaI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl7Lx8YACgkQJNaLcl1U h9B5Dwf+Nb0Y72rxDJYz31zxtSePYg23wFswccy4280iAkIcWoMJkffzIpNnd6/k nn/tJvLg9vt7nnkCRv+a9RXBpLOHughiGTEojzSerkrqLkDEED21ZF+LmgQK4Qwr ORu3nHDWmW46BNo9/Syr7+vDUcPbx11A6LY7/W6f1LMXAXzKHZulq2gcykRgi21I 30jryinvYDsb2nrKRhzNBDASIgyLiNUkOpPGVsN0rXY1K8Avt7Gua8LzRR1ztACM r4I3zCdiR4lZ6UJ9ioEpvWd6jqGYsbcDBJGCDHjtUJSgNvqzwr7e9KerHz0IS2+P LLhgvEFtAZjQUJKkM2vkOezK0Ft0JQ== =Yw0T -----END PGP SIGNATURE----- --RDS4xtyBfx+7DiaI--