From: Boris Brezillon <boris.brezillon@bootlin.com>
To: xiaolei li <xiaolei.li@mediatek.com>
Cc: richard@nod.at, linux-mediatek@lists.infradead.org,
srv_heupstream@mediatek.com, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: Add sysfs attribute for mtd OOB available size
Date: Tue, 3 Apr 2018 10:43:54 +0200 [thread overview]
Message-ID: <20180403104354.03895246@bbrezillon> (raw)
In-Reply-To: <1522723618.3504.7.camel@mhfsdcap03>
On Tue, 3 Apr 2018 10:46:58 +0800
xiaolei li <xiaolei.li@mediatek.com> wrote:
> Hello Boris,
>
> On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:
> > Hi Xiaolei,
> >
> > On Mon, 2 Apr 2018 16:20:10 +0800
> > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> >
> > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.
> >
> > May I ask why you need to expose that? I'm not against exposing new
> > things through sysfs, but since this is part of the ABI, I'd like to be
> > sure we actually need it.
> >
> That is user-space can write OOB data through ioctl MEMWRITE now.
> If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> OOB available bytes it can use. But I didn't find a way to get it. (If
> there is already a method, please kindly let me know, thanks.)
Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
the MTD_MAX_OOBFREE_ENTRIES limitation.
>
> One problem I know is to do Jffs2 type flash erase using MTD user-space
> tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> free area, but it can not get OOB available size.
That's a good reason to expose this property indeed. Do you plan to fix
mtd-utils to use the sysfs value when it's available? Also, do we need
to expose the ECC/free layout as done with the
ECCGETLAYOUT/MEMGETOOBSEL ioctls?
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: xiaolei li <xiaolei.li@mediatek.com>
Cc: <richard@nod.at>, <linux-mediatek@lists.infradead.org>,
<linux-mtd@lists.infradead.org>, <srv_heupstream@mediatek.com>
Subject: Re: [PATCH] mtd: Add sysfs attribute for mtd OOB available size
Date: Tue, 3 Apr 2018 10:43:54 +0200 [thread overview]
Message-ID: <20180403104354.03895246@bbrezillon> (raw)
In-Reply-To: <1522723618.3504.7.camel@mhfsdcap03>
On Tue, 3 Apr 2018 10:46:58 +0800
xiaolei li <xiaolei.li@mediatek.com> wrote:
> Hello Boris,
>
> On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:
> > Hi Xiaolei,
> >
> > On Mon, 2 Apr 2018 16:20:10 +0800
> > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> >
> > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.
> >
> > May I ask why you need to expose that? I'm not against exposing new
> > things through sysfs, but since this is part of the ABI, I'd like to be
> > sure we actually need it.
> >
> That is user-space can write OOB data through ioctl MEMWRITE now.
> If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> OOB available bytes it can use. But I didn't find a way to get it. (If
> there is already a method, please kindly let me know, thanks.)
Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
the MTD_MAX_OOBFREE_ENTRIES limitation.
>
> One problem I know is to do Jffs2 type flash erase using MTD user-space
> tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> free area, but it can not get OOB available size.
That's a good reason to expose this property indeed. Do you plan to fix
mtd-utils to use the sysfs value when it's available? Also, do we need
to expose the ECC/free layout as done with the
ECCGETLAYOUT/MEMGETOOBSEL ioctls?
next prev parent reply other threads:[~2018-04-03 8:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-02 8:20 [PATCH] Add sysfs attribute for mtd OOB available size Xiaolei Li
2018-04-02 8:20 ` Xiaolei Li
[not found] ` <1522657210-56833-1-git-send-email-xiaolei.li-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2018-04-02 8:20 ` [PATCH] mtd: " Xiaolei Li
2018-04-02 8:20 ` Xiaolei Li
[not found] ` <1522657210-56833-2-git-send-email-xiaolei.li-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2018-04-02 12:15 ` Boris Brezillon
2018-04-02 12:15 ` Boris Brezillon
2018-04-03 2:46 ` xiaolei li
2018-04-03 2:46 ` xiaolei li
2018-04-03 8:43 ` Boris Brezillon [this message]
2018-04-03 8:43 ` Boris Brezillon
2018-04-03 9:40 ` xiaolei li
2018-04-03 9:40 ` xiaolei li
2018-04-03 10:14 ` Boris Brezillon
2018-04-03 10:14 ` Boris Brezillon
2018-04-03 11:01 ` xiaolei li
2018-04-03 11:01 ` xiaolei li
2018-04-04 20:05 ` Boris Brezillon
2018-04-04 20:05 ` Boris Brezillon
2018-04-08 1:26 ` xiaolei li
2018-04-08 1:26 ` xiaolei li
2018-04-26 18:04 ` Boris Brezillon
2018-04-26 18:04 ` Boris Brezillon
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=20180403104354.03895246@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=srv_heupstream@mediatek.com \
--cc=xiaolei.li@mediatek.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.