From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Richard Weinberger <richard@nod.at>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
linux-mtd@lists.infradead.org, kernel@pengutronix.de,
Daniel Walter <dwalter@sigma-star.at>
Subject: Re: Pass -EUCLEN to userspace?
Date: Fri, 22 Apr 2016 18:11:03 +0200 [thread overview]
Message-ID: <20160422181103.3691112a@bbrezillon> (raw)
In-Reply-To: <571A47D3.6040602@nod.at>
On Fri, 22 Apr 2016 17:48:35 +0200
Richard Weinberger <richard@nod.at> wrote:
> Sascha, Boris,
>
> Am 22.04.2016 um 17:28 schrieb Boris Brezillon:
> >>> I am currently working on a program similar to ubihealthd, just for raw
> >>> mtd pages, not UBI. Basically I want to find out in userspace if my Nand needs
> >>> scrubbing. Is it possible somehow to get this information in userspace?
> >>
> >> Actually we discussed that a year ago with Richard. I told him that we
> >> should put the read/write/erase statistics at the MTD level so that
> >> other MTD users (including userspace programs) could use the same infra
> >> for non-UBI partitions (I need that for the UBOOT and SPL partitions).
> >>
> >> My suggestion was to store those information at the MTD level, and let
> >> UBI implement its own scrubbing layer on top of that, but Richard
> >> decided to go for a simpler approach for its first implementation.
>
> Yeah, I did a first implementation on UBI layer as it had everything we need
> and I didn't want to replicate UBI at MTD level.
> Another reason is that we were not sure how sophisticated ubihealthd needs to be.
>
> Sasha, what exactly is your use case and why is the UBI approach not sufficient for you?
> On Linux MTD access should only happen through UBI and UBOOT/SPL partitions stay untouched.
Fair enough. So all we'll need is a way to retrieve the maximum number
of bitflips for a given block, so that the userspace deamon can
periodically read the SPL and bootloader blocks and decide to scrub
those blocks if the number of bitflips exceed the threshold.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-04-22 16:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 13:25 Pass -EUCLEN to userspace? Sascha Hauer
2016-04-22 15:24 ` Boris Brezillon
2016-04-22 15:28 ` Boris Brezillon
2016-04-22 15:48 ` Richard Weinberger
2016-04-22 16:11 ` Boris Brezillon [this message]
2016-04-22 18:20 ` Richard Weinberger
2016-04-22 18:39 ` Boris Brezillon
2016-04-25 5:28 ` Sascha Hauer
2016-04-25 7:50 ` Boris Brezillon
2016-04-25 8:22 ` Sascha Hauer
2016-04-25 8:40 ` Boris Brezillon
2016-04-25 9:14 ` Sascha Hauer
2016-04-25 9:26 ` Boris Brezillon
2016-04-25 14:11 ` Boris Brezillon
2016-04-26 7:13 ` Pass -EUCLEAN " Sascha Hauer
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=20160422181103.3691112a@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=dwalter@sigma-star.at \
--cc=kernel@pengutronix.de \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=s.hauer@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox