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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 297B9CE7A81 for ; Mon, 25 Sep 2023 09:31:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233213AbjIYJb5 convert rfc822-to-8bit (ORCPT ); Mon, 25 Sep 2023 05:31:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230061AbjIYJbz (ORCPT ); Mon, 25 Sep 2023 05:31:55 -0400 Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 860FDC0 for ; Mon, 25 Sep 2023 02:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 43D0C635DB5B; Mon, 25 Sep 2023 11:31:48 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id M_5O8PH87ned; Mon, 25 Sep 2023 11:31:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id CE4CE622F591; Mon, 25 Sep 2023 11:31:47 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R0w8n3XsPmXs; Mon, 25 Sep 2023 11:31:47 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 96F04635DB5B; Mon, 25 Sep 2023 11:31:47 +0200 (CEST) Date: Mon, 25 Sep 2023 11:31:47 +0200 (CEST) From: Richard Weinberger To: Miquel Raynal Cc: ZhaoLong Wang , Vignesh Raghavendra , linux-mtd , linux-kernel , chengzhihao1 , yi zhang , yangerkun Message-ID: <1385178592.80194.1695634307277.JavaMail.zimbra@nod.at> In-Reply-To: <20230925112853.6cb7fff3@xps-13> References: <20230923005856.2538223-1-wangzhaolong1@huawei.com> <20230925104938.3f7b4284@xps-13> <495954216.80155.1695633280285.JavaMail.zimbra@nod.at> <20230925112853.6cb7fff3@xps-13> Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF97 (Linux)/8.8.12_GA_3809) Thread-Topic: Fix error code loss in mtdchar_read() function. Thread-Index: W7/WnPiEM/oyGFOILGmf+sfD68BiaA== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Ursprüngliche Mail ----- > Von: "Miquel Raynal" >> As pointed out by Miquel, the comment makes it clean that this behavior is >> on purpose. If we return now all of a sudden -EBADMSG for the described >> scenario we might even break existing MTD userspace. > > The bugzilla link in the commit log [1] mentions: Ups. > * dd would just stop in the middle without showing errors > -> we probably don't care, we expect the userspace to know this is > NAND when dealing with mtd devices directly, dd is not mtd-aware > anyway. Yep. That's fine. > * ubiformat would loop forever > -> that one needs attention I guess :) Hmm. Let me check the source. Thanks, //richard