Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp154139imu; Thu, 8 Nov 2018 06:27:57 -0800 (PST) X-Google-Smtp-Source: AJdET5dXliz9mTMPkSQkmJ1A2IwfQr0vGMkgEUwDhYPlIGmRSaYx2fqhTB/LSoQnCfSu5agoFV+1 X-Received: by 2002:a17:902:50ec:: with SMTP id c41-v6mr4644607plj.176.1541687277461; Thu, 08 Nov 2018 06:27:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541687277; cv=none; d=google.com; s=arc-20160816; b=oj8Oz6EajvSpdFMpylcqMQEpfGLLLaglRA8/X/bKJVpM1JKprThvws1QD75AFHG7G2 wI5U9YkVwShMyjsTKho/XJ+Vk0doEN8M4AC/w/DXtZ9SC0rMNNVONRU3oOzCnpE6kPFE tyFA6oppLVuuRNQrrsqU7H8sD7lfMi0wz90nTjUUcdT32JS95ogThICXXzluwYB8CeQt 8d/olbQB8RakmcLdAwl/TTo/40JesO1OC1GgNLrP1l3Zp6qszjF3OxrNe09eXwGYL/Te vev56VPQ9PVoxU/qn+Ow/bp7KpcNBxGblCHdsaC9+r2aO6ce1y/Z7Dn5AO8Z5spFRooO /n8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=EtQsiIrldae/Xle2vTfi7RHahcPBH5EjTjc18iOf6/M=; b=jV72ra2J8bS0QY6baPlyjG4tmd2rxZBqgqOU5u/Li+KKEXPkVJ/O9nSm1CK0PZRUiR tiq2StxbF4bHDSZ0NFFdzhKsOcISgDfJ0+sKMoplNoMFNoOS1nV6/1/7/0SDKPM1yR3A Jtpsiat/upLmvX/6XxD+Bc1/09iTF+nO25KaQRzddmH4Hl0nupdfNo/eGo9od6NafT+/ moOzAsYwL/r58ZVHMsqE1qP50wRmxeFiuwremHk+jkhsV7JYTcLE1FOKyhv8hpJoLFif WX6SavtuZZeiaOr9hvSHzttmeB5/Ebl1Cf1g95rjn5lXY1LYtw7CRRM61qGNhEVSmrEy y7lw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i64si3831388pge.361.2018.11.08.06.27.41; Thu, 08 Nov 2018 06:27:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726926AbeKIAC2 (ORCPT + 99 others); Thu, 8 Nov 2018 19:02:28 -0500 Received: from mail.bootlin.com ([62.4.15.54]:40241 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726375AbeKIAC2 (ORCPT ); Thu, 8 Nov 2018 19:02:28 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id 41D872080C; Thu, 8 Nov 2018 15:26:43 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.2 Received: from bbrezillon (aaubervilliers-681-1-30-49.w90-88.abo.wanadoo.fr [90.88.15.49]) by mail.bootlin.com (Postfix) with ESMTPSA id 0AC38206A1; Thu, 8 Nov 2018 15:26:43 +0100 (CET) Date: Thu, 8 Nov 2018 15:26:42 +0100 From: Boris Brezillon To: Richard Weinberger Cc: linux-mtd@lists.infradead.org, juergen.lachmann@harman.com, linux-kernel@vger.kernel.org, thomas.roeder@harman.com Subject: Re: [PATCH 2/2] ubi: Expose the bitrot interface Message-ID: <20181108152642.03178c6c@bbrezillon> In-Reply-To: <20181107221619.32498-2-richard@nod.at> References: <20181107221619.32498-1-richard@nod.at> <20181107221619.32498-2-richard@nod.at> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Nov 2018 23:16:19 +0100 Richard Weinberger wrote: > +/** > + * ubi_bitflip_check - Check an eraseblock for bitflips and scrub it if needed. > + * @ubi: UBI device description object > + * @pnum: the physical eraseblock to schedule > + * @force_scrub: force scrubbing if non-zero, schedule erase otherwise Are you sure about the "schedule erase otherwise"? I'd say force_scrub only influence when the scrub operation is done: either unconditionally or depending on the result of ubi_io_read(). > + * > + * This function reads the given eraseblock and checks if bitflips occured. > + * In case of bitflips, the eraseblock is scheduled for scrubbing. > + * If scrubbing is forced with @force_scrub, the eraseblock is not read, > + * but scheduled for scrubbing right away. > + * > + * Returns: > + * %EINVAL, PEB is out of range > + * %ENOENT, PEB is no longer used by UBI > + * %EBUSY, PEB cannot be checked now or a check is currently running on it > + * %EAGAIN, bit flips happened but scrubbing is currently not possible > + * %EUCLEAN, bit flips happened and PEB is scheduled for scrubbing > + * %0, no bit flips detected > + */ > +int ubi_bitflip_check(struct ubi_device *ubi, int pnum, int force_scrub)