[PATCH] mtd: nand: add option to erase NAND blocks even if detected as bad.

[Mario Rugiero]

2017-05-12 7:23 GMT-03:00 Mario Rugiero <mrugiero at gmail.com>:
> 2017-05-12 7:19 GMT-03:00 Boris Brezillon <boris.brezillon at free-electrons.com>:
>> On Fri, 12 May 2017 07:06:45 -0300
>> Mario Rugiero <mrugiero at gmail.com> wrote:
>>
>>> 2017-05-12 6:34 GMT-03:00 Boris Brezillon <boris.brezillon at free-electrons.com>:
>>> > On Fri, 12 May 2017 06:26:14 -0300
>>> > Mario Rugiero <mrugiero at gmail.com> wrote:
>>> >
>>> >> 2017-05-12 6:19 GMT-03:00 Richard Weinberger <richard at nod.at>:
>>> >> > Am 12.05.2017 um 11:15 schrieb Mario Rugiero:
>>> >> >> I'll read it carefully later. Is there any rough time estimate for it
>>> >> >> to hit mainline?
>>> >> >> I'm not expecting a date, but rather something in the lines of
>>> >> >> "several weeks, several months, several years".
>>> >> >> I think we can do with several months, and we'd be happy to start
>>> >> >> local experiments with that timeframe in mind.
>>> >> >> Several years might be more than the devices will live, though.
>>> >> >
>>> >> > Since there is currently no funding it might take much longer.
>>> >> GSoC sounds like a viable workaround.
>>> >> It'd hahve to wait for next year, though.
>>> >> I think I'm elligible, so if I still have access to these boards and
>>> >> Boris can mentor me, we could get funding to speed up the development.
>>> >> I'd be happy to donate it to have another developer, as I'm already
>>> >> kinda being paid for this.
>>> >> What do you think of that?
>>> >
>>> > Yep, that's a possibility.
>>> Great. Could you act as a mentor without GSoC for now?
>>
>> Sure.
>>
>>> I think I might be able to help after finishing with the slides, they
>>> seem clear enough, with proper guidance, and that'd help in my current
>>> work.
>>> I think I've read some slides from a previous talk by you, before the
>>> way to go was as clearly defined.
>>
>> Actually, most of the development is done already, but we need to
>> intensively test the implementation and cleanup the code.
> If you can describe the tests to me, I think I can have them running
> in at least three devices during next week.
> I can help with the cleanup, too.
>>
>> I also started to modify mtd-utils [1] to support the new format, but
>> didn't have time to finish.
>>
>> [1]https://github.com/bbrezillon/mtd-utils/tree/ubi/mlc
> I'll try to help with that.
Back to the original subject, scrubbing from Linux on demand.
Is it a total no-go, or if I add the debugfs entry to make it opt-in
on runtime too it might get accepted?
Is it viable to add it as a new operation, so it can be more explicit
about the risks?
Where would be the proper place to put the debugfs entry?
nand_base.c doesn't seem to deal with debugfs, and exporting the
variable seems too risky IMO.