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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B2054C00145 for ; Thu, 15 Dec 2022 08:13:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9fYVOW0zJPf427eV2DaHyQvK2cu0EZ3BCpa93QXURVY=; b=eClQvh4Q/Z3XRo ftcqaB0xh/3mFbCA4qkFbalC8fYwOEfgxXBdSDO64JIkm9zVN4T1I8+l0oLPUnR/OtVWs/hHIJEGl KtRMjhXlOppRPCviYKiGlYcBOQ/UfPal586ajZRxj29kKl2LKbB3qxGABhfZpgjZgypX2Mbpozv7P YsbGbaeduE6OKWcUkPUfzWIuTELHb4ZUIe3/KQGsJRKIw6NE9HC8HimXoe2EOBA+HUwTL5hYC3eUk 0FT1VP7ML4/JdfNtQXHz3JzvfBeJrTts448VWT1dvQHoGfjyYAxDFL34QarmMGs7RqyM5oYiQcrDh RQogtHejnCc3aWs8Sl8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5jMQ-007Y9a-4c; Thu, 15 Dec 2022 08:12:58 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5jMH-007Y2K-U5 for linux-mtd@lists.infradead.org; Thu, 15 Dec 2022 08:12:51 +0000 Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 98645E000F; Thu, 15 Dec 2022 08:12:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1671091968; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C51q0U2/0wTS/ZVCiEdunxb3b26NHQ1mconNJdeKVbs=; b=QVodwvgl2IdJbm4JSIVKtjC+VTGG7ZXaynRTD/MvabD1Hvb/zL/bo7sIuttpCSicAksAdv 6NC32ph9C7hAxC7AAPo6BYfZ2049Kvy+DvTX8/fm0P/WfjjMbvGRRfSSI3ZExobnlAmlet o52GYAfM+hHawhFf3kHdB4jc8e8T5l4kzEuY/txFqoEanAz3+PmFxFoAR2wU2fin6ZrHyJ rlhv/WssRBMeDMPLrtZ4rjhY7H14u901DHhZD4ubfBznW96GB2AaFymb5t8UlY/OhwmGiz +L4Od33XAg27I1K4HRblya5MNfZQUYOWhxnzu53GvRq+stH5l0OpEufD/13eNQ== From: Miquel Raynal To: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus , Pratyush Yadav , Michael Walle , Cc: Julien Su , Jaime Liao , Alvin Zhou , Thomas Petazzoni , Miquel Raynal Subject: [PATCH v3 4/9] mtd: spi-nor: Reorder the preparation vs locking steps Date: Thu, 15 Dec 2022 09:12:36 +0100 Message-Id: <20221215081241.407098-5-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221215081241.407098-1-miquel.raynal@bootlin.com> References: <20221215081241.407098-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221215_001250_121960_B7680BE9 X-CRM114-Status: GOOD ( 10.91 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org The ->prepare()/->unprepare() hooks are now legacy, and there are only two controllers left supporting them. In both cases, the implementation acquires a mutex, which is somehow redundant with the spi-nor main lock that we acquire as well in the spi_nor_[un]lock_and_[un]prep() helpers. While the mutex taken in the core is necessary, the helper can be reorganized to first do the preparation, then acquire the core lock. This is necessary in order to be able to improve the locking mechanism in the core and should have no side effect. Signed-off-by: Miquel Raynal --- drivers/mtd/spi-nor/core.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 38a57aac6754..de77ca55f74d 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1074,23 +1074,20 @@ int spi_nor_lock_and_prep(struct spi_nor *nor) { int ret = 0; - mutex_lock(&nor->lock); - - if (nor->controller_ops && nor->controller_ops->prepare) { + if (nor->controller_ops && nor->controller_ops->prepare) ret = nor->controller_ops->prepare(nor); - if (ret) { - mutex_unlock(&nor->lock); - return ret; - } - } + + mutex_lock(&nor->lock); + return ret; } void spi_nor_unlock_and_unprep(struct spi_nor *nor) { + mutex_unlock(&nor->lock); + if (nor->controller_ops && nor->controller_ops->unprepare) nor->controller_ops->unprepare(nor); - mutex_unlock(&nor->lock); } static u32 spi_nor_convert_addr(struct spi_nor *nor, loff_t addr) -- 2.34.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/