[PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
flat view
From: Boris Brezillon <hidden>
Date: 2018-10-18 20:50:26
Also in:
linux-amlogic, lkml
On Thu, 18 Oct 2018 13:09:05 +0800 Jianxin Pan [off-list ref] wrote:
quoted hunk ↗ jump to hunk
+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?
quoted hunk ↗ jump to hunk
+ 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.
quoted hunk ↗ jump to hunk
+ + return 0; +}