[PATCH v4 3/9] mtd: nand: add more helpers in nand.h

Peter Pan peterpansjtu at gmail.com
Thu Mar 30 01:04:44 PDT 2017


Hi Boris,

On Thu, Mar 30, 2017 at 3:57 AM, Boris Brezillon
<boris.brezillon at free-electrons.com> wrote:
> On Thu, 23 Mar 2017 17:43:40 +0800
> Peter Pan <peterpandong at micron.com> wrote:
>
>> This commit adds some helpers in nand.h
>>     nand_size()
>>     nand_check_address()
>>     nand_check_oob_ops()
>>     nand_oob_ops_across_page()
>>     nand_check_erase_ops()
>>
>> Signed-off-by: Peter Pan <peterpandong at micron.com>
>> ---
>>  include/linux/mtd/nand.h | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 62 insertions(+)
>>
>> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
>> index 54ded4c..0c52401 100644
>> --- a/include/linux/mtd/nand.h
>> +++ b/include/linux/mtd/nand.h
>> @@ -434,6 +434,68 @@ static inline int nand_neraseblocks(struct nand_device *nand)
>>  }
>>
>>  /**
>> + * nand_size - Get NAND size
>> + * @nand: NAND device
>> + *
>> + * Returns the total size exposed by @nand.
>> + */
>> +static inline u64 nand_size(struct nand_device *nand)
>> +{
>> +     return nand->memorg.ndies * nand->memorg.diesize;
>> +}
>> +
>
> The nand_size() function should probably go in the commit introducing
> the interface-agnostic NAND layer (in my own series).
>
> Since you'll be the first one to use the generic NAND layer, I propose
> that you start maintaining my patch-set along with your SPI NAND
> patches.

You mean that I send your patch-set with SPI NAND patches? If so, you want
me to do this in v5 or when SPI NAND patches is ready to merge?

Thanks,
Peter Pan

>
>> +static inline int nand_check_address(struct nand_device *nand, loff_t addr)
>> +{
>> +     return addr < nand_size(nand) ? 0 : -EINVAL;
>> +}
>> +
>> +static inline int nand_check_oob_ops(struct nand_device *nand, loff_t start,
>> +                                  struct mtd_oob_ops *ops)
>> +{
>> +     struct mtd_info *mtd = nand_to_mtd(nand);
>> +     int ooblen = ops->mode == MTD_OPS_AUTO_OOB ?
>> +             mtd->oobavail : mtd->oobsize;
>> +
>> +     if ((!!ops->datbuf != !!ops->len) ||
>> +         (!!ops->oobbuf != !!ops->ooblen))
>> +             return -EINVAL;
>> +     if (ops->ooboffs >= ooblen)
>> +             return -EINVAL;
>> +     if (ops->ooboffs + ops->ooblen >
>> +         (nand_len_to_pages(nand, nand_size(nand)) -
>> +                            nand_offs_to_page(nand, start)) * ooblen)
>> +             return -EINVAL;
>> +
>> +     return 0;
>> +}
>> +
>> +static inline bool nand_oob_ops_across_page(struct nand_device *nand,
>> +                                         struct mtd_oob_ops *ops)
>> +{
>> +     struct mtd_info *mtd = nand_to_mtd(nand);
>> +     int ooblen = ops->mode == MTD_OPS_AUTO_OOB ?
>> +                  mtd->oobavail : mtd->oobsize;
>> +
>> +     return (ops->ooboffs + ops->ooblen) > ooblen;
>> +}
>> +
>> +static inline int nand_check_erase_ops(struct nand_device *nand,
>> +                                    struct erase_info *einfo)
>> +{
>> +     /* check address align on block boundary */
>> +     if (einfo->addr & (nand_eraseblock_size(nand) - 1))
>> +             return -EINVAL;
>> +     /* check lendth align on block boundary */
>> +     if (einfo->len & (nand_eraseblock_size(nand) - 1))
>> +             return -EINVAL;
>> +     /* Do not allow erase past end of device */
>> +     if ((einfo->addr + einfo->len) > nand_size(nand))
>> +             return -EINVAL;
>> +
>> +     return 0;
>> +}
>
> Hm, looking at these functions and the tests already done in mtdcore.c
> I'm not sure this is the best location.
> AFAICS, all these tests can be done (or are already done) at the MTD
> level, and that's where they are the most useful. The only exception I
> see where it could be useful is when the BBT code directly calls nand
> functions instead of mtd ones, but this should not happen that much.
>
>> +
>> +/**
>>   * nand_register - Register a NAND device
>>   * @nand: NAND device
>>   *
>



More information about the linux-mtd mailing list