From patchwork Tue Mar 4 10:02:53 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 326204 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (unknown [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 9429D2C01AB for ; Tue, 4 Mar 2014 21:03:49 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WKmC7-0004RE-Ld; Tue, 04 Mar 2014 10:03:27 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WKmC6-000631-1z; Tue, 04 Mar 2014 10:03:26 +0000 Received: from mga02.intel.com ([134.134.136.20]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WKmBz-00062I-Ua for linux-mtd@lists.infradead.org; Tue, 04 Mar 2014 10:03:24 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 04 Mar 2014 02:02:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,583,1389772800"; d="scan'208";a="493699589" Received: from sauron.fi.intel.com ([10.237.72.82]) by orsmga002.jf.intel.com with ESMTP; 04 Mar 2014 02:02:55 -0800 From: Artem Bityutskiy To: Ezequiel Garcia Subject: [PATCH] UBI: block: do not use term "attach" Date: Tue, 4 Mar 2014 12:02:53 +0200 Message-Id: <1393927373-1472-1-git-send-email-dedekind1@gmail.com> X-Mailer: git-send-email 1.8.5.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140304_050320_063198_9ABAE3C7 X-CRM114-Status: GOOD ( 16.26 ) X-Spam-Score: -5.1 (-----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-5.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dedekind1[at]gmail.com) -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [134.134.136.20 listed in list.dnswl.org] 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list Cc: MTD Maling List X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Artem Bityutskiy We already use term attach/detach for UBI->MTD relations, let's not use this for UBI->ubiblock relations to avoid confusion. Just use 'create' and 'delete' instead. E.g., "create a R/O block device on top of a UBI volume". Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/block.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c index cea7d1c..69955ce 100644 --- a/drivers/mtd/ubi/block.c +++ b/drivers/mtd/ubi/block.c @@ -29,10 +29,10 @@ * * LEB number = addressed byte / LEB size * - * This feature is compiled in the UBI core, and adds a new 'block' parameter - * to allow early block device attaching. Runtime block attach/detach for UBI - * volumes is provided through two new UBI ioctls: UBI_IOCVOLATTBLK and - * UBI_IOCVOLDETBLK. + * This feature is compiled in the UBI core, and adds a 'block' parameter + * to allow early creation of block devices on top of UBI volumes. Runtime + * block creation/removal for UBI volumes is provided through two UBI ioctls: + * UBI_IOCVOLATTBLK and UBI_IOCVOLDETBLK. */ #include @@ -528,7 +528,7 @@ static int ubiblock_notify(struct notifier_block *nb, switch (notification_type) { case UBI_VOLUME_ADDED: /* - * We want to enforce explicit block device attaching for + * We want to enforce explicit block device creation for * volumes, so when a volume is added we do nothing. */ break; @@ -561,7 +561,7 @@ open_volume_desc(const char *name, int ubi_num, int vol_id) return ubi_open_volume(ubi_num, vol_id, UBI_READONLY); } -static int __init ubiblock_attach_from_param(void) +static int __init ubiblock_create_from_param(void) { int i, ret; struct ubiblock_param *p; @@ -592,7 +592,7 @@ static int __init ubiblock_attach_from_param(void) return ret; } -static void ubiblock_detach_all(void) +static void ubiblock_remove_all(void) { struct ubiblock *next; struct ubiblock *dev; @@ -618,13 +618,13 @@ int __init ubiblock_init(void) return ubiblock_major; /* Attach block devices from 'block=' module param */ - ret = ubiblock_attach_from_param(); + ret = ubiblock_create_from_param(); if (ret) - goto err_detach; + goto err_remove; /* - * Block devices needs to be attached to volumes explicitly - * upon user request. So we ignore existing volumes. + * Block devices are only created upon user requests, so we ignore + * existing volumes. */ ret = ubi_register_volume_notifier(&ubiblock_notifier, 1); if (ret) @@ -633,14 +633,14 @@ int __init ubiblock_init(void) err_unreg: unregister_blkdev(ubiblock_major, "ubiblock"); -err_detach: - ubiblock_detach_all(); +err_remove: + ubiblock_remove_all(); return ret; } void __exit ubiblock_exit(void) { ubi_unregister_volume_notifier(&ubiblock_notifier); - ubiblock_detach_all(); + ubiblock_remove_all(); unregister_blkdev(ubiblock_major, "ubiblock"); }