Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1501048imd; Sun, 4 Nov 2018 04:14:59 -0800 (PST) X-Google-Smtp-Source: AJdET5foiiYXlIwBELUhYdhCrAQVVUEBzb3IyeHTLjHiKmAT6wrPhZGVCeLV1eVfX3kbi3IiyEWW X-Received: by 2002:a62:1693:: with SMTP id 141-v6mr18934249pfw.183.1541333699745; Sun, 04 Nov 2018 04:14:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541333699; cv=none; d=google.com; s=arc-20160816; b=ShPsccJfL8c4MoRRLb6IksfZmrUaeoa6d4tVhoeTe0T+2EdYQL2IwxBp4+sbMS3ty3 ktxeYtE5OwYp1N8WG9eUmQ55+vzKcLSYk2HLqhvzcnNPDFf8kXaQLIklB/YZTWEykC7b bu5EFINEHiAKVMA3bDVyLvjjZXYd8lB6lWx3ulYTtFyVboCiFIf9gQhnx1qf8kjCBiSG zAlnwkEJ+ME/dRX7VsGHMwUki2PKQJ+cLAmxFYinU0DRZCwvNCL1I/Vi13frUm9Mz001 NBoMTLEdf/CWe+SiWId0yOBHjUw0UfGVtcl5Zipv8ty3MO1AbLSIR9F8CWHJRk8c5P/r GlpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=yT+/CpmRuX1E2G7SA6Zud7Fdsv1eCRdcjs9Xkl4ejm4=; b=fex1oxWlSHGQ9gYbmT92SVxP5t6oH2+ytM77M1IVicTcx0OQNJWJoRJzvEHdcpgMhH 6hbaO5yBTatqWHJedsZLt3HlMp9OX7PD3zgaAAxez3kiIucVmr+VrSjDaqgJXOpS5x0Z AUV3x/43ouCVmqQgo6Rznbnk3+TCzo7BqJx2qwgsui3eDpgagfVTIHwkfjUP5zG9z8ND Gw1+kU3dYi4glAWtkeml+IMkaA1OUWsaEASC0Lp1/L0doHvrp7SlSS4zreMjU0Fc9Kaf me17WlQpNMa/WZtyJ4v5QAlFRj7gd8iUAtWtRfWnwaO3jjPoNeg0F4+XsKiPPmZbZ6Pp TwmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si12530857pli.416.2018.11.04.04.14.30; Sun, 04 Nov 2018 04:14:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729615AbeKDVYq (ORCPT + 99 others); Sun, 4 Nov 2018 16:24:46 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:40032 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727216AbeKDVYq (ORCPT ); Sun, 4 Nov 2018 16:24:46 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id BDB1280986; Sun, 4 Nov 2018 13:09:55 +0100 (CET) Date: Sun, 4 Nov 2018 13:09:57 +0100 From: Pavel Machek To: Lubomir Rintel Cc: Mark Brown , Geert Uytterhoeven , James Cameron , Rob Herring , Mark Rutland , Eric Miao , Haojian Zhuang , Daniel Mack , Robert Jarzmik , linux-spi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 07/11] spi: Deal with slaves that return from transfer_one() unfinished Message-ID: <20181104120957.GS23864@amd> References: <20181010170936.316862-1-lkundrak@v3.sk> <20181010170936.316862-8-lkundrak@v3.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8N5nZmKALFZnI1Hj" Content-Disposition: inline In-Reply-To: <20181010170936.316862-8-lkundrak@v3.sk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --8N5nZmKALFZnI1Hj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed 2018-10-10 19:09:32, Lubomir Rintel wrote: > Some drivers, such as spi-pxa2xx return from the transfer_one callback > immediately, idicating that the transfer will be finished asynchronously. >=20 > Normally, spi_transfer_one_message() synchronously waits for the > transfer to finish with wait_for_completion_timeout(). For slaves, we > don't want the transaction to time out as it can complete in a long time > in future. Use wait_for_completion_interruptible() instead. >=20 > Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek > @@ -993,6 +993,44 @@ static int spi_map_msg(struct spi_controller *ctlr, = struct spi_message *msg) > return __spi_map_msg(ctlr, msg); > } > =20 > +static int spi_transfer_wait(struct spi_controller *ctlr, > + struct spi_message *msg, > + struct spi_transfer *xfer) > +{ > + struct spi_statistics *statm =3D &ctlr->statistics; > + struct spi_statistics *stats =3D &msg->spi->statistics; > + unsigned long long ms =3D 1; > + > + if (spi_controller_is_slave(ctlr)) { > + if (wait_for_completion_interruptible(&ctlr->xfer_completion)) { > + dev_dbg(&msg->spi->dev, "SPI transfer interrupted\n"); > + return -EINTR; > + } Do "return 0" here, and you can get rid of the else branch. > + } else { > + ms =3D 8LL * 1000LL * xfer->len; > + do_div(ms, xfer->speed_hz); > + ms +=3D ms + 200; /* some tolerance */ > + > + if (ms > UINT_MAX) > + ms =3D UINT_MAX; > + > + ms =3D wait_for_completion_timeout(&ctlr->xfer_completion, > + msecs_to_jiffies(ms)); > + > + if (ms =3D=3D 0) { > + SPI_STATISTICS_INCREMENT_FIELD(statm, > + timedout); > + SPI_STATISTICS_INCREMENT_FIELD(stats, > + timedout); > + dev_err(&msg->spi->dev, > + "SPI transfer timed out\n"); > + msg->status =3D -ETIMEDOUT; > + } > + } > + > + return 0; > +} > + > /* > * spi_transfer_one_message - Default implementation of transfer_one_mes= sage() > * --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --8N5nZmKALFZnI1Hj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlve4ZUACgkQMOfwapXb+vJezACfdWPmxIHik7NiQxIG5EgeGSmt jn0AoMPqn1NFosIeoCv7HnAUgT8maF5w =mj88 -----END PGP SIGNATURE----- --8N5nZmKALFZnI1Hj--