Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756112AbcCaLLT (ORCPT ); Thu, 31 Mar 2016 07:11:19 -0400 Received: from exsmtp01.microchip.com ([198.175.253.37]:61429 "EHLO email.microchip.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754249AbcCaLLR (ORCPT ); Thu, 31 Mar 2016 07:11:17 -0400 Subject: Re: [PATCH v4 2/2] spi: spi-pic32: Add PIC32 SPI master driver To: Mark Brown References: <1458740576-9168-1-git-send-email-purna.mandal@microchip.com> <1458740576-9168-2-git-send-email-purna.mandal@microchip.com> <20160328192629.GG2350@sirena.org.uk> <56FA6EE1.3000405@microchip.com> <20160329162501.GP2350@sirena.org.uk> <56FBAF2C.9090401@microchip.com> <20160330154839.GZ2350@sirena.org.uk> CC: , , Sergei Shtylyov , Joshua Henderson , Ulf Hansson From: Purna Chandra Mandal Message-ID: <56FD0572.1030309@microchip.com> Date: Thu, 31 Mar 2016 16:39:38 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160330154839.GZ2350@sirena.org.uk> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1147 Lines: 22 On 03/30/2016 09:18 PM, Mark Brown wrote: > On Wed, Mar 30, 2016 at 04:19:16PM +0530, Purna Chandra Mandal wrote: >> On 03/29/2016 09:55 PM, Mark Brown wrote: >>> On Tue, Mar 29, 2016 at 05:32:41PM +0530, Purna Chandra Mandal wrote: >>>> MMC_SPI will have to terminate on-going MMC transactions and it is >>>> done by calling setup(). It is assumed that setup() will always leave >>>> the chip-select deactivated. >>> No, this is just completely broken - that's quite simply not what >>> setup() does. See spi-summary. There is *no* code in the core that >>> terminates ongoing transfers as a result of calling setup(), if that's >>> happening it's a result of triggering error handling. >> Description of spi_setup() in spi.c clearly mentions that "When this >> function returns, the spi device is deselected" and this is only >> possible if (at least) chip-select is deactivated. > This doesn't say anything about any ongoing operations! Trying to do a > setup() with active transfers on the device is just not sensible, it is > intended to be used on an idle device. I would not expect it to work > reliably on an active device. agreed.