[Yaffs] bit error rates --> a vendor speaks

[Josh Boyer]

On 2/27/06, Artem B. Bityutskiy <dedekind at yandex.ru> wrote:
> Josh, I believe you're only *partially* right

I'm surprised I'm right at all :).  Normally I just make an idiot of myself.

> 1. The region is an attribute of *flash chip*. The region is *not* an
> attribute of MTD device. MTD device may describe the whole flash chip,
> it may describe a part of flash chip (partitions), and it may describe
> many flash chips (concatenation).
>
> So, I state: the notion of region has nothing to do with the notion of
> MTD device.

Ok.  I agree with that.  Regions are indeed a chip thing.

> If you have a specific application, which works with a *flash chip* not
> an *MTD device*, please, introduce another software object, sort of
> "struct flash_chip". Let your applications to work with these "struct
> flash_chip" objects.
>
> Putting references to regions to the MTD device structure (struct
> mtd_info) is *bad*.

Yes.  And that is where we are getting our signals crossed.  Or mabye
it was just me.  I was thinking that you wanted to take the region
info and make it manditory for a new MTD to be created.  If it's still
valid for the _chip_ driver to abstract away the region stuff, I'm all
for that.

> 2. Well, you're in ecstasy of the current approach (kidding :-) ). Then
> explain me, why if, let's say JFFS3, opens an MTD device, it has access
> to some weird "regions"? What's on earth is going on? This is definitely
> error-prone. This is messy. This is bad design. JFFS3 does not want to
> see regions.

Right.  This is indeed not really wanted.  Are there even users of the
region info in the mtd_info structure?

> 3. Regions... How do you look at them?
>
> We could look at them like this:
> a). They are different entities, used for completely different purposes,
> a rare program needs to use all of them simultaneously, they may have
> different eraseblock size and other properties, they are just different.
> Yes, it happened to be that they are on one single chip, but they are
> still different.
>
> Or we could look at them narrower:
> b). A region is a kind of "appendix" to the flash chip, where the
> bootcode or whatever may be put. There is not more then one (or really
> few) regions per flash chip. There is only one big and main "data"
> region, and one or few small auxiliary regions.
>
> I reckon that the reality is more like b). And in this respect I see
> your point. Indeed, what for should we spend more DRAM to describe this
> unworthy "appendix" (aka region) by a distinct software object? Let's
> push this all together!
>
> I can agree with you *partially*, providing that chips like a). are
> *not* going to appear. Partially means that I only agree that there *may
> be* no reason to create a distinct MTD device for this poor appendix.
>
> So I state: Ok, in b)-like chips, do not create a distinct MTD device.
> Let's invent something different. But this must not be in struct
> mtd_info anyway.

Or not invent anything at all unless it's really, really, really needed :).

>
> Do you see my points?

Yep.  I think we agree for the most part now.

josh