[PATCH v3 06/10] mtd: fix the wrong mtd->type for nand chip

[Brian Norris]

On Wed, Aug 28, 2013 at 10:50 PM, Huang Shijie <b32955 at freescale.com> wrote:
> 于 2013年08月29日 13:34, Huang Shijie 写道:
>> 于 2013年08月29日 13:05, Brian Norris 写道:
>>>
>>> This patch (patch 6) changes the mtd->type for MLC NAND. And mtd->type is
>>> exposed to user-space via ioctl(MEMGETINFO), and (as of this patch), it is
>>> exposed as "unknown" in sysfs.
>>
>> thanks.
>>
>> this patch changes the mtd->type for the jffs2, and the jffs2 can uses the
>> mtd->type to do the sanity check.

But the key point is that not only does this change mtd->type for
JFFS2, but it also exports this new mtd->type to user-space.

>> If without this patch, how the jffs2 can distinguish a SLC or a MLC?

You could precede this patch with one that prevents exporting
MTD_MLCNANDFLASH in mtd_type_show() and in ioctl(MEMGETINFO). I'm not
saying you *must* do this, but that this side effect must be
acknowledged and explained better, or else it seems that you don't
understand the ramifications of your proposed changes.

> hi Brian:
>
> I find a method to distinguish the SLC/MLC for jffs2, we can add the code
> for jffs2:
>   -------------------------------------------------------
>      if (mtd->flags == MTD_CAP_NANDFLASH) {
>
>              struch nand_chip *chip = c->mtd->priv;
>              if (!nand_is_slc)
>                 return -EINVAL;
>      }
>
>
>   ------------------------------------------------------
>
> If you think this code is okay, we can abandon serveral patches.

No, we don't want to leak the mtd_info and nand_chip abstractions that
far. I think the MTD_MLCNANDFLASH type is the right way to do this for
the in-kernel MTD API, but it is a bigger step to automatically leak
that to user-space.

Brian