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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 0E818C2D0E4 for ; Tue, 17 Nov 2020 11:28:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD5312222E for ; Tue, 17 Nov 2020 11:28:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727843AbgKQL22 (ORCPT ); Tue, 17 Nov 2020 06:28:28 -0500 Received: from mail.baikalelectronics.com ([87.245.175.226]:42262 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725355AbgKQL22 (ORCPT ); Tue, 17 Nov 2020 06:28:28 -0500 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id 3A926803071C; Tue, 17 Nov 2020 11:28:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at baikalelectronics.ru Received: from mail.baikalelectronics.ru ([127.0.0.1]) by localhost (mail.baikalelectronics.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b7RSBy8AN_V; Tue, 17 Nov 2020 14:28:23 +0300 (MSK) Date: Tue, 17 Nov 2020 14:28:23 +0300 From: Serge Semin To: Andy Shevchenko CC: Serge Semin , Mark Brown , Alexey Malahov , Ramil Zaripov , Pavel Parkhomenko , linux-spi , Linux Kernel Mailing List Subject: Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method Message-ID: <20201117112823.fwadsn5ld7ovjqun@mobilestation> References: <20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org On Tue, Nov 17, 2020 at 12:56:44PM +0200, Andy Shevchenko wrote: > On Tue, Nov 17, 2020 at 11:45 AM Serge Semin > wrote: > > > > I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: > > Explicitly de-assert CS on SPI transfer completion") a concurrent usage of > > the spidev devices with different chip-selects causes the "SPI transfer > > timed out" error. > > I'll read this later... > > > + mutex_lock(&spi->controller->io_mutex); > > + > > if (spi->controller->setup) > > status = spi->controller->setup(spi); > > > > if (spi->controller->auto_runtime_pm && spi->controller->set_cs) { > > status = pm_runtime_get_sync(spi->controller->dev.parent); > > I didn't check what this lock is protecting, It is used to protect the SPI io operations. So it's locked only during the SPI memory operations and the SPI-message execution. That's the time when the core toggles the controller chip-selects by calling the spi_set_cs() method and the set_cs callback. > but have you checked all > PM runtime callbacks if they are not taking the lock. When you call PM > runtime functions with 'sync' it may include a lot of work, some of > which may sleep (not a problem for mutex) and may take arbitrary locks > (might be a deadlock in case of trying the same lock). Yeah, I understand that. Simple grepping hasn't showed anyone else but the SPI-core using it. So unless the controllers PM methods also call spi_setup() or request SPI-transfers, there shouldn't be a deadlock. Moreover as I can see from the __spi_pump_messages() method the IO-mutex is locked during the sync-suffixed PM-methods invocation. AFAICS locking io_mutex around the PM-methods here shouldn't cause problems. But of course testing it in various platforms/controllers is always welcome. -Sergey > > > if (status < 0) { > > + mutex_unlock(&spi->controller->io_mutex); > > pm_runtime_put_noidle(spi->controller->dev.parent); > > dev_err(&spi->controller->dev, "Failed to power device: %d\n", > > status); > > @@ -3354,6 +3357,8 @@ int spi_setup(struct spi_device *spi) > > spi_set_cs(spi, false); > > } > > > > + mutex_unlock(&spi->controller->io_mutex); > > + > > > -- > With Best Regards, > Andy Shevchenko