lkml.org 
[lkml]   [2018]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan <jianxin.pan@amlogic.com> wrote:

> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> + static int max_page_bytes, max_info_bytes;
> + int page_bytes, info_bytes;
> + int nsectors;
> +
> + nsectors = mtd->writesize / nand->ecc.size;
> + page_bytes = mtd->writesize + mtd->oobsize;
> + info_bytes = nsectors * PER_INFO_BYTE;
> +
> + if (nfc->data_buf && nfc->info_buf) {
> + if (max_page_bytes < page_bytes)
> + meson_nfc_free_buffer(nfc);
> + else
> + return 0;
> + }
> +
> + max_page_bytes = max_t(int, max_page_bytes, page_bytes);
> + max_info_bytes = max_t(int, max_info_bytes, info_bytes);
> +
> + nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);

Is there a good reason for not using chip->data_buf and allocating a
new buffer here?

> + if (!nfc->data_buf)
> + return -ENOMEM;
> +
> + nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
> + if (!nfc->info_buf) {
> + kfree(nfc->data_buf);
> + return -ENOMEM;
> + }

I'd recommend moving this info_buf in the priv chip struct, otherwise
you'll have to protect nfc->info_buf with a lock to prevent an already
register chip from using this pointer while you're reallocating the
buffer. Also, I think you have a memleak here.

> +
> + return 0;
> +}

\
 
 \ /
  Last update: 2018-10-18 22:50    [W:0.102 / U:3.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site