From patchwork Fri May 19 13:37:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 100190 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp319129qge; Fri, 19 May 2017 06:37:46 -0700 (PDT) X-Received: by 10.98.211.87 with SMTP id q84mr10754533pfg.126.1495201066590; Fri, 19 May 2017 06:37:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1495201066; cv=none; d=google.com; s=arc-20160816; b=WrYB/CwpYcCy8oyx/4JvDWjtGlfFzHaAMIJqFmsJ1cqtWSu2ze2ckKJqLElfDoUE74 q2pEvaQL+W5YdQrybrpB9UQHz23eO6CPgonCDKtMZ8indnK09E7BzNxO1m4cy4PElQYY rzI46fm9dQktiHuYZBIJF/1bEFT89Hc8o4UtGZSdDe3tEeoOBFeaWXB5KRMt79uG/KAN EQzBV3bkj8sqvY7ndMRiPNKgMULH1T5kYaMEB02DFmYLZh8x4x1n0jkqU21LOG1hYx91 bkD7uI71hrkI/SoLOYtyQg7P4JPag2xBYNc8L9uKX7nKNz0y23UhDub2PIKjllPHYPUU 7nDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=DWz/mkdjaLHL+j4C2AYJeVm12YhEO/THPEqpGYdmSe8=; b=AZsusHYLfn/s6vlel8BwktLILfuHkVCfErmHD1Ni49cKIvnHu8oIKdVQqM41hw6LDP pqvWfebUoGvhj6ZeI+eeKFCcIUBeOT2y1jEfDxN8BNKvNPd7Rh2wukz6ponqGXapkaE5 R2XNzrS89KAWL1ea8oJej5F/kn5HysaZOMGbEum70gfpWumOA5ppClMlwaWwPEhN70VT gMGj7SAAyQgOxEjvO3+YJL/AD9kipKatd+Vjap+nN+lBNGAeDKCTBhgHKIEcppWrMP22 LvrR6oTA890sm57Sy05I/368+VpxpzoRnvzCwwPMcwxbhH1L8VAasK2UvdOj85ZnQKur VHPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33si8689720plb.270.2017.05.19.06.37.46; Fri, 19 May 2017 06:37:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753624AbdESNho (ORCPT + 6 others); Fri, 19 May 2017 09:37:44 -0400 Received: from mail-lf0-f48.google.com ([209.85.215.48]:34403 "EHLO mail-lf0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbdESNhn (ORCPT ); Fri, 19 May 2017 09:37:43 -0400 Received: by mail-lf0-f48.google.com with SMTP id 99so1208287lfu.1 for ; Fri, 19 May 2017 06:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=EO9fMEGXfMHpZgNTsHglqSvbAgbwHWBoHpDPWuL7MVU=; b=bVdosaF/4NAHei9uGAY/ctyyEUByXGFuolKcVAzLLVXXzByQfaWxiL18KZ52ygQLuX eek/ccKtkh011XSGBzb+ZBQ3kjQNkOFbhg2pcSO84jSSy8JxiDKGgPjCiTSD+6sszCKe 0lD9mAAV3BucFJrX9lWYSVtOjzd/Q1Apm4N2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=EO9fMEGXfMHpZgNTsHglqSvbAgbwHWBoHpDPWuL7MVU=; b=meN589KDqox3aV3j/AEB4hdhSIR8fGHL8Pf6WCFjUi7vndakmYHOjxiAzVBaF9oJZe XZC4PtlEF8I7l445fewxzG/DUKMKAU5RiMujUWZE/8Xhe22MglDK1eEAmn/V5DgZ2Ul9 uXDG5RZmBpYnD/v/Sz95w+rYuexR8bG+/P62Zla5KENv4bEnXpsN8rfNj6wijU9WdnR8 nBD1q+J/reuLOGAH5uqVCflfFUr5bCObEcVRD2YwAyKLvKhJf/VRPUz/5uS7XQLlh7DZ ekphoSNGX2JILQxkzMmWNZ2RQZOTRl8Oe9a879Ro2jGgIYuyZ2xRS80LXXznJUINVLvY +GCQ== X-Gm-Message-State: AODbwcBRETW7sWcbZGSjakWOGrDvX4QSXFpbN6ibFZs/Rg9772VG8gQG x5ODzQHpPrMvw7BK X-Received: by 10.46.82.22 with SMTP id g22mr2427645ljb.111.1495201062086; Fri, 19 May 2017 06:37:42 -0700 (PDT) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id 19sm1514130ljf.32.2017.05.19.06.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 06:37:40 -0700 (PDT) From: Linus Walleij To: linux-mmc@vger.kernel.org, Ulf Hansson , Adrian Hunter Cc: linux-block@vger.kernel.org, Jens Axboe , Christoph Hellwig , Arnd Bergmann , Bartlomiej Zolnierkiewicz , Paolo Valente , Avri Altman , Linus Walleij Subject: [PATCH 0/6] More MMC block core refactorings Date: Fri, 19 May 2017 15:37:26 +0200 Message-Id: <20170519133732.27470-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.9.3 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org This series builds on top of the previous series that created custom DRV_OP requests for ioctl() operations in MMC. The first patch is a suggestion from Christoph, the second builds infrastructure for issuing more, currently orthogonal custom operations through the block layer. The first operation we move over is pretty uncontroversial and straight-forward: it is the operation that write-protect-locks the boot partitions from sysfs. This is now done through the block layer so we do not need to congest and starve in the big MMC lock. The last two patches are more contoversial: they move the two debugfs accesses for reading card status and EXT CSD over to using the block layer funnel *if* *present*. So if the block layer is configured out, these will still issue operations directly and take the big MMC lock. The patch series is fully ABI safe: any scripts or code using the debugfs with or without the block layer will still work. However this leaves the mmc_card_get() locks in the block.h header for the !CONFIG_MMC_BLOCK case and I'm not really happy to keep them around, the idea is to terminate them. Ways forward after these patches: - Simply remove the debugfs files for status and ext_csd if the block layer is not there. The debugfs is not ABI after all, and there is an ioctl() to do the same job, and that is what mmc-utils is using. - Simply remove the debugfs files for status and ext_csd completely - and require users to switch to using the ioctl() mmc-utils way of doing things if they want to inspect their MMC/SD cards. - Wait and see: when I get to removing the big MMC lock from SDIO I will anyway have to deal with this mess since the big lock is no more a block layer problem, but a problem with the entire MMC/SD/SDIO stack. In any case: these patches fixes the starvation of the boot partition locking and the debugfs access when using the block layer heavily at the same time. Linus Walleij (6): mmc: block: remove req back pointer mmc: block: Tag DRV_OPs with a driver operation type mmc: block: Move DRV OP issue function mmc: block: Move boot partition locking into a driver op mmc: debugfs: Move card status retrieveal into the block layer mmc: debugfs: Move EXT CSD debugfs acces to block layer drivers/mmc/core/block.c | 168 ++++++++++++++++++++++++++++++++------------- drivers/mmc/core/block.h | 49 +++++++++++++ drivers/mmc/core/debugfs.c | 19 +---- drivers/mmc/core/queue.c | 13 ++-- drivers/mmc/core/queue.h | 27 +++++++- 5 files changed, 200 insertions(+), 76 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html