All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: ZhaoLong Wang <wangzhaolong1@huawei.com>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>,
	 chengzhihao1 <chengzhihao1@huawei.com>,
	 yi zhang <yi.zhang@huawei.com>, yangerkun <yangerkun@huawei.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
Date: Mon, 25 Sep 2023 11:31:47 +0200 (CEST)	[thread overview]
Message-ID: <1385178592.80194.1695634307277.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20230925112853.6cb7fff3@xps-13>

----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
>> 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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: ZhaoLong Wang <wangzhaolong1@huawei.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	chengzhihao1 <chengzhihao1@huawei.com>,
	yi zhang <yi.zhang@huawei.com>, yangerkun <yangerkun@huawei.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
Date: Mon, 25 Sep 2023 11:31:47 +0200 (CEST)	[thread overview]
Message-ID: <1385178592.80194.1695634307277.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20230925112853.6cb7fff3@xps-13>

----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
>> 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

  reply	other threads:[~2023-09-25  9:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-23  0:58 [RFC] mtd: Fix error code loss in mtdchar_read() function ZhaoLong Wang
2023-09-23  0:58 ` ZhaoLong Wang
2023-09-25  8:49 ` Miquel Raynal
2023-09-25  8:49   ` Miquel Raynal
2023-09-25  9:14   ` Richard Weinberger
2023-09-25  9:14     ` Richard Weinberger
2023-09-25  9:28     ` Miquel Raynal
2023-09-25  9:28       ` Miquel Raynal
2023-09-25  9:31       ` Richard Weinberger [this message]
2023-09-25  9:31         ` Richard Weinberger
2023-09-25 14:22   ` ZhaoLong Wang
2023-09-25 14:22     ` ZhaoLong Wang
2023-09-25 14:03 ` Richard Weinberger
2023-09-25 14:03   ` Richard Weinberger
2023-09-25 14:37   ` Miquel Raynal
2023-09-25 14:37     ` Miquel Raynal
2023-09-25 14:59     ` Richard Weinberger
2023-09-25 14:59       ` Richard Weinberger
2023-09-25 15:06       ` Miquel Raynal
2023-09-25 15:06         ` Miquel Raynal
2023-09-26  1:08         ` ZhaoLong Wang
2023-09-26  1:08           ` ZhaoLong Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1385178592.80194.1695634307277.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=chengzhihao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=vigneshr@ti.com \
    --cc=wangzhaolong1@huawei.com \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.